Bug 112804 - Update to glibc-2.3.2-27.9.7 breaks KDE (kdeinit)
Update to glibc-2.3.2-27.9.7 breaks KDE (kdeinit)
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-01 18:54 EST by Date J. Noorlag
Modified: 2007-04-18 13:00 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-06 06:29:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Date J. Noorlag 2004-01-01 18:54:49 EST
Description of problem:

Whe I updated two RH9 boxes with glibc-2.3.2-27.9.7 from
glibc-2.3.2-27.9 using up2date, both boxes had problems running KDE.
When KDE started there was an error message: "Can't start kdeinit;
check your installation". Still KDE came up, but fonts were garbled
and several programs (Mozilla 1.5, up2date) did not run.

Both boxes started life running RH7.2 and were subsequently upgraded
to RH7.3, RH8.0 and RH9. The hardware is very different though:

box #1: homebuilt box based on a Tyan Thunder S2462 motherboard with
two Athlon MP-1500 CPUs; 
box #2: an old Dell XPS-266 with Pentium-II

I was able to recover the Athlon box by downgrading to
glibc-2.3.2-27.9. This made the KDE problem disappear. I did not
recover the Dell box but reinstalled RH9 from scratch (reformatted all
partitions except /home). After the RH9 reinstall I ran up2date to
make RH9 current, including glibc-2.3.2-27.9.7. I noticed that the KDE
problem had disappeared on the Dell box.

Subsequently I diagnosed the Athlon box and found that the problem was
caused by a stale /usr/X11R6/lib/libfreetype.so.6.2 file. I moved this
file (and a stale /usr/X11R6/lib/libfreetype.a file which was also
there) to a temporary directory, reran ldconfig and restarted KDE.
This cleared up the problem.

libfreetype.so.6.2 and libfreetype.a in /usr/X11R6/lib were not owned
by any package. A Google search revealed these files were part of an
old XFree86 package (4.0.3?) and apparently not removed during an
earlier up2date or upgrade session. However, they did not cause
problems until glibc-2.3.2-27.9.7. Details on these file:

-rw-r--r--    1 root     root       309908 Jan 20  2002 libfreetype.a
-rwxr-xr-x    1 root     root       262959 Jan 20  2002 libfreetype.so.6.2

I can provide these files if necessary.

Version-Release number of selected component (if applicable):
glibc-2.3.2-27.9.7

How reproducible:
Always

Steps to Reproduce:
1. Start with a current RH9 (current as of 30-Dec-03) 
2. Have files libfreetype.so.6.2 and libfreetype.a (from XFree86
4.0.3) in /usr/X11R6/lib.
3. Restart KDE. There will be a kdeinit error message.
4. Downgrade (in a console) glibc-2.3.2-27.9.7 to glibc-2.3.2-27.9
5. Restart KDE. KDE now starts fine.
  
Actual results:
kdeinit error during KDE start. Other programs, such as Mozilla and
up2date will not run.

Expected results:
Trouble-free start of KDE.

Additional info:
The following posting in alt.os.linux.gentoo got me on the right track:

http://groups.google.com/groups?q=%22/usr/X11R6/lib/libfreetype.so.6.2+%22/usr/X11R6/lib//libfreetype.a%22&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=OF5ma.2202%24Vh4.1869%40news01.roc.ny.frontiernet.net&rnum=2

Apparently the ldconfig of glibc-2.3.2-27.9.7 is linking to the wrong
libfreetype.so if these files are present in /usr/X11R6/lib, whereas
ldconfig of glibc-2.3.2-27.9 does not. I'm not sure this is a bug in
ldconfig, but it might be prudent to change the glibc-2.3.2-27.9.7
installation script to check for stale libfreetype.so etc. files in
/usr/X11R6/lib.
Comment 1 Jakub Jelinek 2004-01-05 03:11:31 EST
Then this is either a bug in the old XFree86 package that it left
the files around, or in rpm.  Two versions of the library in different
location is certainly a bug.
You can undo the ldconfig change by putting
/lib
/usr/lib
at the beginning of /etc/ld.so.conf and rerunning ldconfig.
ldconfig has been changed so that you can choose where the standard
directories are located in the library search path and to match
behaviour of ldconfigs separate from glibc.  Without that, the system
directories were always first and you couldn't override anything.
Comment 2 Date J. Noorlag 2004-01-05 15:17:14 EST
The change in ldconfig you mention explains my problem. In my
/etc/ld.so.conf there is a line:

