I've been looking through the documentation for sci-libs/cln-1.1.11. It looks like the ebuild isn't setting the "optimal" compile flags as documented. Here's what the documentation says: If you use g++ 3.x, I recommend adding
I've been looking through the documentation for sci-libs/cln-1.1.11. It looks like the ebuild isn't setting the "optimal" compile flags as documented. Here's what the documentation says: If you use g++ 3.x, I recommend adding -finline-limit=1000 to the CXXFLAGS. This is essential for good code. If you use g++ gcc-2.95.x or gcc-3.x , I recommend adding -fno-exceptions to the CXXFLAGS. This will likely generate better code. If you use g++ from gcc-3.0.4 or older on Sparc, add either -O, -O1 or -O2 -fno-schedule-insns to the CXXFLAGS. With full -O2, g++ miscompiles the division routines. If you use g++ older than 2.95.3 on Sparc you should also specify --disable-shared because of bad code produced in the shared library. Also, do not use gcc-3.0 on Sparc for compiling CLN, it wont work at all. If you use g++ on OSF/1 or Tru64 using gcc-2.95.x, you should specify --disable-shared because of linker problems with duplicate symbols in shared libraries. If you use g++ from gcc-3.0.n, with n larger than 1, you should not add -fno-exceptions to the CXXFLAGS, since that will generate wrong code (gcc-3.1 is okay again, as is gcc-3.0). Also, please do not compile CLN with g++ using the -O3 optimization level. This leads to inferior code quality. If you use g++ from gcc-3.1, it will need 235 MB of virtual memory. You might need some swap space if your machine doesnt have 512 MB of RAM.
Uhm, the ebuild shouldn't be setting "optimal" flags, it should honor the user-defined ones in make.conf (unless they break the thing). If it needs some really specific ones, then the Makefile or whatever else it's using should take care of those.
Hi Edward, Thank your very much for your input! I believe this should no longer be an issue with the latest cln and gcc-4.x hence I'll close this bug for now. Please feel free to re-open if you have any additional comments. Thanks, Markus
