checking if STL implementation is SGI like... no checking if STL implementation is HP like... no configure: error: "no known STL type found - did you forget to install libstdc++-devel ?" !!! ERROR: The ebuild did not complete successfully. !!! Function kde_src_compile, Line -4738, Exitcode 1 !!! died running ./configure, kde_src_compile:configure !!! emerge aborting on /usr/portage/kde-base/arts/arts-1.0.2-r1.ebuild . manually emerging dev-libs/STLport didn't help, I rm'ed /var/cache/edb/dep/* , I deleted the distfile, I emerge --clean, still errors with this. If I manually run ./configure it works fine (detects STL with no error). I looked breifly at the class but didn't see any problems. This is on 2 machines for me I have same problems, others have no problems at all.
What does config.log say about the error when run with emerge?
Created attachment 2479 [details] kdelisb-config.log This is log from kdelibs, which exact sme thing happens for
in the config.log I get from running manually, the step fails at #define HAVE_SGI_STL 1 Also, this was not a dependancy of this build (STL), I forgot to mention that before. (I emerged manually)
This isn't an STL problem; you're missing the powerpc-unknown-linux-gnu-g++ symlink. Look at config.log, every test that has a compilation in it fails because the symlink can't be found and the stl test is the first test that requires compilation. Another $CHOST-g++ symlink issue then, create the symlink, check taht it fixes things and investigate where it went to in the first place ;-)
You were right, symlink was missing, I replaced it, but the test still fails. This also doesn't explain why manually running ./configure (even with same options) works fine. I am trying to track down why the symlink went missing yet again (I suspect portage removed it somehow). Still have failure for arts + kdelibs with same problem about STL from ebuilds, but work when doing it manually.
Created attachment 2608 [details] Configure falure dump I hope this helps, It appears to be breaking when checking for STL
OK, please give me the new config.log with the symlink in place, let's see what is says now. Christopher, please do the same.
Created attachment 2623 [details] config.log after adding g++ symlinks adding symlinks got me past STL problem, but now fails to find qt(>=3.0.2), I have qt3.0.5. Any suggestions
I also manualy ./conifure, no problems then.
Realized that I did not run ./configure with the same options that emerging used. ./configure (works) Using options from emerge, breaks coinfigure at qt-mt again. ./configure --enable-alsa --prefix=/usr/kde/3 --host=i686-pc-linux-gnu --with-x --enable-mitshm --with-xinerama --with-qt-dir=/usr/qt/3 --disable-dependency-tracking --enable-mt --disable-debug --without-debug (does not work) removing --host=i686-pc-linux-gnu, allows configure to finish without error ./configure --enable-alsa --prefix=/usr/kde/3 --with-x --enable-mitshm --with-xinerama --with-qt-dir=/usr/qt/3 --disable-dependency-tracking --enable-mt --disable-debug --without-debug (works)
I reemerged gcc 2.95.3, downgrading from gcc 3.0.4 (I did not Know that I was even using this). Now the package configures with all options, and is building now
Reemerging gcc 2.95.3 appears to have solved the buildproblem. I hope that this info isof some use. Thanks for the help Chris
OK, let's organize this: 1. It obviously shouldn't be using --host=i686-pc-linux-gnu on ppc. The --host= parameter in kde ebuilds is actually --host=${CHOST}. Make sure yours is ppc not i686-pc? 2. You shouldn't have been using gcc 3.0.x. It's either 2.x or 3.1.x.
Dan.. I'm the one on ppc, and I didn't sumbit the logs yet
Ah ok, I thought Christopher was on ppc also.
Hi Dan i was unable to reproduce this on my new system, so I will assume that something was strange on my old system setup, seems to work now. I'll close this bug as I can no longer reproduce :) Gerk
WEll this has now been reported on other PPC machines as well, I will have owen work on this with you Dan.
OK, look in configure.log again I suppose?
I don't have the machine to reproduce this now, I think it's a gcc 2.95.3 issue, and it seems owen can't reproduce or doesn't care to. I will close this for now.
