I'm trying to build XFree from development. It fails here:
gcc -m32 -o bitmap -march=athlon-xp -m3dnow -msse -mmmx -mfpmath=sse -Os -fno-strict-aliasing -pip e -ansi -pedantic -Wall -Wpointer-arith -Wundef -L../../exports/lib BitEdit.o CutPaste.o Grap hics.o ReqMach.o Bitmap.o Dialog.o Handlers.o -lXaw -lXmu -lXt -lSM -lICE -lXpm - lXext -lX11 -lm -Wl,-rpath-link,../../exports/lib ../../exports/lib/libXaw.so: undefined reference to `.L91' collect2: ld returned 1 exit status make[4]: *** [bitmap] Error 1 make[4]: Leaving directory `/usr/src/redhat/BUILD/XFree86-4.3.0/xc/programs/bitmap'
Is this the correct list for build issues?
thanks
sean
_________________________________________________________________ Share holiday photos without swamping your Inbox. Get MSN Extra Storage now! http://join.msn.com/?PAGE=features/es
Am Do, den 27.11.2003 schrieb sean darcy um 18:06:
I'm trying to build XFree from development. It fails here:
gcc -m32 -o bitmap -march=athlon-xp -m3dnow -msse -mmmx -mfpmath=sse -Os -fno-strict-aliasing -pip e -ansi -pedantic -Wall -Wpointer-arith -Wundef -L../../exports/lib BitEdit.o CutPaste.o Grap hics.o ReqMach.o Bitmap.o Dialog.o Handlers.o -lXaw -lXmu -lXt -lSM -lICE -lXpm - lXext -lX11 -lm -Wl,-rpath-link,../../exports/lib ../../exports/lib/libXaw.so: undefined reference to `.L91' collect2: ld returned 1 exit status make[4]: *** [bitmap] Error 1 make[4]: Leaving directory `/usr/src/redhat/BUILD/XFree86-4.3.0/xc/programs/bitmap'
Is this the correct list for build issues?
If you build test packages I think so.
thanks
sean
Btw. to set "-march=athlon-xp -m3dnow -msse -mmmx -mfpmath=sse" as gcc 3.3 compiler options the 3dnow, sse, mmx and -mfemath=sse calls are redundant as the -march setting to athlon-xp will choose that all.
Alexander
On Thu, 27 Nov 2003, Alexander Dalloz wrote:
I'm trying to build XFree from development. It fails here:
gcc -m32 -o bitmap -march=athlon-xp -m3dnow -msse -mmmx -mfpmath=sse -Os -fno-strict-aliasing -pip e -ansi -pedantic -Wall -Wpointer-arith -Wundef -L../../exports/lib BitEdit.o CutPaste.o Grap hics.o ReqMach.o Bitmap.o Dialog.o Handlers.o -lXaw -lXmu -lXt -lSM -lICE -lXpm - lXext -lX11 -lm -Wl,-rpath-link,../../exports/lib ../../exports/lib/libXaw.so: undefined reference to `.L91' collect2: ld returned 1 exit status make[4]: *** [bitmap] Error 1 make[4]: Leaving directory `/usr/src/redhat/BUILD/XFree86-4.3.0/xc/programs/bitmap'
Is this the correct list for build issues?
If you build test packages I think so.
thanks
sean
Btw. to set "-march=athlon-xp -m3dnow -msse -mmmx -mfpmath=sse" as gcc 3.3 compiler options the 3dnow, sse, mmx and -mfemath=sse calls are redundant as the -march setting to athlon-xp will choose that all.
Athlon reorders instructions internally anyway, the net result generally being that it makes no difference what CPU instruction scheduling is chosen, as the chip does it's own thing internally.
I'd be kind of surprised if compiling with all those options yields any real world performance gains anyway. Placebo effect perhaps... ;o)
Mike A. Harris wrote:
Athlon reorders instructions internally anyway, the net result generally being that it makes no difference what CPU instruction scheduling is chosen, as the chip does it's own thing internally.
I'd be kind of surprised if compiling with all those options yields any real world performance gains anyway. Placebo effect perhaps... ;o)
The gentoo folks would definitely have you believe otherwise. A friend of mine swears that rebuilding everything using the -march=athlon-xp results in a much more responsive X subsystem.
I would be very curious to see a Fedora installation completely rebuilt xp-only.
Ron
On Fri, 28 Nov 2003 19:26:29 -0800, Ron Kuris wrote:
Mike A. Harris wrote:
Athlon reorders instructions internally anyway, the net result generally being that it makes no difference what CPU instruction scheduling is chosen, as the chip does it's own thing internally.
I'd be kind of surprised if compiling with all those options yields any real world performance gains anyway. Placebo effect perhaps... ;o)
The gentoo folks would definitely have you believe otherwise. A friend of mine swears that rebuilding everything using the -march=athlon-xp results in a much more responsive X subsystem.
The funny thing about the "Gentoo folks" is, their perceived performance improvement is not reproducible by all Gentoo folks. After wasting many hours on recompiling stuff with modified compiler options and a largely different set of build dependencies, not everyone finds the system to be "much more responsive". Those, that do, should attempt at proving performance increases with benchmark studies.
--
Well, what should one do? Download XFree-* srpms, rebuild and reinstall?
michalz
Ron Kuris wrote:
Mike A. Harris wrote:
Athlon reorders instructions internally anyway, the net result generally being that it makes no difference what CPU instruction scheduling is chosen, as the chip does it's own thing internally.
I'd be kind of surprised if compiling with all those options yields any real world performance gains anyway. Placebo effect perhaps... ;o)
The gentoo folks would definitely have you believe otherwise. A friend of mine swears that rebuilding everything using the -march=athlon-xp results in a much more responsive X subsystem.
I would be very curious to see a Fedora installation completely rebuilt xp-only.
Ron
-- fedora-test-list mailing list fedora-test-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-test-list
On Thu, Nov 27, 2003 at 12:06:26PM -0500, sean darcy wrote:
I'm trying to build XFree from development. It fails here:
gcc -m32 -o bitmap -march=athlon-xp -m3dnow -msse -mmmx -mfpmath=sse -Os -fno-strict-aliasing -pip e -ansi -pedantic -Wall -Wpointer-arith -Wundef -L../../exports/lib BitEdit.o CutPaste.o Grap hics.o ReqMach.o Bitmap.o Dialog.o Handlers.o -lXaw -lXmu -lXt -lSM -lICE -lXpm - lXext -lX11 -lm -Wl,-rpath-link,../../exports/lib ../../exports/lib/libXaw.so: undefined reference to `.L91' collect2: ld returned 1 exit status make[4]: *** [bitmap] Error 1 make[4]: Leaving directory `/usr/src/redhat/BUILD/XFree86-4.3.0/xc/programs/bitmap'
Is this the correct list for build issues?
No. If you suspect a bug in the compiler (which this looks like it), find out which libXaw.so object has undefined .L91 symbol and file a bugreport in http://bugzilla.redhat.com/bugzilla/ with the details (gcc command line used to compile that object with .L91 undefined reference (use e.g. nm -u to find out), preprocessed source (add -save-temps to gcc options, rerun it and attach the resulting .i file) and exact gcc version you used).
Jakub