I lied, libbitmap.a does exist.

Confirming this with G450. Downgrade to 4.1.0-0.0.1 helps.
Now I do some recompiling and investigating ...

So I'm back. Recompilation of XFree86-4.1.0-0.5.9.src.rpm does solve the problem for 
me. (If anybody wants athlon optimized rpms - mail me).

To Mr. Harris: there is one bug in ulT1mo-beta-1.0.tar.gz, there are two dirs without 
"execute" permission ...

same behavior confirmed on my install on IBM thinkpad w/ neomagic drivers

seems to be core dumping somewhere..  I have a core file if you're interested..

Same symptoms here after upgrade from 4.1.0-0.0.1 to 4.1.0-0.5.9.
My video card is a Matrox G400.

I just compiled the latest source from CVS from the xf-4_1_0 tag from 
xfree86.org and was able to get X to start up.  However, something happened to 
the Netscape fonts.  They all show up as boxes.  It seems to only affect the 
controls -- so the menus, the text on the toolbars and the selection boxes in 
Bugzilla show up as boxes but the text on the page, and text that I enter in 
text boxes looks OK.

Same here on Riva TNT2

The problem rc5tv reports with Netscape is probably the same as bug
44948 regarding xfs being pickier about leading - characters.

The libbitmap.a problem also seems to affect the i810 driver.  I''m unclear why
the reporter of 44948 got far enough to see a Netscape problem - do only some
drivers reference libbitmap.a?

This bug is due to the string merging patches that were put into gcc breaking
the XFree86 module loader.  In other words, no modules can load.

It is not a problem with any driver, but with the whole release.  It is fixed
in my internal build.

Does this mean that 'rpm --rebuild' off the SRPM will either work or not work,
depending on which release of GCC is used?  What releases are known to
work/break?  Latest RawHide gcc is gcc-2.96-88 - looks like I need to think
about downgrading either XFree86 or gcc, but unsure which I should do....

i can reproduce it, too (with nvidia tnt2)

after recompiling qith gcc-2.96-88 it is working,
but there is now a problem with resolution greater than 1024x768:
on the right side of the screen, there is a vertical bar (about 50pixels wide)
with totally wrong pixels (with nv and nvidia driver)

If you rebuild with gcc that merges strings across entire binaries, you
need to build with -fno-merge-constants

*** Bug 45246 has been marked as a duplicate of this bug. ***

Reopening this until the packages are made available..

*** Bug 46431 has been marked as a duplicate of this bug. ***

4.1.0-0.8.6 in rawhide is the good stuff.

I am trying to upgrade to this version using the following RPMS:

	XFree86-4.1.0-0.8.6.i386.rpm
	XFree86-devel-4.1.0-0.8.6.i386.rpm
	XFree86-libs-4.1.0-0.8.6.i386.rpm
	XFree86-xfs-4.1.0-0.8.6.i386.rpm
	Mesa-3.4.2-2.i386.rpm

and I get the following error:

	error: failed dependencies:
	        Mesa >= 3:3.4.2-3 is needed by XFree86-4.1.0-0.8.6
	        libXxf86dga.so.1   is needed by XFree86-4.1.0-0.8.6

It looks like Rawhide is a version behind for Mesa.  (And what is that colon in
the version number?)  I don't know what package contains libXxf86dga.so.1 but
the SRPM looks like -- to my uneducated eyes -- that it will only install it if
BuildExtraSharedLIbs is on but it is off by default.

I see Mesa-3.4.2-3.i386.rpm in Rawhide.  You should get it.

libXxf86dga.so.1 is in XFree86-compat-libs-4.0.3-2.i386.rpm, which is also in
Rawhide.

jik is correct above about the compat package and the Mesa, but to answer
your questions:

Mesa package uses "Epoch" in RPM packaging.  This is because we have
Mesa 3.4.2 for XFree86 4.0.3, and for XFree86 4.1.0, however the Mesa
for 4.0.3 and 4.1.0 are not the same package, and will NOT work with
the other release of XFree86.  So basically Mesa and XFree86 releases
are VERY tightly coupled.  Tight to the point where I have considered merging
Mesa into XFree86, but when I did so it created more problems than it solved.
So, Mesa remains separate at least until XFree86 4.2.0 at which point separate
Mesa will possibly disappear.

This means that we need a way to distinguish Mesa for 4.0.3 and Mesa for
4.1.0.  This is done by giving Epoch 2 for the 4.0.3 package, and Epoch 3
for 4.1.0.  XFree86 4.1.0 is made dependant on having a Mesa that is of epoch 3
which is specified as:   Mesa 3:3.4.2-3  (the 3: specifies epoch 3).

As for the lib DGA dependancy, this was a bug.  I dunno how the package
ended up dependant on dga, but the latest build is not (4.1.0-0.9.0).
The only reason for the new XFree86-compat-libs package is to supply
shared libs for libXv and libXxf86dga so that apps linked to them will
still function.  We no longer ship these libs for reasons listed in
numerous bugzilla reports already to which I don't care to repeat again.
You can query bugzilla for details.  ;o)

Note: Do not reopen closed bug reports with new bug details.  If there is
a new bug, open a new report.

Marking resolved rawhide XFree86-4.1.0-0.9.0

Sorry, the above should read "Do not reopen an old bug report, unless
it is because the old bug exists still.  If you have a new bug, use
a new bug report."  The way I wrote the above is confusing.  ;o)  If you
have an old bug and it is still there, but closed, then by all means,
reopen and supply new info.

OK, I won't re-open this bug report.  

I downloaded Mesa from the beta ftp site instead of the normal ftp one and it is
one release behind (i.e. beta is -2 but ftp.redhat.com is -3).  So, the reason
that I reopened it was because I couldn't verify the bug was fixed. Having
downloaded Mesa....-3, it seems to be fixed.

Your comment about the bug being fixed in 4.1.0-0.9.0.  That was about the
sub-bug that I reported here (and shouldn't have) not the original bug, right? 
Otherwise, I am going to complain about not being able to download it from
either rawhide site.

Yes, it means the dependancy on libXxf86dga is fixed.  It was a buildsystem
glitch of some kind, and all that was needed was a rebuild, which occured
when I built 0.9.0.  For the record: "Fixed RAWHIDE" does not mean "you
can download it this second", but rather it means "you can either get it now,
or it will be in the next update of RAWHIDE".  Shortened "will appear in
future RAWHIDE release".  Versioin numbers supplied, in general mean "Fixed
in release 0.9.0 or greater" for example.  Keeping a bug report open until
it is publically available, when we know something is fixed, means that we
have to constantly monitor the rawhide mirroring, and keep track of its
schedule, which we do not (at least I do not).  It also means I have an open
bug list that is longer and I will get less work done.

When I know a bug is fixed, I close it.  If a user uses the release I say
it is fixed in and it is not fixed, then that is what REOPEN is for.  The
process is much smoother this way.  Hope that helps understand the
admitedly semi-confusing bug states.  We are discussing internally some
possible bugzilla enhancements to improve this though.

Take care,
TTYL