I think dev-libs/ode fails to link at some point. Not entirely sure why. Here is some output from the failure: gcc -o ode/test/test_chain2.exe ode/test/test_chain2.o lib/libode.a lib/libdrawstuff.a -L/usr/X11R6/lib -L/usr/X11/lib -L/usr/lib/X11R6 -L/usr/lib/X11 -lX11 -lGL -lGLU -lm lib/libode.a(collision_kernel.o)(.gnu.linkonce.d._ZTV6dxGeom+0x10): undefined reference to `__cxa_pure_virtual' lib/libode.a(collision_space.o)(.gnu.linkonce.d._ZTV7dxSpace+0x20): undefined reference to `__cxa_pure_virtual' lib/libode.a(collision_space.o)(.gnu.linkonce.d._ZTV7dxSpace+0x24): undefined reference to `__cxa_pure_virtual' lib/libode.a(collision_space.o)(.gnu.linkonce.d._ZTV7dxSpace+0x28): undefined reference to `__cxa_pure_virtual' lib/libdrawstuff.a(drawstuff.o)(.text+0x243): In function `Image::Image[not-in-charge](char*)': : undefined reference to `operator new[](unsigned)' lib/libdrawstuff.a(drawstuff.o)(.text+0x3d3): In function `Image::Image[in-charge](char*)': : undefined reference to `operator new[](unsigned)' And many more undefined references with libdrawstuff. Here is my GCC version. [root@Evergreen] app-games # gcc --version gcc (GCC) 3.2.2
Looks to me at first glance as though Makefile invokes gcc to compile C++ code (g++ might fare better). Will look into it shortly. George
George, In order to not waste your time further. I have found that recompiling X seemed to solve the problem. I upgraded from gcc 2.95 a short time before trying to install ode. The recompilation of X caused it to compile fine. Thanks for the cursory glance though.
Hi Holden. Thanks for report. Closing the bug now.. George
It seems that emerging XFree doesn't always solve this problem. Perhaps this is another bug, but I'm not sure, so I think it should be re-opened. Below is the error from portage/gcc: gcc -c -Wall -fno-rtti -fno-exceptions -Wall -fomit-frame-pointer -ffast-math -Iinclude -DdNODEBUG -O2 -o ode/src/timer.o ode/src/timer.cpp ode/src/timer.cpp:109:17: missing terminating " character ode/src/timer.cpp: In function `void getClockCount(long unsigned int*)': ode/src/timer.cpp:110: error: parse error before `movl' ode/src/timer.cpp:112:28: missing terminating " character ode/src/timer.cpp:119:17: missing terminating " character ode/src/timer.cpp: In function `void serialize()': ode/src/timer.cpp:120: error: parse error before `$0' ode/src/timer.cpp:121:14: missing terminating " character make: *** [ode/src/timer.o] Error 1 !!! ERROR: dev-libs/ode-0.035 failed. !!! Function src_compile, Line 26, Exitcode 2 !!! (no error message)
Hi Akshay. I see you have -ffast-math in your CFLAGS. This is a very unstable flag - quite often it causes grief, especially in math-related apps (some of which actually do use the "omitted" checks and features). Please try emerging the package without this flag. (You might try playing with -fno-rtti and -fno-exceptions as well). If that doesn't help, please reopen the bug and post the output of emerge info. George
Actually, my make.conf file defines it as: CFLAGS="-march=i686 -O3 -pipe -fomit-frame-pointer" portage did it's own thing to add -ffast-math. Should I edit the build?
Now I'm just a little confused...now that I've gone through some of the makefile stuff. Here are my comments: reading the Makefile file in ODE, it states: # NOTE: the '.c' files are pregenerated sources, and must be compiled with # -O1 optimization. that is why the rule for .c files is a bit different. # why should it be compiled with O1? it is numerical code that is generated # by fbuild. O1 optimization is used to preserve the operation orders that # were discovered by fbuild to be the fastest on that platform. believe it or # not, O2 makes this code run much slower for most compilers. Then reading config/makefile.unix-gcc: C_FLAGS=-c -Wall -fno-rtti -fno-exceptions -Wall ... ifeq ($(BUILD),release) OPT=2 C_FLAGS+=-fomit-frame-pointer -ffast-math endif which is why I end up with the gcc line in my first comment, and also why nothing of my own CFLAGS is used. Is this how it should be? And it seems as though the comments within ODE collide with what they actually do. I would think taht OPT=1 would be here, not 2. Any ideas? Also, I don't have a drop down to re-open this bug. I can only "Leave as RESOLVED INVALID"
Hi Akshay. Thanks for the details! The behaviour you spotted (ignoring CFLAGS and other stuff) is due to the way package is assembled - it uses a hand-written Makefile, which uses ${C_FLAGS} for building the binaries (!!) rather than standard way with autotools. Thus all local settings are getting thrown out :(. But then I am able to compile and install the package Ok here (and apparently package defaults are working fine for many people). However in the region corresponding to where you are getting an error I only get a few warnings: gcc -c -Wall -fno-rtti -fno-exceptions -Wall -fomit-frame-pointer -ffast-math -Iinclude -DdNODEBUG -O2 -o ode/src/timer.o ode/src/timer.cpp ode/src/timer.cpp:109:17: warning: multi-line string literals are deprecated ode/src/timer.cpp:119:17: warning: multi-line string literals are deprecated ode/src/timer.cpp:109:17: warning: multi-line string literals are deprecated ode/src/timer.cpp:119:17: warning: multi-line string literals are deprecated Most likely this behavior is due to the difference in gcc versions used. Please post an output of your emerge info. Few more things to try: 1. Just try it again - I did cosmetic touches to the sed construct in the ebuild, to make it more readabla and "standard". I also added sed to replace C_FLAGS with CFLAGS to make it use local settings. 2. Correspondingly try removing -pipe from your CFLAGS. Sometimes this option makes gcc mistreat certain formatting... Note: I tested it with varietty of flags, it seems to be pretty tolerant. I created a new ebuild -r1, to keep the present version intact as it seems to be working for many people. The -r1 version is keymasked, please use it for your tests. Holden: can you also please take a look at the -r1? I would appreciate some testing, as the chages I made are not completely trivial. George
I tried to emerge the old ebuild and the -r1 with various CFLAG settings. The old one gave me the same errors since it was still using it's own C_FLAG, and the new one also failed with the same errors regardless of the CFLAGS I set (last one I tried was CFLAGS="-march=i686 -O1"). I know that gcc-3.3 has caused quite a few things to fail (kernel), so it is probably that, but I don't know the asm command in C, so I don't know how to edit the c file. Could I just replace the unclosed multi-line quotes with \n? Or execute asm multiple times? Below is my emerge info: Portage 2.0.48-r1 (default-x86-1.4, gcc-3.3, glibc-2.3.1-r2) ================================================================= System uname: 2.4.20-gentoo-r5 i686 Celeron (Coppermine) GENTOO_MIRRORS=" ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo http://csociety-ftp.ecn.purdue.edu/pub/gentoo/" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb:/usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/local/portage" USE="oss 3dnow arts avi crypt encode libg++ libwww mikmod mpeg nls pdflib xml2 xv zlib gtkhtml gdbm berkdb slang readline bonobo tcltk java guile sdl gpm tcpd pam ssl python esd imlib oggvorbis gtk motif opengl mozilla cdr X gnome -kde alsa cups apm qt fbcon jpeg tiff gtk2 gif mmx ncurses quicktime png perl spell svga x86 usb xmms truetype dvd mysql" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=i686 -O3 -pipe -fomit-frame-pointer" CXXFLAGS="-march=i686 -O3 -pipe -fomit-frame-pointer" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
Hi Akshay. This indeed seems to be a gcc-3.3 issue. Well, gcc-3.3 is not really "ready" yet, - there are quite a few more issues caused by this version in portage tree (gentoo is very good in spotting any inconsistensies and bad code - a double edged sword :/). We can only hope this gets fixed soon in the upstream.. Meanwhile you can try using another gcc version for building ode. Unfortunately, since 3.3 is supposed to be binary compatible with 3.2 it is slotted at 3.2. Therefore you if you emerge gcc-3.2.3, some files will be overwritten :(. However the rtl stuff gets installed under different dir (inside /usr/lib/gcc-lib/i686-pc-linux-gnu/), so you should be able to select the specific version of gcc to use by passing an appropriate -V flag. You can emerge gcc-3.3 afterwards to be sure that gcc is consistent with the rest of the system. Alternatively you can emerge gcc-2.95.3. It is SLOTted differently and you will be able to use gcc-config to switch back and forth without having to remerge gcc. I checked ode again - it builds fine with 2.95.3 as well.. Yet another option is to try dev-lang/tcc.. Or icc.. If that works I can add tcc/icc support to ebuild when I return a week later. George
Thanks for the help. I ended up installing gcc-2.95 and used gcc-config to switch profiles and it seems to be working fine now. I suspect all will compile with no problems, and I will switch back to gcc-3.3 in the end. Hope gcc-3.3 stabalizes, and people make the appropriate changes to their code. Again. Thanks.
Hi Akshay Thanks for the report. Unfortunately it doesn't look like I will be able to do much about this issue until the package is fixed upstream. I will close this bug for now. I added pkg_setup which checks gcc version used and if it (major part) matches 3.3 will output a short explanation mentioning gcc-config and referencing this bug (and then dies). You might want to test.. George
Looks like there's a fix here: http://q12.org/pipermail/ode/2003-July/009240.html
new version in portage and seems to build Ok. Reclosing the bug
