Caveats and Known Bugs on FC4

From FedoraNEWS.ORG

Written by Rahul Sundaram on 2005-06-30

Caveats

GCC 4 and compatibility

When compiling source that has not yet been fixed to work properly with GCC 4.0 the previous 3.2 version of GCC compiler can be used. It can be installed via

# yum install compat-gcc-32

Many Automake files can be invoked with "CC=gcc32" to use it. You can also export it as a environment variable using the following command

# export CC=gcc32

Also the build process can be configured to use it as follows:

# ./configure --cc=gcc32

• Bugzilla Bug 162217 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162217) – FC4 release notes should mention how to use gcc32

Known bugs and workarounds

Known Bug #1

• Synopsis:

If the installation process crashes with a kernel oops or crash then
you are likely running into a bug with sysinstall which potentially
affects the Southbridge chipsets: 865, 875, 915, 925, 945, 955

• Workaround:

In the installation boot prompt type in some garbage. The
boot process will fail with an error message. Press enter twice to start
the installation process again.

• Bugzilla Bug 159026 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159026) – machine oopses on booting from CD

Known Bug #2

• Synopsis:

Numerous bugs are being reported for FC4 and development of FC4 prior to
that which seem to indicate that the libvgahw.a X server module binary
differs between an FC3 build of the same version of Xorg as the FC4 build.

In other words, when this module is compiled in FC3 it works properly in
FC4, but when it is compiled in FC4 it results in a variety of failures
being reported with a wide range of hardware.

To date, the majority of hardware the problems are being reported on
include all Matrox video hardware, but in particular the G550 has a lot
of reports.  Additionally, Intel i852/i855/i865 and perhaps other Intel
hardware seems to be hit by this problem.  There are a number of other
issues reported for FC4 on other hardware such as Cirrus Logic, and various 
other cards which are seemingly strange and might be related
to this problem also, although that has not yet been investigated.

The issue seems to be x86 specific thus far as nobody has reported the issue
on other architectures yet.

At this point it seems that there are 2 plausible scenarios to explore
the root cause:

1) a compiler bug of some sort that results in invalid code being generated

2) a bug in the X sources which makes invalid assumptions in the C code which 
   result in undefined behavior of which might have worked magically with 
   various compilers previously, but may no longer work the same manner in gcc4

Experimentation has shown that using "-O0" (oh zero) instead of "-O2" for
optimization on x86 seems to avoid the problem, so it seems as if it is
related to compiler optimization although at this point either scenario is
equally plausible and no conclusions can be drawn until a full diagnosis
has been completed and the problem analyzed to the code generation level.

• Workaround:

For those experiencing issues of this nature,  libvgahw.a
X server module from the current FC3 errata release has been updated to following webpage

ftp://people.redhat.com/mharris/libvgahw.a

This should make it easier for some people to test out the module hopefully,
and also have a temporary workaround.

• Bugzilla Bug 161242 (http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161242) – libvgahw.a is broken in FC4, replacing it with FC3's solves the problem

Update the above Bugzilla tracker reports with your comments about success or failure of the workaround with more details if you are experiencing these problem.

There are probably more duplicate issues which have not been found yet, so this would be very helpful if people posted "potential duplicate" ID's here.

Thank you