Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ld.so-1.7.14 + libc-5.2.18

23 views
Skip to first unread message

Markus Gutschke

unread,
Mar 5, 1996, 3:00:00 AM3/5/96
to
-----BEGIN PGP SIGNED MESSAGE-----

In article <4hea9v$q...@netnews.ntu.edu.tw> an...@archi5.ee.ntu.edu.tw (Anmin Deng) writes:
> My system is PC/i586/Slackware-3.0 Based/Linux-1.3.59/
> ld.so-1.7.10/libc-5.2.16(ELF)/libc-4.7.5(a.out)/
^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
> GCC-2.7.2/G++-2.7.1.3/binutils-2.6.0.2 (binaries obtained
> from GCC directory).
>
> These packages work fine with my system, and I have followed
> the instructions.. patching make, making links for lib*.so.x.y.z,
> removing invalid head files, unpacking packages, and ldconfiging.
>
> Here is the problem.. When I upgraded to ld.so-1.7.14/libc-5.2.18,
> all the programs that dynamically linked to DLL libraries did not
> run and ld.so issued error messages. For example, "dip" of slackware-3.0
> which is dynamically linked to..
> libc.so.4 (DLL Jump 4.6pl29) => /lib/libc.so.4
> did not run on ld.so-1.7.14/libc-5.2.18.
>
> What should I do to make DLL work on ld.so-1.7.14/libc-5.2.18 ?

You already answered your own question. You have a mixed ELF/a.out
system. Thus you need two keep both the ELF and the a.out libraries
and program loaders. This means, you need to install ld.so *and*
ld-linux.so.1! Furthermore, all libc releases above and including
5.0.0 are ELF and all older releases are a.out; so you need to keep
your old 4.x libraries.

BTW, could you please refrain from crossposting to this many different
newsgroups. Also, please do not crosspost to the de.* hierarchy, as
this is a German speaking hierarchy! It is usually no problem to post
English articles to this hierarchy if there is a special need for
doing so, but in that case you should *not* cross post to other
groups, as it will eventually result in German followups that end up
in the international groups :-)

Markus

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface

iQCVAgUBMTwuQRqJqDLErwMxAQEpcwP+Ib0RwV9YK2ghhE7aHmwErDMoiID2xE/c
tlTtHk/WTNFDWtY+XmMuPxZaNIzPGTvXWlDDeXyZg4oCVMFGsnvCCtDi+fjST4Yh
XcoPjQGRYcX3uXZNfKcVM51tLOckkeTf3TqlkOEhWw7vavgcWNZCkLhu2fVOk1yc
H18b3uIwOgQ=
=l6tD
-----END PGP SIGNATURE-----

Anmin Deng

unread,
Mar 6, 1996, 3:00:00 AM3/6/96
to
Markus Gutschke (gut...@uni-muenster.de) wrote:

: an...@archi5.ee.ntu.edu.tw (Anmin Deng) writes:
: > My system is PC/i586/Slackware-3.0 Based/Linux-1.3.59/
: > ld.so-1.7.10/libc-5.2.16(ELF)/libc-4.7.5(a.out)/
: > GCC-2.7.2/G++-2.7.1.3/binutils-2.6.0.2 (binaries obtained
: > from GCC directory).
: > These packages work fine with my system, and I have followed......
: > ..... When I upgraded to ld.so-1.7.14/libc-5.2.18,

: > all the programs that dynamically linked to DLL libraries did not
: > run and ld.so issued error messages. For example, "dip" of slackware-3.0
: > libc.so.4 (DLL Jump 4.6pl29) => /lib/libc.so.4

: > did not run on ld.so-1.7.14/libc-5.2.18.

: You already answered your own question. You have a mixed ELF/a.out


: system. Thus you need two keep both the ELF and the a.out libraries
: and program loaders. This means, you need to install ld.so *and*
: ld-linux.so.1! Furthermore, all libc releases above and including
: 5.0.0 are ELF and all older releases are a.out; so you need to keep
: your old 4.x libraries.

On my ld.so-1.7.10 + libc-5.2.16 + libc-4.7.5 system, there ARE
ld.so-1.7.10, ld-linux.so.1.7.10, libc-5.2.16, libc-4.7.5, etc. in
directory "/lib", and DLL linked binaries work on this system. And
upgrading to ld.so-1.7.14 + libc-5.2.18 that I mean is to replace
ld.so-1.7.10 with ld.so-1.7.14, ld-linux.so.1.7.10 with ld-linux.so.1.7.14,
libc-5.2.16 with libc-5.2.18, and leave libc-4.7.5 unchanged (libm and
libdl are replaced for ELF and left unchanged for a.out, too).
This upgrading makes DLL linked binaries just don't run on the system.

: BTW, could you please refrain from crossposting to this many different


: newsgroups. Also, please do not crosspost to the de.* hierarchy, as
: this is a German speaking hierarchy! It is usually no problem to post
: English articles to this hierarchy if there is a special need for
: doing so, but in that case you should *not* cross post to other
: groups, as it will eventually result in German followups that end up
: in the international groups :-)

I did crosspost the article in many newsgroups, but I don't remember
that I have crosspost it to de.* newsgroups. Actually I remembered that
I crosspost it on only comp.os.linux.*, but not including comp.os.linux.{
hardware,answers,announce,advocacy,x,setup,networking}.

I am sorry if the crossposting make other irrelevant newsgroups flooded.


Anmin Deng

unread,
Mar 12, 1996, 3:00:00 AM3/12/96
to
Anmin Deng (an...@archi5.ee.ntu.edu.tw) wrote:
> My system is PC/i586/Slackware-3.0 Based/Linux-1.3.59/
> ld.so-1.7.10/libc-5.2.16(ELF)/libc-4.7.5(a.out)/
> GCC-2.7.2/G++-2.7.1.3/binutils-2.6.0.2 (binaries obtained
> from GCC directory).
> These packages work fine with my system, and I have followed......
> ..... When I upgraded to ld.so-1.7.14/libc-5.2.18,
> all the programs that dynamically linked to DLL libraries did not
> run and ld.so issued error messages. For example, "dip" of slackware-3.0
> libc.so.4 (DLL Jump 4.6pl29) => /lib/libc.so.4
> did not run on ld.so-1.7.14/libc-5.2.18.

Problem solved, I just made an incorrect symbolic link to ld.so
with a wrong version.

Sorry for wasting your time and disk space.

0 new messages