Summary: | php-5.2.8-r2 build fails after upgrade to gcc-4.3.2-r3 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jan Kohnert <bughunter> |
Component: | [OLD] Unspecified | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | eXt |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | log from configure while trying to build php |
Description
Jan Kohnert
2009-04-20 15:13:38 UTC
Created attachment 188967 [details]
log from configure while trying to build php
Sorry, the file is a bit lenghty, but since I'm not too sure about possibly relevant parts, I just send it complete. The failure is documented at line 9228ff.
Does it die during the configuration stage or does it start building? Can you paste the message from emerge and if possible attach the build log. I've tried building php-5.2.8-r2 with gcc-4.3.3 and I didn't run into any issues. Perhaps your could try a later version (5.2.9-r2 is stable). (In reply to comment #2) > Does it die during the configuration stage or does it start building? Can you > paste the message from emerge and if possible attach the build log. Sorry, I probably should have hade that one more clear. It dies during configure, so it does not even start building. So the title of the bug is maybe a bit misleading. > I've tried building php-5.2.8-r2 with gcc-4.3.3 and I didn't run into any > issues. Perhaps your could try a later version (5.2.9-r2 is stable). Well, I don't even have php-5.2.9-r2 on my system, the last sync is from Friday. Is it that new? OTOH, php-5.2.9 and php-5.2.9-r1, which I do have, are masked ~x86, as well as gcc-4.3.3 and later. If it is not *really* neccessary, I don't want to put ~x86 software on that system. Best regards Jan These are the last configure checks: checking for libedit readline replacement... no checking for readline support... yes checking for tgetent in -lncurses... no checking for tgetent in -ltermcap... no checking for readline in -lreadline... no configure: error: readline library not found * * ERROR: dev-lang/php-5.2.8-r2 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 4459: Called src_compile_normal * environment, line 4578: Called php5_2-sapi_src_compile * environment, line 3500: Called die * The specific snippet of code: * ./configure --prefix=${destdir} --host=${CHOST} --mandir=${destdir}/man --infodir=${destdir}/info --sysconfdir=/etc --cache-file=./config.cache ${my_conf} ${EXTRA_ECONF} || die "configure failed"; * The die message: * configure failed * > Well, I don't even have php-5.2.9-r2 on my system, the last sync is from > Friday. Is it that new? Yes, stable since 2009-04-18. (In reply to comment #4) > configure: error: readline library not found Doesn't seem like it depends on readline, which I think it should. Is readline installed on your system? OK, got the new version, but still the same error: checking for readline support... yes checking for tgetent in -lncurses... no checking for tgetent in -ltermcap... no checking for readline in -lreadline... no configure: error: readline library not found * * ERROR: dev-lang/php-5.2.9-r2 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 4459: Called src_compile_normal * environment, line 4578: Called php5_2-sapi_src_compile * environment, line 3500: Called die * The specific snippet of code: * ./configure --prefix=${destdir} --host=${CHOST} --mandir=${destdir}/man --infodir=${destdir}/info --sysconfdir=/etc --cache-file=./config.cache ${my_conf} ${EXTRA_ECONF} || die "configure failed"; * The die message: * configure failed * And again the same message from configure: configure:105692: checking for tgetent in -lncurses configure:105727: i686-pc-linux-gnu-gcc -o conftest -I/usr/include -march=athlon-xp -O2 -pipe -fomit-frame-pointer -D_GNU_SOURCE -pthread -D_REENTRANT -L/usr/lib -Wl,-O1 conftest.c -lncurses -lpspell -lpq -lpanel -lncurses -lmhash -lmcrypt -lltdl -lldap -llber -lcrypt -lpam -lgmp -lt1 -lfreetype -lpng -lz -ljpeg -ldb-4.5 -lgdbm -lcurl -lbz2 -lz -lpcre -lresolv -lm -ldl -lnsl -lxml2 -lz -lm -lssl -lcrypto -ldl -lcurl -lidn -lssl -lcrypto -lldap -lrt -lssl -lcrypto -ldl -lz -lxml2 -lz -lm -lssl -lcrypto -ldl >&5 /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libstdc++.so.6: undefined reference to `_Unwind_GetIPInfo@GCC_4.2.0' collect2: ld returned 1 exit status configure:105734: $? = 1 I really don't know whats going on here. One thing I know: I *never* had GCC-4.2.X on that machine, as it never went stable. Some additional info: Of course, readline is installed, just reinstalled it and getting the same error. revdep-rebuild is also executed regulary, and does not give any broken libs. Best regards Jan Again me, I just tested the conftest.c program created by configure and searched for the library creating the problem. It turns out to be -lpspell, coming from the aspell package. Unfortunately reinstalling aspell does not resolve the problem, too. I'm pretty much stuck at the moment, any clues? Many thanks Jan OK, new day, new luck. I think I broke the error down to its origin. :-D Building php with USE -spell resolves the failure (of course, then I don't have the spell checking functions...). But there is also another fix (which at least lets the configure test program compile fine): I have to add -lstdc++ if I use -lpspell enabled with USE spell. Anyone out there how can confirm this behavior? (In reply to comment #9) > Anyone out there how can confirm this behaviour? I tried it on amd64 and I can't confirm. I used the same useflags as you do except I had to disable the threads useflag because I was hit by bug 234762. Hey guys, it was a hard way figuring out, what actually happend, but I'm finally done. :-D I was hit by the fact, that some old gcc library files lay under /usr/lib/. Since gcc installes its lib-files in /usr/lib/gcc/$ARCH/$VERSION/ and /lib, but *not* /usr/lib, they never got updated. I don't know where this files came from, they were probably leftovers from the installation process (which the service provider did using an ancient Gentoo install medium). So, the solution simply was: # for file in $(find /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/ -name lib\*); do \ base=$(basename $file); find /usr/lib -maxdepth 1 -name $base -delete; done (followed by revdep-rebuild, of course). I'll close this one. Thanks for all your patience and best regards, Jan (In reply to comment #11) > Hey guys, > > it was a hard way figuring out, what actually happend, but I'm finally done. > :-D > > I was hit by the fact, that some old gcc library files lay under /usr/lib/. > Since gcc installes its lib-files in /usr/lib/gcc/$ARCH/$VERSION/ and /lib, but > *not* /usr/lib, they never got updated. I don't know where this files came > from, they were probably leftovers from the installation process (which the > service provider did using an ancient Gentoo install medium). > > So, the solution simply was: > # for file in $(find /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/ -name lib\*); do \ > base=$(basename $file); find /usr/lib -maxdepth 1 -name $base -delete; done > (followed by revdep-rebuild, of course). > > I'll close this one. > > Thanks for all your patience and best regards, > > Jan > This was my same problem. Thanks for the fix. |