This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: How do I link to a shared lib without having that lib'sdependencies (the way MS link does)
Hi Guys,
OK, after thinking about this a bit, here is what I feel we should
do:
* Clarify the documentation to express exactly what should be
happening. I think that there are three situations:
1. Creating a statically linked library or executable.
In this case the default should always be to generate an error
message for any unresolved reference.
The --defsym <name>=<value> command line switch can be used if
there is a need to suppress an undefined reference to <name>.
2. Creating a shared or dynamic library.
In this case the default should be to silently ignore any
unresolved references. The assumption being that the
references will be resolved when the library is later linked or
loaded.
Two options exist to change this behaviour however:
--no-undefined will make the linker generate an error message
if the unresolved reference comes from a normal object files
being linked into the shared library. It has no effect if the
unresolved reference is in a shared library that is being
linked in.
--no-allow-shlib-undefined will make the linker generate error
messages when the unresolved references are in a shared library
that is being linked in.
3. Creating an executable that links to shared libraries.
The default for ELF binaries should be to generate warning
messages for any unresolved symbol, even if that symbol is in a
shared library, and even if that shared library links to other
shared libraries which are not present/locatable at link time.
The message is a warning because these unresolved references
might be intentional. The warning is generated by default
however because otherwise the problem might not be discovered
until the executable has been running for a long time.
The warnings ought to be suppressible by use of a command
line switch. At the moment this switch does not exist.
In fact the default behaviour in this situation ought to be
selectable by the target emulation. For ELF format targets the
default ought to be as described. For other targets (eg the PE
format) the default may well be to enable the new switch.
* Ensure that the code conforms to the above documentation.
* Generate a set of tests to ensure that the desired behaviour
continues.
It seems to me however that having three different switches to
control the linker's behaviour with undefined references is a bit
much. I think that it would be cleaner and easier to understand if
we had only one switch, but its default setting would depend upon
the target file format, and what task the linker was being asked to
perform.
So for example we could have one switch, say,
--ignore-unresolved-symbols=<setting> which could take a number of
different values:
all [ignore any unresolved reference]
none [do not ignore any unresolved reference]
in-shared-libraries [references from one shared library to another]
in-object-files [references in object files]
The default setting of this switch would depend upon the presence of
other information gleaned from the command line:
--ignore-unresolved-symbols=all Default if --shared is used
on the command line.
--ignore-unresolved-symbols=none Default if no shared
libraries are present on the
command line.
--ignore-unresolved-symbols=none (For ELF): Default if shared
libraries are present on the
command line.
I am going to look at how to implement all of this, but comments and
suggestions welcome.
Cheers
Nick