Re: cross-compilation and proprietary pkg-config replacements (pcre-config, pcap-config, etc)
On Sun 17 Aug 2014 18:50:54 Bob Friesenhahn wrote: On Sat, 16 Aug 2014, Wookey wrote: It's not really en vogue, it's historic: many of the things that have their own *-config scripts are sufficiently old that they pre-date pkg-config so are not doing this just to be annoying. At the time they didn't have much choice. Sometimes it is also done because not every system will have pkg-config, or the one which exists is not well maintained. It can be done in addition to supporting pkg-config. so build+install a pkg-config ? there are simple replacements that don't require any external libs like: https://github.com/pkgconf/pkgconf -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: cross-compilation and proprietary pkg-config replacements (pcre-config, pcap-config, etc)
On Sat, 16 Aug 2014, Wookey wrote: It's not really en vogue, it's historic: many of the things that have their own *-config scripts are sufficiently old that they pre-date pkg-config so are not doing this just to be annoying. At the time they didn't have much choice. Sometimes it is also done because not every system will have pkg-config, or the one which exists is not well maintained. It can be done in addition to supporting pkg-config. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: cross-compilation and proprietary pkg-config replacements (pcre-config, pcap-config, etc)
On Sat 16 Aug 2014 00:21:02 Wookey wrote: +++ John Spencer [2014-08-15 23:49 +0200]: It seems it's en vogue for libs to ship their own broken replacement rather than supplying a portable pkgconfig file... the list is big, but these here are the most often used ones: pcap-config, pcre-config, freetype-config, apr-1-config, glib-config, gtk-config, ncursesw5-config, libmikmod-config, etc. It's not really en vogue, it's historic: many of the things that have their own *-config scripts are sufficiently old that they pre-date pkg-config so are not doing this just to be annoying. At the time they didn't have much choice. at least with some, it's not just a matter of just compile flags. the apr ones to mind as a complete mess as they use the paths to indirectly look up a bunch of other things (like use the install libtool linker script). simply dropping in a .pc file there isn't sufficient to clean up the mess :(. since it's unlikely to get any of those fixed in the next decade (or even convinced to ship .pc files instead of their NIH'd pkg-config replacement), I don't see why this should be too hard. We've (Debian) already persuaded a couple of projects to just use pkg-config instead of whatever homegrown stuff they had, or at least do that as well. It's the right way to make crossing and multiarch work right (as you are aware), and I'd hope that most upstreams could be persuaded of that. the gpg guys are the only ones that come to mind as actively ignoring and blocking progress. i too have had good experience with just about every other project. -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
cross-compilation and proprietary pkg-config replacements (pcre-config, pcap-config, etc)
Hello! I'm currently in the process of adding cross-compilation support to a linux distribution, but I'm running into a lot of nasty issues. The #1 offender are proprietary pkg-config replacements, and there are many. They break cross-compilation by returning non-sysrooted include and library directories from the host, like -I/usr/include or -L/lib. I'm glad to say that autoconf itself is one of the few components that properly handle cross-compilation. It seems it's en vogue for libs to ship their own broken replacement rather than supplying a portable pkgconfig file... the list is big, but these here are the most often used ones: pcap-config, pcre-config, freetype-config, apr-1-config, glib-config, gtk-config, ncursesw5-config, libmikmod-config, etc. (in a proper setup those are not even needed, unless they installed headers into a custom subdir in the standard include path. otherwise just returning -lmylib is the only thing that's needed.) since it's unlikely to get any of those fixed in the next decade (or even convinced to ship .pc files instead of their NIH'd pkg-config replacement), my idea was to add support for them into autoconf itself: Offer a m4 macro for each of them (or a generic external config macro), which then calls these config tools and prefixes the returned include and library paths with the sysroot path (passed to configure via --with-sysroot=). so packagers depending on these libraries would use the provided macros rather than hardcoding their own test. Does this sound viable and acceptable for inclusion ? Or is there another workaround that i missed ? Regards, --JS ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: cross-compilation and proprietary pkg-config replacements (pcre-config, pcap-config, etc)
+++ John Spencer [2014-08-15 23:49 +0200]: Hello! I'm currently in the process of adding cross-compilation support to a linux distribution, but I'm running into a lot of nasty issues. The #1 offender are proprietary pkg-config replacements, and there are many. They break cross-compilation by returning non-sysrooted include and library directories from the host, like -I/usr/include or -L/lib. I'm glad to say that autoconf itself is one of the few components that properly handle cross-compilation. It seems it's en vogue for libs to ship their own broken replacement rather than supplying a portable pkgconfig file... the list is big, but these here are the most often used ones: pcap-config, pcre-config, freetype-config, apr-1-config, glib-config, gtk-config, ncursesw5-config, libmikmod-config, etc. It's not really en vogue, it's historic: many of the things that have their own *-config scripts are sufficiently old that they pre-date pkg-config so are not doing this just to be annoying. At the time they didn't have much choice. since it's unlikely to get any of those fixed in the next decade (or even convinced to ship .pc files instead of their NIH'd pkg-config replacement), I don't see why this should be too hard. We've (Debian) already persuaded a couple of projects to just use pkg-config instead of whatever homegrown stuff they had, or at least do that as well. It's the right way to make crossing and multiarch work right (as you are aware), and I'd hope that most upstreams could be persuaded of that. But there is a load of work involved in fixing things up and checking you didn't break all their reverse dependencies so it will take some time. my idea was to add support for them into autoconf itself: Offer a m4 macro for each of them (or a generic external config macro), which then calls these config tools and prefixes the returned include and library paths with the sysroot path (passed to configure via --with-sysroot=). so packagers depending on these libraries would use the provided macros rather than hardcoding their own test. Interesting idea. Is that easier than just adding a pkg-config file to each project? If you do this do remember that we want it to work on multiarch systems too, where sysroot is not used (equivalent to sysroot=/) Does this sound viable and acceptable for inclusion ? Or is there another workaround that i missed ? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: cross-compilation and proprietary pkg-config replacements (pcre-config, pcap-config, etc)
It seems it's en vogue for libs to ship their own broken replacement rather than supplying a portable pkgconfig file... the list is big, but these here are the most often used ones: pcap-config, pcre-config, freetype-config, apr-1-config, glib-config, gtk-config, ncursesw5-config, libmikmod-config, etc. Uh, oh, FreeType provides a .pc file also! And I've fixed all bug reports w.r.t. freetype-config; in particular, it supports sysroot. If you think something's still missing, please write a bug report or provide a patch instead of whining behind my back, so to say :-) Werner ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
