I'm in the process of trying to create a lean prototype linux system
based on glibc-2.3.3, and kernel-2.6.10. I started with a suse 8.1
glibc2.2.5 system and created a new partition, installed the updated
glibc2.3.3 on it and have been compiling the system utils from
sourceode and putting them on the new partition.

I'm running into a very strange weirdness.

Wherever possible I used CFLAGS=-Wl,--dynamic-linker=/uber/lib/ld-linux.so.2
and also the dynamic linker line in LDFLAGS. This causes the
ld.so for glibc2.3.3 to be used instead of the old one for 2.2.5.

SOME of the packages work properly on the new system but others give
a vague and non-descript error message when I try to execute them.

on the prototype system I type something like

ls -l | /bin/more

under the 2.3.3 system causes "/bin/sh: cannot find /bin/more"
even though it exists, and is executable. ldd will not read it either...
but if I do

/lib/ld-linux.so.2 --list /bin/more

it prints out the correct shared library dpendencies.

also, if I prefix the command line as follows:

ls | /lib/ld-linux.so.2 /bin/more

it works fine and doesn't complain...executes /bin/more properly

Why are SOME of my freshly compiled binaries requiring explicit
entry of the ld.so loader, to be found or to be execute under 2.3.3?

ld.so.cache is empty because /lib is the ONLY shared
library location on the new system.

Looks like suse8.1 glibc DOES NOT CONTAIN ANY ABI VERSION INFORMATION THUS
SCREWING THOSE OF US WHO WANT TO UPGRADE...can someone confirm?


thoughtful comments, or suggestions welcome...
stupid ego based rants silently ignored...
thanks.



----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----