Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 81260 - apache2 includes libtool but it should not
Summary: apache2 includes libtool but it should not
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: High major (vote)
Assignee: Apache Team - Bugzilla Reports
: 120585 (view as bug list)
Depends on:
Reported: 2005-02-08 10:07 UTC by Jakub Moc (RETIRED)
Modified: 2014-01-22 21:21 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Moc (RETIRED) gentoo-dev 2005-02-08 10:07:21 UTC
Please see the following links to find out more, I
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2005-02-08 10:07:21 UTC
Please see the following links to find out more, I´m really confused with this libtool/non-libtool bug... :-(

Reproducible: Always
Steps to Reproduce:
1. emerge mod_jk from Bug 19094 

Actual Results:  

Expected Results:  
Emerge without the infamous "libtool: compile: unable to infer tagged
configuration" bug.

Portage 2.0.51-r15 (default-linux/x86/2004.3, gcc-3.3.5,
glibc-, 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)]
dev-lang/python:     2.3.4-r1
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
sys-devel/libtool:   1.5.10-r4
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
sandbox sfperms"
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
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2005-02-08 10:51:17 UTC
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. 
Comment 3 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-02-08 12:05:49 UTC
You do know mod_jk is no longer in the tree, right?  Regardless, marking ASSIGNED.
Comment 4 Jakub Moc (RETIRED) gentoo-dev 2005-02-08 12:13:45 UTC
OK, mod_jk is not YET in the tree, it
Comment 5 Jakub Moc (RETIRED) gentoo-dev 2005-02-08 12:13:45 UTC
OK, mod_jk is not YET in the tree, it´s mod_jk2 that is phased out. ;-)

Anyway, thanks.
Comment 6 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-02-08 16:00:36 UTC
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 ;-)
Comment 7 Benedikt Böhm (RETIRED) gentoo-dev 2005-02-08 17:41:53 UTC
reopened to resolve correctly
Comment 8 Benedikt Böhm (RETIRED) gentoo-dev 2005-02-08 17:42:04 UTC
fix in cvs now
Comment 9 Benedikt Böhm (RETIRED) gentoo-dev 2005-02-08 17:46:31 UTC
/kick beu for giving me wrong bug ids! ;)
Comment 10 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-02-08 18:14:37 UTC
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.
Comment 11 Michael Stewart (vericgar) (RETIRED) gentoo-dev 2005-02-08 20:55:53 UTC
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?
Comment 12 Jakub Moc (RETIRED) gentoo-dev 2005-02-09 00:26:28 UTC
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?
Comment 13 Jakub Moc (RETIRED) gentoo-dev 2006-01-27 16:41:35 UTC
*** Bug 120585 has been marked as a duplicate of this bug. ***
Comment 14 Jakub Moc (RETIRED) gentoo-dev 2006-01-27 16:46:40 UTC
Reopening wrt Bug 120585, I'm also still not convinced that apr should install it's own libtool.
Comment 15 Michael Stewart (vericgar) (RETIRED) gentoo-dev 2006-03-05 13:30:56 UTC
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?
Comment 16 Michael Stewart (vericgar) (RETIRED) gentoo-dev 2006-05-25 20:58:37 UTC
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.
Comment 17 Xake 2010-09-12 15:19:54 UTC
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.