/usr/X11R6/lib

near the top. Thus the "old" ldconfig found libfreetype.so.6.2 in
/usr/lib, whereas the "new" ldconfig finds the one in /usr/X11R6/lib.

I seem to remember that a long time ago I compiled and installed
XFree86 4.2 from source (downloaded from www.xfree86.org) . The stale
libraries in /usr/X11R6/lib may be a leftover.

While I can see the utility of the ldconfig change, I would submit
that it might be prudent to include /lib and /usr/lib in
/etc/ld.so.conf, so that the default behavior of ldconfig isn't changed. 
Comment 3 Mike A. Harris 2004-01-06 06:29:15 EST
Our XFree86 packages do not supply any libfreetype.* libraries at
all in any location.  If you are having a conflict with libraries
located in the /usr/X11R6/lib directory, then you have either:

1) At some point in time previously, you have installed XFree86
   binary installation from XFree86.org in tarball format, or
   compiled and installed it yourself from raw source.  This will
   install libfreetype in that location, and RPM will not know
   anything about it, nor will rpm uninstall it or modify it.

or

2) At some point in time you have installed a non-official build
   of XFree86 either in rpm format or not, such as from rawhide,
   or some other rpm repository, which may have conflicted with
   your system.

If the files were managed by rpm however, then they would have
been uninstalled properly, so #2 is only possible if you've used
--nodeps --force or other dangerous rpm commandline options.

If neither of the above situations are the case, then your system
is not a clean OS installation, and may have corrupted rpm database
or something else over time.  If you do a clean OS installation of
Red Hat Linux 9, you will not have any libfreetype in /usr/X11R6/lib,
nor should you have libfreetype in that directory on any previous
official Red Hat Linux OS release, nor with any upgrades, nor OS
to OS upgrades.  All files supplied in the rpm packages, are owned
by the rpm packages in any case, so even if such libraries were
supplied in developmental builds accidentally in the past (they may
have been), they would _definitely_ be removed upon upgrade.

Closing bug as NOTABUG.
Comment 4 Date J. Noorlag 2004-01-06 13:50:36 EST
To refute your first statement:

$ rpm -ql freetype-2.1.3-6 | grep "/usr/lib"
/usr/lib/libfreetype.so.6
/usr/lib/libfreetype.so.6.3.2
/usr/lib/libttf.so.2
/usr/lib/libttf.so.2.3.0

This is on a box with RH9 installed from scratch. Thus the RedHat
XFree86 packages most certainly provide the libfreetype.* libraries
(which they have to, otherwise X wouldn't work). If you meant to say
that the RedHat XFree86 packages never provided libfreetype* in
/usr/X11R6/lib, then I'll accept that.

As I said, I believe that in the past (about 18 months ago) I compiled
Xfree86 4.2 from sources from xfree86.org. This source put
libfreetype* in /usr/X11R6/lib.

My beef is not with your XFree86 packages, but with glibc. When a
package goes from version 2.3.2-27.9 to 2.3.2-27.9.7, then I do would
expect to see only minor changes. I would contend such a minor version
change should not break any system, however badly configured it may
be. It turns out that ldconfig changed the default library search
order. This I believe is a major change and it should not have been
implemented in the way it was. It broke two of my systems and from
Google I don't think I was the only one. I think that either the
ldconfig change should have been deferred or /etc/ld.so.conf should
have been changed as well to ensure the previous library search order
was maintained.

On more note on XFree86: since the official XFree86 sources put
libfreetype.* in /usr/X11R6/lib, you may want to consider to have your
rpm check for this. When you do things differently from the folks who
officially support XFree86, you should not ignore the potential
consequences for your customers.
Comment 5 Mike A. Harris 2004-01-06 17:20:26 EST
> This is on a box with RH9 installed from scratch. Thus the RedHat
> XFree86 packages most certainly provide the libfreetype.* libraries

What you've shown above, is that you have the freetype library
installed, from the "freetype" rpm package, which has absolutely
nothing to do with XFree86.  freetype is a standalone font
library http://www.freetype.org which is included with Red Hat
operating systems as many pieces of software directly use freetype,
including XFree86 and others, however XFree86 is not the only
piece of software that uses freetype.  Our freetype package is _not_
part of XFree86 packaging, but is a separate standalone package,
as you've shown above.  XFree86 components do indeed require
libfreetype to be present on the system during compile time and
runtime, however there is absolutely no requirement whatsoever
that XFree86 supply its own libfreetype.

XFree86 comes with freetype source code in its source tree, however
we do _not_ use the freetype that comes with XFree86.  We use the
system supplied freetype from our freetype package, by enabling
the XFree86 host.def "HasFreetype2 YES" option during compilation,
which forces XFree86 to compile itself against the system supplied
freetype.  It thus never compiles nor uses its own internal
freetype.

> If you meant to say that the RedHat XFree86 packages never
> provided libfreetype* in /usr/X11R6/lib, then I'll accept that.

No, I meant specifically that *official* Red Hat XFree86 packages
released either as part of one of our OS distribution CDs in their
final form, as well as any updates to Red Hat XFree86 packages
that have been released by us, have never included libfreetype
at all period, not in /usr/X11R6/lib, and not in /usr/lib.  If there
has ever been an XFree86 package that we've shipped that did in 
fact contain the libfreetype libraries, then it is news to me.

Your above query does show that you have freetype installed, and
that it is installed in /usr/lib, however that has nothing to do
with XFree86 at all, as the "freetype" rpm package, as I've stated
above, is not part of XFree86 any more than glibc is.

> As I said, I believe that in the past (about 18 months ago) I
> compiled Xfree86 4.2 from sources from xfree86.org. This source
> put libfreetype* in /usr/X11R6/lib.

And that is exactly what I stated above is your problem in comment
#3 above, when I stated:

-----8<---------------------------------------------------------
1) At some point in time previously, you have installed XFree86
   binary installation from XFree86.org in tarball format, or
   compiled and installed it yourself from raw source.  This will
   install libfreetype in that location, and RPM will not know
   anything about it, nor will rpm uninstall it or modify it.
