Please see the following links to find out more, I
Please see the following links to find out more, I´m really confused with this libtool/non-libtool bug... :-(
Steps to Reproduce:
1. emerge mod_jk from Bug 19094
Emerge without the infamous "libtool: compile: unable to infer tagged
Portage 2.0.51-r15 (default-linux/x86/2004.3, gcc-3.3.5,
glibc-126.96.36.19940808-r1, 2.6.9-gentoo-r13 i686)
System uname: 2.6.9-gentoo-r13 i686 AMD Athlon(tm) XP 2200+
Gentoo Base System version 1.6.9
Python: dev-lang/python-2.3.4-r1 [2.3.4 (#2, Feb 7 2005, 10:01:40)]
sys-devel/autoconf: 2.59-r6, 2.13
sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4
CFLAGS="-O3 -march=athlon-xp -pipe -fomit-frame-pointer"
CONFIG_PROTECT="/etc /opt/glftpd/etc /usr/kde/2/share/config
/usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=athlon-xp -pipe -fomit-frame-pointer"
FEATURES="autoaddcvs autoconfig ccache collision-protect distlocks makecheck
USE="x86 3dnow acpi apache2 apm arts avi berkdb bitmap-fonts crypt encode f77
fbcon firebird font-server foomaticdb fortran gd gd-external gdbm gif gpm gtk2
imap imlib innodb java jpeg junit libg++ libwww mad maildir mikmod mmx motif
mpeg mysql ncurses nls nptl odbc oggvorbis opengl oss pam pdflib perl png pnp
postgres python quicktime readline sasl sdl slang snmp socks5 spell sqlite sse
ssl svga tcpd tiff truetype truetype-fonts type1-fonts unicode xml xml2 xmms xv
Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
OK, I can confirm that libtool included with apache2 causes this bug. I managed to fix this this way:
1. cd /usr/lib/apache2/build/libtool
2. mv libtool libtool.bak
3. ln -s /usr/bin/libtool /usr/lib/apache2/build/libtool
4. emerge mod_jk
Now it emerges without any problems.
You do know mod_jk is no longer in the tree, right? Regardless, marking ASSIGNED.
OK, mod_jk is not YET in the tree, it
OK, mod_jk is not YET in the tree, it´s mod_jk2 that is phased out. ;-)
Exactly. It helps to to give a package that's actually in the tree in a bug's reproduction steps, though. ;-)
Slight fo-paux on my part - this bug seems to have been fixed upstream (at least, libtool is no longer installed by default with 2.0.52, and there's no gentoo-rolled patch applied that removes it). Resolving bug as LATER while awaiting confirmation from upstream (/me looks at chipig ;-)
reopened to resolve correctly
fix in cvs now
/kick beu for giving me wrong bug ids! ;)
Apologies for the above! ;-)
Also, pardom my ignoreance; Paul Querna just refreshed my memory (thanks for that, btw :-), and libtool _is_ still bundled, it's just no longer installed by the stable apache ebuilds in the tree, but instead by apr (~arch & p.mask'ed - which I'm running now ;-)
Lastly, to reply to your request of removing the bundled libtool, that's a no-can-do I'm afraid. It's needed to ensure the ABI, i.e., compatability, with other apache modules. Resolving WONTFIX - sorry.
I was looking into this earlier today before I had to leave for work. With the ABI compatibility thing, since everything is compiled from source, do we have to match upstreams libtool, or can we modify apr so that is uses the existing libtool for it's builds?
Well, I needed mod_auth_mysql today, this one also compiles with libtool and had no problems with the symlinked /usr/bin/libtool. Maybe a symlimk would do. What do you think?
*** Bug 120585 has been marked as a duplicate of this bug. ***
Reopening wrt Bug 120585, I'm also still not convinced that apr should install it's own libtool.
chipig: being upstream, any comment on why an external libtool would not work? how difficult would it be to rip libtool out of apr and apr-util so we can use one that's already on disk?
APR 1.2.7-r1 should now be using the libtool already installed on the system instead of using the bundled libtool. I have tested rebuilding the apache stack and a few modules, and everything seems to work. More testing would be appreciated.
It is a good idea to recompile apache after you update to this APR, though it's not required until you want to install/update an apache module (the compile of the module will fail due to hardcoded libtool locations in apache). Other software that depends on APR may have similar issues. I see this as a non-issue currently because everything apache 2.2.x related is currently hard masked.
Is this an issue with newer versions of apr?
Why I ask is that because the logic in apr to use system libtool is broken in itself, but currently removing that logic all together from the ebuild (i.e. let apr use its own libtool-script and install that) seems to work here (after rebuilding apr, apache and building mod_jk wich according to bugreports should fail without system libtool).
So is there a fail-safe way to test if this is a problem or if I have just a system which you can call "worksforme" upon?
Why I want to redo this logic is because the current apr-logic fails with anything but bash as /bin/sh, may fail if you change *FLAGS (if I understand the buildsystem right) between the merge of apr and apache/any mod_* and I am trying to find out which way to go forward.