This is the mail archive of the glibc-linux@ricardo.ecn.wfu.edu mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: //lib/libc.so.6: undefined reference to `_dl_...@GLIBC_2.2'


>>>>> David Andrew Michael Noelle writes:

>> From: Andreas Jaeger <aj@suse.de>
>> Date: 02 Jan 2001 08:19:04 +0100
>> 
>> --prefix=/ is wrong.  RTFM, you need --prefix=/usr 

 > Are you really telling me that glibc 2.2 can ONLY be installed in
 > /usr/lib?  In exactly WHAT manual is that explained?  If you mean
 > "--prefix=/" is wrong because it generates paths like "//lib" and
 > "//include", wouldn't it be better to use "--libdir=/lib
 > --includedir=/include" rather than installing a second copy of glibc in
 > a second location and trying to switch my whole system from using
 > /lib/libc to using /usr/lib/libc without breaking anything?
RTFM the glibc docu, for example FAQ 2.2 reads:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2.2.    How do I configure GNU libc so that the essential libraries
        like libc.so go into /lib and the other into /usr/lib?

{UD,AJ} Like all other GNU packages GNU libc is designed to use a base
directory and install all files relative to this.  The default is
/usr/local, because this is safe (it will not damage the system if installed
there).  If you wish to install GNU libc as the primary C library on your
system, set the base directory to /usr (i.e. run configure --prefix=/usr
<other_options>).  Note that this can damage your system; see question 2.3 for
details.

Some systems like Linux have a filesystem standard which makes a difference
between essential libraries and others.  Essential libraries are placed in
/lib because this directory is required to be located on the same disk
partition as /.  The /usr subtree might be found on another
partition/disk. If you configure for Linux with --prefix=/usr, then this
will be done automatically.
[...]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you can't read the manual, I can't help you.

>> (check how Slackware does it!).  

 > I did check how Slackware does it.  Did you?  The Slackware binary

Did you check how Slackware configures glibc?  I don't need to check
it because I'm not responsible for Slackware and don't use it but I do
know what the glibc documentation says.

 > package I'm currently using installed everything in /lib, not /usr/lib.
 > Here are the contents of the Slackware 7.1 package a1/glibcso.tgz:

 > ./
 > lib/
 > lib/incoming/
 > lib/incoming/ld-2.2.so
That looks fine, those libs belong into /lib.  But where's libc.so?
libc.so will go into /usr/lib as part of the devel (?) package.

[...]
>> Now your installation is completly broken.  Remove everything from
>> *your* broken installation and perhaps you're happy.

 > Even if I were still using the version that I compiled, what you're
 > telling me to do, REMOVE glibc, would KILL the system, not fix it.  Or,
 > by "installation" do you mean more than just the glibc I compiled and
 > later replaced?  If you're telling me to wipe the hard drive and
 > reinstall from CD, I'm not willing to do that just so I can get rid of a
 > few undefined references.

I mean to properly install glibc.  On your broken system you have
libc.so in /lib from your broken installation - it belongs to /usr/lib
(there should be the one from your Slackware installation).  Fix all
these broken libs and you should be fine.  The glibc FAQ explains how
to not kill the system.

Since you can't RTFM, I refuse to answer any of your further emails.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]