Re: How do I link to a shared lib without having that lib's dependencies (the way MS link does)

[Ian Lance Taylor <ian at airs dot com>]

"Don Woodward" <woodward@woodward.org> writes:

> This is why the linker is requiring prog to also link against libC, so that
> it
> can check the symbols and give me an error (proposed patch changes this
> to a warning) if not all of libC's symbols that prog uses indirectly through
> libB can be resolved.

The linker shouldn't be requiring you to link against libC.  That
would be wrong.  The linker is checking on libC for you, but you
shouldn't need to specify libC on the command line, and the resulting
executable shouldn't depend upon libC.  If it does, then I think there
is something else wrong.

It's true that the linker is currently issuing an error when it can't
find libC, but I think we do need to change that to be a warning,
perhaps as controlled by a command line option.

> Which begs the following question: is there a linker option where I can
> build
> my shared libraries and programs so that the loader invokes all dlopens
> with RTLD_NOW?

First I'll note that if you set the environment variable LD_BIND_NOW
when you run the program, then the dynamic linker will effectively use
RTLD_NOW when it loads the program.

Also, at least for newer versions of the program linker and the
dynamic linker, you can use the option ``-z now'' to set a flag in the
executable which tells the dynamic linker to effectively use RTLD_NOW.
This is documented in a rather cryptic manner in the linker manual and
in ld's --help output.

Note that the option ``-z now'' will set the flag, but it won't change
the linker's behaviour as far as looking for undefined symbols and
warning about them.

Ian