Re: Linux, X, ld, gcc, linking, shared libraries and stuff

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...

"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 :)

> 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.

> 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...

> 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...

What *isn't* required, if only libc is used, is any "-L"
switch...

> It is also possible that there is some problem with the
> installation of ld. Dynamic linking requires some configuration;
> hints files, default library paths, and the like. It is
> conceivable that something along those lines is wrong that has
> not been discovered because so few people call ld directly.

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!

> 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. I
would expect a complaint from ld about an "unresolved
external". But it seems to work. As we know, "it works"
doesn't mean "it's right". I might be reporting errors
someplace that's "mostly harmless" today, but will blow up
tomorrow. My "experiments" into "what I can get away with"
are by no means well-tested, but so far I haven't noticed
any ill effects from the missing startup code. At the very
least, I ought to put reading the source for the C
startup/cleanup routines on my rather elusive "todo list"...

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"... 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...

BTW, thanks for "name dropping" those book recommendations -
I probably won't get around to reading them, but I
acknowledge that I "should"... So many things to learn, so
little ambition...

Best,
Frank
.

Relevant Pages

  • Re: Linux, X, ld, gcc, linking, shared libraries and stuff
    ... it appears to be a "configuration issue" - we could compile ourselves a version of ld that *did* use the "right" dynamic linker, ... how you'd do dynamic linking on BSD - "ld-linux" didn't seem ... then specifying the dynamic linker is just ... libc only, not the X libraries. ...
    (alt.lang.asm)
  • Re: Shared libraries and modules
    ... Libraries are one of the earliest forms of organised code reuse. ... The linking may be static linking or, in some systems, dynamic linking. ... the same as Unix because in addition it makes porting easier. ...
    (comp.sys.acorn.misc)
  • Re: Apples linking
    ... The first kind of dynamic linking is more or less the traditional ... because, like FreeBSD, the Intel version of Darwin maps process ... can't create new split libraries; ... suffer the runtime penalty for most of the shared libraries in OS's ...
    (freebsd-current)
  • Re: Unfortunate dynamic linking for everything
    ... > an aspect of the dynamic linker and the lack of prebinding rather than ... big win for large applications with many libraries (XWindows, KDE, ... OpenOffice, whathaveyou), but that the base cost of loading relocation ... Remaining with dynamic linking ...
    (freebsd-current)
  • Re: what is faster dynamic linking or static linking?
    ... Could one use specific compile time flag with makefile or is it ... advisable to go for dynamic linking. ... shared library that is loaded into physical memory only once and many ... Without shared libraries every different program would have its own copy ...
    (comp.unix.programmer)