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
m4 check for OpenSSL does not consider multi-arch setups
In distributions that use multi-arch setup (such as Debian 7) libssl.a is
installed in /usr/lib/x86_64-linux-gnu. That renders the m4
macro ax_check_openssl.m4 useless for such systems since the library is
only looked for in the following paths:
ssldirs=/usr/local/ssl /usr/lib/ssl /usr/ssl /usr/pkg /usr/local /usr
Boost is also installed in /usr/lib/x86_64-linux-gnu, but the m4 macro for
Boost takes care of it in the following way:
100 dnl allow for real multi-arch paths e.g. /usr/lib/x86_64-linux-gnu.
Give 101 dnl them priority over the other paths since, if libs are found
there, they 102 dnl are almost assuredly the ones desired. 103
AC_REQUIRE([AC_CANONICAL_HOST]) 104 libsubdirs=lib/${host_cpu}-${host_os}
$libsubdirs 105 106 case ${host_cpu} in 107 i?86) 108
libsubdirs=lib/i386-${host_os} $libsubdirs 109 ;; 110 esac
My knowledge of m4 and autoconf's internals is very limited, so it would be
great if someone with the required knowledge could have a look at it. But I
may be able to come up with a solution if I receive some guidance.
Thank you,
Victor
Re: m4 check for OpenSSL does not consider multi-arch setups
On 08/16/2014 02:21 PM, victor jimenez wrote: In distributions that use multi-arch setup (such as Debian 7) libssl.a is installed in /usr/lib/x86_64-linux-gnu. That renders the m4 macro ax_check_openssl.m4 useless for such systems since the library is only looked for in the following paths: ssldirs=/usr/local/ssl /usr/lib/ssl /usr/ssl /usr/pkg /usr/local /usr Thanks for the report. However, autoconf is not the owner of ax_check_openssl.m4, so you'll have to redirect your report to the author of that file if you want anything to change. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
