Re: gcc can't compile, egcc can!??
On Sun, 14 Jun 1998 16:46:45 -0500 (CDT), servis@purdue.edu wrote:
>
>/lib/libc.so -> /lib/libc.so.5
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>MAY-DAY! MAY-DAY!!!!!!!!!!!!!!!
>
>/lib/libc.so.5 -> /lib/libc.so.5.4.36
>/lib/libc.so.5.4.36
>/lib/libm.so -> /lib/libm.so.5
>/lib/libm.so.5 -> /lib/libm.so.5.0.9
>/lib/libm.so.5.0.9
>
>
>I have now removed /lib/libc.so link and 'gcc -o hello hello.c'
>worked!!!!
>
>Other compiles were still complaining about
>
>ld: warning: libc.so.5, needed by /lib/libncurses.so, may conflict with libc.s
>o.6
>
>I looked at /lib/libncurses.so links:
>
>/lib/libncurses.so -> /lib/libncurses.so.3
>/lib/libncurses.so.3.0
>/lib/libncurses.so.3.4
>
>I removed /lib/libncurses.so and /lib/libncurses.so.3 and all seems to
>be well now.
You probably want to remove _all_ /lib/lib*.so links. You definitely
want to remove the ones that point to libraries compiled with libc5.
ldd will tell you which those are:
$ ldd /lib/libm.so.5
libc.so.5 => /lib/libc.so.5
General principle: you can not mix libc5 and libc6 code. That goes
for libraries as well -- any nontrivial shared library (such as
libncurses) will use C library functions.
>> The key thing here is that the libfoo.so links need to point to the
>> libc6 libraries. Check that there is no /lib/libc.so link. In fact,
>> there should probably be no xyz.so files in /lib at all, except
>> /lib/ld.so. (xyz-2.0.7.so files are ok.) Check that /usr/lib/libm.so
>> points at /usr/lib/libm.so.6.
>
>I have:
>
>/lib/libm.so -> /lib/libm.so.5 ******* Is this trouble?
Yes it is. Programs that use libm will get the same sort of conflict.
>/lib/libreadline.so -> /lib/libreadline.so.2
>/lib/librl.so -> /lib/librl.so.2
These are also trouble; they're the libc5 versions of libreadline and
librl. Delete the links.
>With this all fixed I just did a kernel compile and it went without a
>hitch.(I did not change the /lib/libm.so link above).
>
>This all started when I upgraded from bo to hamm.
>Something must not have cleaned up its links when being upgraded.
>
>This machine has been upgraded in place since Debian 0.93 days but
>this is the first problem I have had like this.
What seems to have happened is that the hamm libraries put the .so
links into /usr/lib, but the libraries from some pre-FSSTND debian put
them in /lib. ld searches /lib before /usr/lib, so it uses the libc5
libraries.
bo puts .so links in /usr/lib, so it was earlier than that. You
never noticed before because you never had a C library major version
change. (And hopefully it'll never happen again :)
One thing that bothers me is that your kernel compile was affected.
The kernel shouldn't use anything from libc. If the kernel boots it's
fine, but there might be something strange going on there.
Also I wonder what libm is doing in /lib. That's probably legitimate,
but I'd think nothing needs it before /usr is mounted.
zw
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: