When pkg-config is required for a package because it is needed by the configure script, it needs to be listed as a BuildRequired dependency in the spec file. Currently I see three different versions of the dependency: BuildRequires: pkgconfig (most common) BuildRequires: pkg-config (e.g. mingw32-cairo) BuildRequires: mingw32-cross-pkg-config (e.g. mingw-poppler) Which one should be used? And a related question: I presume pkgconfig and pkg-config come from the native OpenSUSE package and mingw32-cross-pkg-config from the package with the same name. But what does the mingw32-pkg-config package provide? Maarten -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org
Maarten, On 05/04/2011 23:11, Maarten Bosmans wrote:
BuildRequires: pkgconfig (most common) BuildRequires: pkg-config (e.g. mingw32-cairo)
These two are equivalent because OBS takes care of renaming in the spec file either of them to the name the pkg-config package has in the distribution. These are normal native linux pkg-config packages that don't know about our /usr/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig and /usr/i686-w64-mingw32/sys-root/mingw/share/pkgconfig directories unless one sets a special PKG_CONFIG_PATH. Which we do in the environment creation script, so that the mingw32-configure and other wrappers will set that variable. The disadvantage of this is that if you don't have on the system in the cross-compiling sysroot the given package, it will pick the native one if it is present. Which is not good
BuildRequires: mingw32-cross-pkg-config (e.g. mingw-poppler)
This is also a Linux native binary, although it is configured so that it knows only about our cross-compiling paths. It will not consider the native paths unless one adds them using the PKG_CONFIG_PATH variable. It is also installed as i686-w64-mingw32-pkg-config. The advantage is that if present, the environment creation script will set the PKG_CONFIG variable to it. Which means that the different configure scripts will use it. This is the preferable dependency,since it depends on the native pkg-config/pkgconfig anyway for the pkg.m4 macro file which this package does not install to avoid conflicts. I hope I did not mess you up too much with this explanation F. -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org
2011/4/6 Fridrich Strba
Maarten,
On 05/04/2011 23:11, Maarten Bosmans wrote:
BuildRequires: pkgconfig (most common) BuildRequires: pkg-config (e.g. mingw32-cairo)
These two are equivalent because OBS takes care of renaming in the spec file either of them to the name the pkg-config package has in the distribution. These are normal native linux pkg-config packages that don't know about our /usr/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig and /usr/i686-w64-mingw32/sys-root/mingw/share/pkgconfig directories unless one sets a special PKG_CONFIG_PATH. Which we do in the environment creation script, so that the mingw32-configure and other wrappers will set that variable. The disadvantage of this is that if you don't have on the system in the cross-compiling sysroot the given package, it will pick the native one if it is present. Which is not good
BuildRequires: mingw32-cross-pkg-config (e.g. mingw-poppler)
This is also a Linux native binary, although it is configured so that it knows only about our cross-compiling paths. It will not consider the native paths unless one adds them using the PKG_CONFIG_PATH variable. It is also installed as i686-w64-mingw32-pkg-config. The advantage is that if present, the environment creation script will set the PKG_CONFIG variable to it. Which means that the different configure scripts will use it. This is the preferable dependency,since it depends on the native pkg-config/pkgconfig anyway for the pkg.m4 macro file which this package does not install to avoid conflicts.
I hope I did not mess you up too much with this explanation
Thanks for the explanation. If I understand correctly, the second (preferred) option is like setting PKG_CONFIG_LIBDIR to the mingw32 specific directories instead of PKG_CONFIG_PATH.
F.
Can you then explain what the mingw32-pkg-config provides? Maarten -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org
Maarten, On Wed, 2011-04-06 at 00:44 +0200, Maarten Bosmans wrote:
Thanks for the explanation. If I understand correctly, the second (preferred) option is like setting PKG_CONFIG_LIBDIR to the mingw32 specific directories instead of PKG_CONFIG_PATH.
As I understand the PKG_CONFIG_LIBDIR, once it is set, the PKG_CONFIG_PATH is completely ignored. That is why I created that mingw32-cross-pkg-config. Certain packages look for some build tools using the native linux pc files. In that case, using mingw32-cross-pkg-config and appropriate PKG_CONFIG_PATH is good. I know that Fedora went the PKG_CONFIG_LIBDIR path long after we had the mingw32-cross-pkg-config, but I am still considering that our solution is more flexible. F. -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org
Hello, good people, On 06/04/2011 07:35, Fridrich Strba wrote:
As I understand the PKG_CONFIG_LIBDIR, once it is set, the PKG_CONFIG_PATH is completely ignored. That is why I created that mingw32-cross-pkg-config. Certain packages look for some build tools using the native linux pc files. In that case, using mingw32-cross-pkg-config and appropriate PKG_CONFIG_PATH is good. I know that Fedora went the PKG_CONFIG_LIBDIR path long after we had the mingw32-cross-pkg-config, but I am still considering that our solution is more flexible.
And this flexibility was useful in what I'm gonna describe. Some weeks ago I got bitten by a broken behaviour of the PKG_CHECK_MODULES macro. If some of the requested *.pc files, it will shout loud and it is good so. But if all the requested *.pc files are present, but some of the dependent *.pc files are not, the macro will still succeed checking for the packages, just will leave blank the corresponding *_CFLAGS and *_LIBS. And the logs are not really useful. One has to actually try to run the pkg-config command manually to get an error that is giving the right hint. So, having been bitten by this, I gave a thought to a more intelligent way of generating provides and dependencies also for the *-devel packages. The system that I implemented uses quite extensively mingw{32,64}-cross-pkg-config. There is still need to set the requires manually for packages that have nothing to do with pkg-config, but they are the minority and the dependencies in them are generally tried and true since some time. Now, how it works: Provides: In the mingw{32,64}-find-provides.sh we scan for 1) all *.a files 2) all *.pc files For each lib<libname>.dll.a or lib<libname>.a, we generate a provide mingw32(lib:<libname>) For each *.pc file, we ask mingw32-cross-pkg-config to --print-provides and we generate for each of them the mingw32(pkg:<pkgname>) = <version>. (And here it was great to be able to have default pkg-config path in our sys-root but also to add arbitrary directory to it). Requires: Those are purely done by the mingw32-cross-pkg-config. We querry each *.pc file for --print-requires and generate the require mingw32(pkg:<packagename>) for each of them, also being able to specify version requirements if they exist in the *.pc file. We also querry the *.pc files for --libs-only-l and for each -l<libname>, we generate mingw32(lib:<libname>) require. In this way, the *-devel package will be able to know all other *-devel packages needed for the correct function of PKG_CHECK_MODULES and all libraries neede for a proper -no-undefined linking. There inconvenient is that if a package distributes a *.pc file, it will have to buildrequire the mingw32-cross-pkg-config, even though the package itself does not "use" pkg-config for detecting its dependencies. The positive side is that we diminish a risk of mess in dependencies, and basically, one could eventually get rid of the manual dependency specifications in the *-devel files. Another positive element is that the dependencies are not specified using the name of the package, but its content. This would eventually allow to have a little bit easier repackaging in case we decide one day to generate packages for other Windows package management systems. Don't hesitate to comment and to seek clarification if needed. Fridrich -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org
2011/4/20 Fridrich Strba
Hello, good people,
On 06/04/2011 07:35, Fridrich Strba wrote:
As I understand the PKG_CONFIG_LIBDIR, once it is set, the PKG_CONFIG_PATH is completely ignored. That is why I created that mingw32-cross-pkg-config. Certain packages look for some build tools using the native linux pc files. In that case, using mingw32-cross-pkg-config and appropriate PKG_CONFIG_PATH is good. I know that Fedora went the PKG_CONFIG_LIBDIR path long after we had the mingw32-cross-pkg-config, but I am still considering that our solution is more flexible.
And this flexibility was useful in what I'm gonna describe.
Some weeks ago I got bitten by a broken behaviour of the PKG_CHECK_MODULES macro. If some of the requested *.pc files, it will shout loud and it is good so. But if all the requested *.pc files are present, but some of the dependent *.pc files are not, the macro will still succeed checking for the packages, just will leave blank the corresponding *_CFLAGS and *_LIBS. And the logs are not really useful. One has to actually try to run the pkg-config command manually to get an error that is giving the right hint.
So, having been bitten by this, I gave a thought to a more intelligent way of generating provides and dependencies also for the *-devel packages.
That's great. And thanks for the extensive explanation of how it works.
The system that I implemented uses quite extensively mingw{32,64}-cross-pkg-config. There is still need to set the requires manually for packages that have nothing to do with pkg-config, but they are the minority and the dependencies in them are generally tried and true since some time.
Now, how it works:
Provides: In the mingw{32,64}-find-provides.sh we scan for 1) all *.a files 2) all *.pc files For each lib<libname>.dll.a or lib<libname>.a, we generate a provide mingw32(lib:<libname>) For each *.pc file, we ask mingw32-cross-pkg-config to --print-provides and we generate for each of them the mingw32(pkg:<pkgname>) = <version>. (And here it was great to be able to have default pkg-config path in our sys-root but also to add arbitrary directory to it).
Requires: Those are purely done by the mingw32-cross-pkg-config. We querry each *.pc file for --print-requires and generate the require mingw32(pkg:<packagename>) for each of them, also being able to specify version requirements if they exist in the *.pc file. We also querry the *.pc files for --libs-only-l and for each -l<libname>, we generate mingw32(lib:<libname>) require.
Shouldn't it also check --print-requires-private? I don't know what the difference is supposed to be for public and private dependencies, but at least for cairo, pixman is not in the public dependencies of any of the cairo*.pc files. Currently pixman is in the Requires: list of cairo-devel. May be that's not needed though, in any case it isn't needed for linking against Cairo.
In this way, the *-devel package will be able to know all other *-devel packages needed for the correct function of PKG_CHECK_MODULES and all libraries neede for a proper -no-undefined linking.
There inconvenient is that if a package distributes a *.pc file, it will have to buildrequire the mingw32-cross-pkg-config, even though the package itself does not "use" pkg-config for detecting its dependencies.
The positive side is that we diminish a risk of mess in dependencies, and basically, one could eventually get rid of the manual dependency specifications in the *-devel files.
Have you tested this on some packages and did the new dependencies pull in the same packages as the manual Requires tags?
Another positive element is that the dependencies are not specified using the name of the package, but its content. This would eventually allow to have a little bit easier repackaging in case we decide one day to generate packages for other Windows package management systems.
Don't hesitate to comment and to seek clarification if needed.
Fridrich
Maarten -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org
Hello, On 20/04/11 09:53, Maarten Bosmans wrote:
Shouldn't it also check --print-requires-private? I don't know what the difference is supposed to be for public and private dependencies, but at least for cairo, pixman is not in the public dependencies of any of the cairo*.pc files. Currently pixman is in the Requires: list of cairo-devel. May be that's not needed though, in any case it isn't needed for linking against Cairo.
No, the --print-requires-private is for static linking and we don't do static linking anyway.
Have you tested this on some packages and did the new dependencies pull in the same packages as the manual Requires tags?
I did not test it extensively, because it would mean to change everything again and I would like to do this gradually when upgrading packages. But where I checked it worked. Cheers F. -- Please avoid sending me Word, Excel or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org
Well, the build service has finished building the whole repository.
(x64_64 lagging a bit). And all works well. It seems you have fixed
the global rpmlintrc file problem fo SLE 11.
2011/4/20 Fridrich Strba
Hello,
On 20/04/11 09:53, Maarten Bosmans wrote:
Shouldn't it also check --print-requires-private? I don't know what the difference is supposed to be for public and private dependencies, but at least for cairo, pixman is not in the public dependencies of any of the cairo*.pc files. Currently pixman is in the Requires: list of cairo-devel. May be that's not needed though, in any case it isn't needed for linking against Cairo.
No, the --print-requires-private is for static linking and we don't do static linking anyway.
Have you tested this on some packages and did the new dependencies pull in the same packages as the manual Requires tags?
I did not test it extensively, because it would mean to change everything again and I would like to do this gradually when upgrading packages. But where I checked it worked.
I checked a very simple package: libcroco. Apart from the correctly detected dependency on glib and libxml (both through pkg: and lib:), there is another dependency on mingw32(lib:intl), provided by: mingw32-gettext-tools. How did your scripts pick up that one? It does not appear in the current Requires: for the -devel package (gettext isn't even in the BuildRequires) and no mention of libintl in libcroco-0.6.pc either. Maarten -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, On 22/04/11 21:54, Maarten Bosmans wrote:
Well, the build service has finished building the whole repository. (x64_64 lagging a bit). And all works well. It seems you have fixed the global rpmlintrc file problem fo SLE 11.
Yup, I branched into the infrastructure repository windows:mingw the packages rpmlint, rpmlint-Factory and rpmlint-mini from openSUSE_11.3 and use them for the SLE_11 and SLE_11_SP1 repositories. Those rpmlint versions load the global config files, so we are ok now.
I checked a very simple package: libcroco. Apart from the correctly detected dependency on glib and libxml (both through pkg: and lib:), there is another dependency on mingw32(lib:intl), provided by: mingw32-gettext-tools. How did your scripts pick up that one? It does not appear in the current Requires: for the -devel package (gettext isn't even in the BuildRequires) and no mention of libintl in libcroco-0.6.pc either.
The secret of production :) The pkg-config --libs-only-l is pulling all libs from all dependent pc files when run on a particular pc file. This is basically a way to assure that the linking will not fail because of a missing library, so every -l<whatever> that appears in the chain, we consider it as a dependency. Cheers Fridrich - -- Please avoid sending me Word, Excel or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk2x7WAACgkQu9a1imXPdA+NbACfbLlocHXz1n95cQoXovWdKUGU v5oAn3H4DwFwDek72d3ebLcD6E2lqKfN =kI7v -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org
2011/4/22 Fridrich Strba
On 22/04/11 21:54, Maarten Bosmans wrote:
I checked a very simple package: libcroco. Apart from the correctly detected dependency on glib and libxml (both through pkg: and lib:), there is another dependency on mingw32(lib:intl), provided by: mingw32-gettext-tools. How did your scripts pick up that one? It does not appear in the current Requires: for the -devel package (gettext isn't even in the BuildRequires) and no mention of libintl in libcroco-0.6.pc either.
The secret of production :)
The pkg-config --libs-only-l is pulling all libs from all dependent pc files when run on a particular pc file. This is basically a way to assure that the linking will not fail because of a missing library, so every -l<whatever> that appears in the chain, we consider it as a dependency.
But in this case you don't want libcroco-devel to depend directly on libintl, because it doesn't link against that. The Require: for the -devel package gets pulled in through the dependency on glib2-devel. Maarten -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org
Hello, On 22/04/2011 21:54, Maarten Bosmans wrote:
I checked a very simple package: libcroco. Apart from the correctly detected dependency on glib and libxml (both through pkg: and lib:), there is another dependency on mingw32(lib:intl), provided by: mingw32-gettext-tools. How did your scripts pick up that one? It does not appear in the current Requires: for the -devel package (gettext isn't even in the BuildRequires) and no mention of libintl in libcroco-0.6.pc either.
I extended it a bit by profitting from the use of the %{_mingwXY_bindir}/*-config files that sometimes can give good information for packages that don't use pkg-config. I also removed any explicit dependency for the *-devel packages and will add the necessary ones only if the builds break due to badly detected dependencies. It should be a bit faster given that during the Easter break the OBS cleared a bit :) F. -- Please avoid sending me Word, Excel or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org
participants (2)
-
Fridrich Strba
-
Maarten Bosmans