Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- From: "T.M. Sommers" <tms@xxxxxx>
- Date: Wed, 13 Apr 2005 05:27:01 GMT
Frank Kotler wrote:
Sorry for the delayed reply... I've been meaning to do some "research" first, but haven't gotten around to it... I ought to make some reply, anyway...
Nothing to apologize for. Anyway, better late than never I always say (although for some reason I can't fathom my creditors don't seem to agree). At least I can always count on your responses being civil, unlike those of another whose name I won't mention but whose initials describe much of what she writes.
"T.M. Sommers" wrote:
Frank Kotler wrote: > > Apparently, we need to tell ld the "Interpreter" ("-I") or > "--dynamic-linker" to use - "-I" is shorter :) > > ld -s -o example2 example2.o -I /lib/ld-linux.so.2 -lX11 > -L/usr/X11R6/lib > > Works cherry for me!
That is odd.
Always seems odd to me if anything works - especially first try :)
You've been using Windows too long.
GNU ld on FreeBSD knows all about the dynamic linker without being told. I am very surprised that GNU ld on Linux is not that smart.
That seems to be the case. As you point out in another post, it appears to be a "configuration issue" - we could compile ourselves a version of ld that *did* use the "right" dynamic linker, if we wanted to. But the "regular Linux ld" seems to use a default that, on my system, doesn't exist. This could quite reasonably be considered a "bug", I think.
In any case, I think you've answered a question I had about how you'd do dynamic linking on BSD - "ld-linux" didn't seem like a good candidate :) BSD's ld "knows"... good... that's easy.
FreeBSD's dynamic linker is ld-elf.so. ld is configured to know that. Nevertheless, gcc still specifies the linker explicitly via -I. It obviously must do the same on Linux, which would mask a misconfigured ld for virtually everyone.
Are you sure that is the real problem?
Not at all. I learned the "-I" switch as "that's how you do it", rather than as a "solution to a problem". I had no idea that ld *had* a default until Beth posted about her problem. Now that I look, a plain "text dump" of the executable shows "ld-linux.so.1" if no "-I" switch is used...
Use 'objdump -s' and look for the .interp section; that is where the dynamic linker is specified. If that is ld-linux.so and the -I switch was not used, there should be no problem.
Try linking the program without specifying the dynamic linker, and use objdump or whatever to look at the .interp section. If that is correct, then specifying the dynamic linker is just masking the real problem.
You might want to try seeing if the problem occurs when you use libc only, not the X libraries.
It does. Without the "-I" switch, ld links without complaint, but running the executable gives a "no such file or directory" message - presumably /lib/ld-linux.so.1... I guess...
That would be consistent with a misconfigured ld.
I was under the impression that /etc/ld.so.conf was an important file for dynamic linking. I thought that if I added "/usr/X11R6/lib" there, I wouldn't need to specify that path with the "-L" switch... but it's already there, and I *do* need it - but libc apparently *is* found without specifying where... More to learn here, for sure!
Every Unix does these things differently, so I can't be of much help. However, on FreeBSD, /etc/ld.so.conf is for a.out binaries, not ELF. There can be an /etc/ld-elf.so.conf for ELF files. However, these are obsolete, and FreeBSD now uses a hints file managed by ldconfig(8). I don't know how Linux does things, but they might have something similar.
I would also urge you to use the C startup and cleanup code if you are linking to C libraries. That code exists for a reason; some library functions depend on it.
That seems right. I'm a bit surprised that it works at all without it. I would expect that "global errno", for one obvious example, might be defined in the startup code.
It is.
I would expect a complaint from ld about an "unresolved external".
If the linker is using lazy binding, as it probably is, the symbols won't be looked for until needed.
Not satisfied with dynamic linking, I've tried using "dlopen", "dlsym", and "dlclose"... to open and use a "shared library" on the fly (to do very simple-minded things). Idiotic code - dynamically links dllib.so (which drags in libc) to get dlopen to open Seadhert's "libsimple.so" example to use "print_out"...
At least in FreeBSD, dlopen and kin are actually part of the dynamic linker.
Again, it "seems to work". Just a "proof of concept" - the idea being to write "homemade" dlopen/dlsym/dlclose replacements, eventually, and do away with the dynamic linker entirely... Haven't gotten beyond the "first try" yet...
That would be a very ambitious project. Of course, you can always do away with the dynamic linker by linking everything statically.
-- Thomas M. Sommers -- tms@xxxxxx -- AB2SB
.
- Follow-Ups:
- References:
- Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- From: T.M. Sommers
- Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- From: Frank Kotler
- Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- Prev by Date: Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- Next by Date: Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- Previous by thread: Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- Next by thread: Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- Index(es):
Relevant Pages
|
