| Summary: | xfree-4.2.0-r12 module loader broken with gcc 3.1 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Andreas Simon <andreas.w.simon> |
| Component: | [OLD] GCC Porting | Assignee: | Martin Schlemmer (RETIRED) <azarah> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
<charzilla> I just compiled X successfully with gcc3.1 with -fno-merge-constants <lostlogic> good deal, which x ebuild and are you now clean of that libbitmap.a issue? <charzilla> I am using r12... and I had the libbitmap.a issue before but not now <lostlogic> excellent, thanks for the info! apparently the compiler option -fno-merge-constants fixes it, needs more testing, ssrit you out there? whoops, apparently ssrit found the fix, Azarah, can put this in the X ebuild somehow? Will be added to compile flags if gcc is not version 2.95.3. I believe the solution for this was overly conservative? All of the existing
gentoo ebuilds for 4.2 series Xfree resolve this by filtering "-march=pentium4"
and changing it to pentium3 (instead of the recommended -fno-merge-constants,
although there may have been a reason for that decision at the time).
The problem: This filter will persist for ANY future version of GCC, but I think
the problem is fixed in 3.2 which is the current gentoo supported ebuild. I
manually built Xfree with -march=pentium4 -mcpu=pentium4 and have no problems
loading modules.
It may be a better solution to apply the filter only in the case of "`gcc
-dumpversion`" == "3.1". That is, if somebody can independently verify that 3.2
compiles correctly now ("worksforme").
Below is the code for that section. It change pentium4 to pentium3, as
the pentium4 optimizations have problems with sse2/whatever.
The -fno-merge-constants are still added for gcc 3.1.
Check the bug in the comment. I also did get another for gcc-3.2 if you really
want that. If it builds fine for you with -march=pentium4, great.
Its two different bugs entirely. If you have an issue with changing pentium4
to pentium3, open a bug for that. Even better, If you can get me 5-10 people
to test with gcc-3.2, gcc-3.2.1 and gcc-3.2.1-r[16], we might think about
removing it for now.
For me, 3.2.1 still fails some times, and it still fail with the same type
of thing for mozilla, so until gcc team get their act together, I really do
not need another 20 bugreports about gcc miscompiling.
--------------------------------------------
# Should fix bug #4189. gcc-3.x have problems with -march=pentium4
# and -march=athlon-tbird
replace-flags "-march=pentium4" "-march=pentium3"
replace-flags "-march=athlon-tbird" "-march=athlon"
# Without this, modules breaks with gcc3
if [ "`gcc-version`" = "3.1" ]
then
export CFLAGS="${CFLAGS} -fno-merge-constants"
export CXXFLAGS="${CXXFLAGS} -fno-merge-constants"
fi
Just to chime in and help, as it looks like you guys needed people to test it..
Using gcc 3.2.3 (gcc (GCC) 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r3, propolice)) I was able to compile and am successfully using xfree-4.3.0-r3, having commented out the replace-flags line for pentium4 optimizations.
$ grep pentium4 /usr/portage/x11-base/xfree/xfree-4.3.0-r3.ebuild
# Should fix bug #4189. gcc-3.x have problems with -march=pentium4
#replace-flags "-march=pentium4" "-march=pentium3"
$ egrep '^CFLAGS' /etc/make.conf
CFLAGS="-O3 -mcpu=pentium4 -march=pentium4 -funroll-loops -pipe"
$ grep -i pentium /proc/cpuinfo
model name : Mobile Intel(R) Pentium(R) 4 - M CPU 2.40GHz
$ uname -srvmpio
Linux 2.6.1 #4 Fri Jan 9 15:35:57 PST 2004 i686 Mobile Intel(R) Pentium(R) 4 - M CPU 2.40GHz GenuineIntel GNU/Linux
I did not find any of the error messages like those referenced in the ticket.
|
After the addition of XFree86-4.2.0-Suse-Updates.patch and other patches on June 25th 2002 building xfree 4.2.0-r12 with gcc 3.1 results in a broken module loader. This is an old issue, which was fixed in 4.2.0 but seems to be resurrected by those new patches. What happens? A new feature of gcc (constant merging) which is activated by default produces elf sections, which the module loader of Xfree does not support. So no x11 module can be loaded. Thus X11 cannot be started. One gets error messages like the following when trying to start X11: ... > (II) Loader running on linux > (II) LoadModule: "bitmap" > (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a > Not loading .rodata.str1.1 > Not loading .rodata.str1.32 > Not loading .rodata.cst8 > Not loading .rodata.str1.1 > Not loading .rodata.str1.32 > Not loading .rodata.str1.1 > Not loading .rodata.cst8 > Not loading .rodata.str1.1 > Not loading .rodata.str1.32 > Not loading .rodata.str1.1 > (II) Symbol .LC2 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is > unresolved! > Symbol .LC2 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is > unresolved! ... I found two references for this on the xpert mailing list. As I said, that issue was fixed but reappeared after the addition of those new patches on 25 June. (BTW, the ebuild release number was NOT increased although the package was dramatically changed!) The old workaround for this issue is to compile XFree with "-fno-merge-constants" when using gcc > 2.96. It would be sufficient to only build the x11 modules with "-fno-merge-constants" but that would require more changes to the build script and I've only tested building whole x11 with that compiler flag. I am not the only one who encountered this issue. Serveral people on #Gentoo yesterday had the same error and were all able to fix this after adding "-fno-merge-constants" to their CFLAGS. Note, this error does not appear with gcc 2.95. IMHO it would help a lot of people trying Gentoo 1.3x to add this flag automatically in the ebuild. Cheers.