Summary: | www-servers/apache and dev-libs/apr do not bundle libtool and use old automake (libtool cannot infer tags from full path) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Santiago M. Mola (RETIRED) <coldwind> |
Component: | Current packages | Assignee: | Apache Team - Bugzilla Reports <apache-bugs> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | bertrand, binki, d.stonier, haubi, mail, sam, ss23, vapier |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=385775 https://bugs.gentoo.org/show_bug.cgi?id=374355 https://issues.apache.org/bugzilla/show_bug.cgi?id=47691 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Santiago M. Mola (RETIRED)
![]() *** This bug has been marked as a duplicate of bug 56407 *** I fail to see why $PATH should be a problem for $CC being an _absolute_ path. Add a quick explanation if you really think this is a duplicate. (In reply to comment #2) > I fail to see why $PATH should be a problem for $CC being an _absolute_ path. > Add a quick explanation if you really think this is a duplicate. I don't see how's Bug 56407 limited to path really. As the summary suggests, it's a generic bug about portage failing to sanitize ebuild environment. Ok, it's a dupe of Bug 56407 in the sense that portage shouldn't be using user's env CC. But what I'm reporting is actually libtool being broken when CC is a patch, and CC can be defined in PM's env. portage should never remove CC from the environment there are multiple issues here, all of which i blame on apache: - no package should ever execute libtool from /usr/bin/ - apache's automake is old and does not pass the --tag option when executing libtool i could further hack libtool so that its tag inferring logic takes into account full paths, but apache would still be broken (In reply to comment #5) > portage should never remove CC from the environment > > there are multiple issues here, all of which i blame on apache: > - no package should ever execute libtool from /usr/bin/ > - apache's automake is old and does not pass the --tag option when executing > libtool apache uses/needs to use (not entirely sure here) APRs libtool, and i guess other packages depending on APR do so as well, but for some reason i cannot remember installing APRs libtool was broken as well, otherwise we wouldn't have switched to the system libtool not sure what to do here ... i'm not sure i follow ... apache needs APRs libtool, but it can use the system's /usr/bin/libtool ? any package that works with /usr/bin/libtool works with bundling a local version no, apache uses the same libtool as apr (via apr-1-config --apr-libtool), so we use /usr/bin/libtool in apr, otherwise we'd need to install the libtool bundled with apr/generated by eautoreconf so when you say "APRs libtool", you actually mean "the same exact libtool that APR uses" ... so apache and APR use /usr/bin/libtool (In reply to comment #7) > any package that works with /usr/bin/libtool works with bundling a local > version Well, no not really. It blows up horribly and the apr-bundled libtool was already removed for this exact reason (things like Bug 81260). you're mixing up "bundled" i think when i say "bundled" i mean the configure process should be generating a libtool script which the rest of the one package's build system uses. this is how all libtool based packages should work in order for things to work sanely. i am not referring to any package *installing* a libtool script for other packages to utilize *** Bug 264250 has been marked as a duplicate of this bug. *** *** Bug 474586 has been marked as a duplicate of this bug. *** (In reply to SpanKY from comment #11) Eventually, a separate autotoolized package just doing LT_INIT-things would help here, like https://github.com/haubi/host-libtool which I'm using for ncurses and readline in Prefix for the moment: http://prefix.gentooexperimental.org/hg/prefix-tree/diff/c9c7aedd3e4a/sys-libs/ncurses/ncurses-5.9-r02.1.ebuild http://prefix.gentooexperimental.org/hg/prefix-tree/diff/950e40887d8a/sys-libs/readline/readline-6.2_p1-r1.ebuild IMO, sys-devel/libtool should not install /usr/bin/libtool any more (just libtoolize). Instead, we might eventually want to install something like /usr/${CHOST}/bin/libtool - as noone would find /usr/bin/${CHOST}-libtool. However, I could imagine for /usr/bin/libtool to be a wrapper redirecting to proper sth. like /usr/bin/${CHOST}-libtool for cross-compiling and the like... (In reply to Michael Haubenwallner from comment #14) it would help to a degree. the apache packages still probe their internal helper scripts looking for paths, and libtool is just one of the items they extract. the latest versions in the tree should properly cross-compile now and should work under prefix afaict. Is this still the case with apache-2.4? apr-util still pokes apr directly and runs its libtool script: /bin/bash /usr/share/build-1/libtool --mode=compile x86_64-pc-linux-gnu-gcc -pthread -O2 -march=amdfam10 -pipe -g -frecord-gcc-switches -Wimplicit-function-declaration -DHAVE_CONFIG_H -DLINUX -D_REENTRANT -D_GNU_SOURCE -DCPPFLAGS_TEST -I/var/tmp/portage/dev-libs/apr-util-1.5.4-r1/work/apr-util-1.5.4/include -I/var/tmp/portage/dev-libs/apr-util-1.5.4-r1/work/apr-util-1.5.4/include/private -I/usr/include/postgresql-9.4 -I/usr/include/apr-1 -I/usr/include/db6.0 -o buckets/apr_buckets.lo -c buckets/apr_buckets.c && touch buckets/apr_buckets.lo so does apache: /usr/share/build-1/libtool --silent --mode=compile x86_64-pc-linux-gnu-gcc -std=gnu99 -pthread -O2 -march=amdfam10 -pipe -g -frecord-gcc-switches -Wimplicit-function-declaration -DLINUX -D_REENTRANT -D_GNU_SOURCE -DCPPFLAGS_TEST -I. -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/os/unix -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/include -I/usr/include/apr-1 -I/usr/include/db6.0 -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/modules/aaa -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/modules/cache -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/modules/core -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/modules/database -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/modules/filters -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/modules/ldap -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/modules/loggers -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/modules/lua -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/modules/proxy -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/modules/session -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/modules/ssl -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/modules/test -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/server -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/modules/arch/unix -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/modules/dav/main -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/modules/generators -I/var/tmp/portage/www-servers/apache-2.4.12/work/httpd-2.4.12/modules/mappers -prefer-non-pic -static -c unixd.c && touch unixd.lo |