I have installed Octave 2.1.73 and octave-forge 2006.03.17 using GCC 4.1.1 on two systems: my desktop and my laptop. On both systems Octave reports unresolved symbols on certain built-in Octave functions (see below). This problem does not occur on a Debian unstable shell I have access to. This problem is also being discussed on the Gentoo Forums at http://forums.gentoo.org/viewtopic-t-499860.html. fsolve ====== fsolve appears broken on both systems: octave:1> fsolve error: /usr/libexec/octave/2.1.73/oct/i686-pc-linux-gnu/fsolve.oct: undefined symbol: _ZNK12octave_value12double_valueEb min and max =========== min and max are broken only on my desktop system, but with a similar error: octave:1> min error: /usr/libexec/octave/2.1.73/oct/i686-pc-linux-gnu/min.oct: undefined symbol: _ZNK12octave_value5numelEv octave:1> max error: /usr/libexec/octave/2.1.73/oct/i686-pc-linux-gnu/max.oct: undefined symbol: _ZNK12octave_value5numelEv
Created attachment 97517 [details] emerge --info output for my laptop
Created attachment 97518 [details] emerge --info output for my desktop
(In reply to comment #2) > Created an attachment (id=97518) [edit] > emerge --info output for my desktop > Unfortunately, I can't reproduce this here. Please recompile octave with only -march=athlon-xp -O2 (particularly, get rid of the -fvisibility-inlines-hidden) and see if that helps.
Works with CFLAGS="-march=athlon-xp -O2 -pipe" CXXFLAGS="${CFLAGS}". However, this is the first package I've found to break with my CFLAGS, which AFAIK aren't even "over-riced" (comments?). Should the ebuild be modified to filter out "bad" CFLAGS?
I had this same problem. I added "filter-flags -fvisibility-inlines-hidden" to Octave's ebuild, recompiled, and now everything works smoothly. The working CFLAGS I compiled Octave are CFLAGS="-march=athlon-xp -O2 -pipe -falign-functions=64 -ftracer -fomit-frame-pointer".
(In reply to comment #4) > Works with CFLAGS="-march=athlon-xp -O2 -pipe" CXXFLAGS="${CFLAGS}". However, > this is the first package I've found to break with my CFLAGS, which AFAIK > aren't even "over-riced" (comments?). Should the ebuild be modified to filter > out "bad" CFLAGS? > My comment here would be: Please do NOT use -fvisibility-inlines-hidden unless you know what you are doing and you are willing to deal with issues like this. -fvisibility-inlines-hidden breaks even standard compliant C++ code. This flag causes a symbol that the compiler inlined during generation of shared objects to be "hidden". On the good side, this can significantly speed up loading of shared objects. On the downside, since the decision of what functions to inline is completely up to the compiler, if during the compilation of an application that links against such a shared object, the compiler for some reason decides not to inline a particular function any more the linker will not find the symbol since it is hidden in the shared object. This is exactly what happened in your case. To get this "hiding" to work one had to jump through quite a few additional hoops like the kde folks with the kdehiddenvisibility stuff. Even there I am not sure if it works 100% all the time. The reason why you didn't experience many problems so far is pure luck and also due to the fact the there are not too many C++ packages in portage where this behavior potentially could show up. The filtering of CFLAGS in ebuilds should only be used in cases where common "good" CFLAGS (-O3 or -Os, say) are known to cause trouble, e.g., on a particular arch. Their purpose is not to filter every potentially bad CFLAG that gcc offers and of which there might be quite a few, -fvisibility-inlines-hidden included. Please let me know if you have any additional questions; I'll close this as invalid since it is not a bug per se. Best, Markus the compil