-----8<---------------------------------------------------------

> My beef is not with your XFree86 packages, but with glibc.

Your problem is solely caused by you manually installing XFree86
from source code, and allowing it to install whatever libraries
it wanted to, wherever it felt like doing so, regardless of wether
or not the system already supplied the proper libraries or not.

This is not a glibc problem, nor an XFree86 problem.  If you replace
major core parts of the operating system from raw source code,
such as freetype, XFree86, or any of a number of other major core
OS components, your operating system may have at one time been
a Red Hat Linux OS installation, but once you've replaced core
components it is no longer Red Hat Linux, but rather something that
resembles Red Hat Linux and is originally based upon it.

We do not support users systems that have replaced major OS
components with unofficial builds compiled by the user from source
code or downloaded from elsewhere.

> On more note on XFree86: since the official XFree86 sources put
> libfreetype.* in /usr/X11R6/lib, you may want to consider to have
> your rpm check for this.

Absolutely not.  The system comes with freetype, and you are
expected to use the system supplied freetype, as supplied by Red Hat,
if you want your system to be supported in any way.

> When you do things differently from the folks who officially
> support XFree86, you should not ignore the potential
> consequences for your customers.

XFree86.org supports XFree86 on a large number of OS platforms and
CPU architectures.  Many of the libraries which XFree86 and its
components require in order to compile and/or run, do not come
with many of those operating systems, as all of the software is
open source software, and many operating systems do not come with
any OSS software at all.  As such, XFree86.org has traditionally
done 2 things to work around this problem:

1) They have made XFree86 intentionally only require and/or use
   libraries which are under a license which is compatible with
   the XFree86 MIT license.

2) They include the library sources with XFree86 so that systems that
   do not supply the libraries that XFree86 requires, can still
   compile and use XFree86, as it supplies these libraries itself
   for systems that do not provide them, and does so under a
   license compatible with XFree86 itself.

In the case of freetype, it _is_ supplied with the system, and is
likely supplied with every Linux OS out there.  Any usage of the
XFree86 supplied freetype is totally non-standard, and is just
asking for problems.  XFree86.org does _not_ set the standard.

If you are wanting to compile XFree86 from source, then you should
be seeking support for that from XFree86.org directly, not from
Red Hat.  What you are asking us to support, we very much do not
support.  You _MUST_ use the system supplied libraries and software
we supply if you want your system supported.

Please contact your Red Hat customer support account manager
directly if you require clarification on the boundaries of
what your support contract does and does not cover, and they'll
be happy to clarify any confusion that may be present.

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