Bug 44954 - XFree86 4.1.0 fails with unresolved symbols can't load libbitmap.a
Summary: XFree86 4.1.0 fails with unresolved symbols can't load libbitmap.a
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 1.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
: 45246 46431 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2001-06-19 06:16 UTC by Stephen Rasku
Modified: 2005-10-31 22:00 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-17 05:42:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Stephen Rasku 2001-06-19 06:16:48 UTC
Description of Problem:

I just upgraded to the latest rawhide version of X and it crashes every time I start it up.

How Reproducible:


Steps to Reproduce:
1. startx
2. crash

Actual Results:

Crash.  Here's the log:

XFree86 Version 4.1.0 (Red Hat Linux release: 4.1.0-0.5.9) / X Window System
(protocol Version 11, revision 0, vendor release 6510)
Release Date: 2 June 2001
	If the server is older than 6-12 months, or if your card is
	newer than the above date, look for a newer version before
	reporting problems.  (See http://www.XFree86.Org/FAQ)
Build Operating System: Linux 2.2.17-8smp i686 [ELF] 
Module Loader present
(==) Log file: "/var/log/XFree86.0.log", Time: Mon Jun 18 22:53:03 2001
(==) Using config file: "/etc/X11/XF86Config-4"
Markers: (--) probed, (**) from config file, (==) default setting,
         (++) from command line, (!!) notice, (II) informational,
         (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) ServerLayout "XFree86 Configured"
(**) |-->Screen "My Screen" (0)
(**) |   |-->Monitor "E95"
(**) |   |-->Device "ATI|Rage 128 RF"
(**) |-->Input Device "Logitech Mouse"
(**) |-->Input Device "IBM Keyboard"
(**) Option "XkbLayout" "us"
(**) XKB: layout: "us"
(==) Keyboard: CustomKeycode disabled
(**) FontPath set to "unix/:7100"
(==) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(==) ModulePath set to "/usr/X11R6/lib/modules"
(**) Option "BlankTime" "5"
(**) Option "StandbyTime" "10"
(**) Option "SuspendTime" "20"
(**) Option "OffTime" "30"
(--) using VT number 7

(II) Open APM successful
(II) Module ABI versions:
	XFree86 ANSI C Emulation: 0.1
	XFree86 Video Driver: 0.4
	XFree86 XInput driver : 0.2
	XFree86 Server Extension : 0.1
	XFree86 Font Renderer : 0.2
(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!
Symbol .LC0 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC9 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC19 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC71 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC71 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC71 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC3 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC0 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC67 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC0 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC0 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC0 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC0 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC0 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC0 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC0 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC0 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC1 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC0 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!
Symbol .LC0 from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved!

Fatal server error:
Caught signal 11.  Server aborting

When reporting a problem related to a server crash, please send
the full server output, not just the last messages.
This can be found in the log file "/var/log/XFree86.0.log".
Please report problems to xfree86@xfree86.org.

Expected Results:

Smoothly Operating X Server.

Additional Information:
The libbitmap.a file doesn't exist.  This looks like it might be a package dependency issue.  I am running an ATI Rage 128 Xpert.  The version 
of X that I downloaded was XFree86-4.1.0-0.5.9.i386.rpm

Comment 1 Stephen Rasku 2001-06-19 06:41:07 UTC
I lied, libbitmap.a does exist.

Comment 2 martin.macok 2001-06-20 13:54:32 UTC
Confirming this with G450. Downgrade to 4.1.0-0.0.1 helps.
Now I do some recompiling and investigating ...

Comment 3 martin.macok 2001-06-20 15:04:50 UTC
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 ...

Comment 4 Paul Lindner 2001-06-21 00:28:00 UTC
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..

Comment 5 Olivier Baudron 2001-06-21 16:32:38 UTC
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.

Comment 6 Stephen Rasku 2001-06-22 20:58:28 UTC
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.

Comment 7 Nicolas Mailhot 2001-06-26 08:53:13 UTC
Same here on Riva TNT2

Comment 8 Valdis Kletnieks 2001-06-29 17:38:17 UTC
The problem rc5tv@home.com 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?

Comment 9 Mike A. Harris 2001-06-29 19:31:12 UTC
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.

Comment 10 Valdis Kletnieks 2001-06-29 20:05:26 UTC
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....

Comment 11 Ronny Buchmann 2001-06-29 22:06:46 UTC
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)

Comment 12 Mike A. Harris 2001-06-29 22:20:52 UTC
If you rebuild with gcc that merges strings across entire binaries, you
need to build with -fno-merge-constants

Comment 13 Mike A. Harris 2001-07-03 01:09:33 UTC
*** Bug 45246 has been marked as a duplicate of this bug. ***

Comment 14 Mike A. Harris 2001-07-03 01:10:52 UTC
Reopening this until the packages are made available..

Comment 15 Mike A. Harris 2001-07-03 01:12:12 UTC
*** Bug 46431 has been marked as a duplicate of this bug. ***

Comment 16 Mike A. Harris 2001-07-12 23:21:41 UTC
4.1.0-0.8.6 in rawhide is the good stuff.

Comment 17 Stephen Rasku 2001-07-17 02:11:31 UTC
I am trying to upgrade to this version using the following RPMS:


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.

Comment 18 Jonathan Kamens 2001-07-17 02:55:06 UTC
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

Comment 19 Mike A. Harris 2001-07-17 03:13:13 UTC
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

Comment 20 Mike A. Harris 2001-07-17 03:15:00 UTC
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.

Comment 21 Stephen Rasku 2001-07-17 05:42:39 UTC
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.

Comment 22 Mike A. Harris 2001-07-17 09:15:43 UTC
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,

Note You need to log in before you can comment on or make changes to this bug.