How do I link to a shared lib without having that lib's dependencies (the way MS link does)
H. J. Lu
hjl@lucon.org
Tue Aug 12 19:06:00 GMT 2003
On Tue, Aug 12, 2003 at 11:35:14AM -0700, H. J. Lu wrote:
> On Tue, Aug 12, 2003 at 11:00:40AM -0700, Ian Lance Taylor wrote:
> > "H. J. Lu" <hjl@lucon.org> writes:
> >
> > >
> > > I prefer something like this.
> > >
> > >
> > > H.J.
> > > ----
> > > --- bfd/elflink.h.undef 2003-08-07 09:04:31.000000000 -0700
> > > +++ bfd/elflink.h 2003-08-12 10:38:32.000000000 -0700
> > > @@ -4380,7 +4380,7 @@ elf_link_output_extsym (struct elf_link_
> > > {
> > > if (! ((*finfo->info->callbacks->undefined_symbol)
> > > (finfo->info, h->root.root.string, h->root.u.undef.abfd,
> > > - NULL, 0, TRUE)))
> > > + NULL, 0, ! finfo->info->allow_shlib_undefined)))
> > > {
> > > eoinfo->failed = TRUE;
> > > return FALSE;
> >
> > I may be confused on the meaning of the --allow-shlib-undefined
> > option. The documentation is a bit confusing. If I read it
> > carefully, it appears to mean that if --allow-shlib-undefined is set,
> > then it is OK to link against a shared library which has undefined
> > references which are not satisfied by anything else in the link.
> >
> > However, that does not match the code. For example, in the very place
> > we are looking at, elf_link_output_extsym(), we see this:
> > && (finfo->info->executable
> > || ! finfo->info->allow_shlib_undefined)
> > That clearly suggests that the --allow-shlib-undefined option refers
> > not to the case of linking against a shared library, but to the case
> > of creating a shared library.
> >
> > This code was inserted with this patch:
> >
> > 2003-02-17 Nick Clifton <nickc@redhat.com>
> >
> > * elflink.h (elf_link_output_extsym): Only check
> > allow_shlib_undefined for shared libraries.
> >
> > So before deciding on that patch, I need to understand what
> > --allow-shlib-undefined is supposed to mean.
> >
> > To be as clear as I can, there are two possibilities:
> >
> > 1) When linking against shared library A to form an executable or
> > shared library B, if A has any undefined references which are not
> > satisfied by anything else in the link, that is OK.
> >
> > 2) When creating a shared library A, if A has any undefined references
> > which are not satisfied by anything else in the link, that is OK.
> >
> > The documentation is hard for me to understand, but suggests
> > alternative 1. The code in elf_link_output_extsym() appears to
> > implement alternative 2.
> >
> > If alternative 1 is correct, then I agree with your patch. And I
> > think that the immediately preceding condition in
> > elf_link_output_extsym() should not refer to allow_shlib_undefined.
> >
> > Note that the allow_shlib_undefined field was introduced with this
> > ChangeLog entry in the bfd directory:
> >
> > 2000-12-10 Fred Fish <fnf@be.com>
> >
> > * elflink.h (elf_link_output_extsym): Don't complain about undefined
> > symbols in shared objects if allow_shlib_undefined is true.
> >
> > This too is ambiguous, but suggests that if --allow-shlib-undefined is
> > set, the code should not even issue a warning.
>
> I went over this piece of code myself a few times. It was not clear
> to me either. We can always clearify it. But I don't want to make it
> a warning unconditionally. Maybe we should add another option to ignore
> the undefined references from shared objects when creating executables.
> Or we can change the default of allow_shlib_undefined to FALSE when
> creating executables.
>
This is what I meant.
H.J.
-------------- next part --------------
bfd/
2003-08-12 H.J. Lu <hongjiu.lu@intel.com>
* elflink.h (elf_link_output_extsym): Don't make it a fatal
error when reporting an undefined symbol in a shared library
for --allow-shlib-undefined.
ld/
2003-08-12 H.J. Lu <hongjiu.lu@intel.com>
* ld.texinfo: Updated.
* ldmain.c (main): Set link_info.allow_shlib_undefined to
FALSE.
* lexsup.c (parse_args): Default link_info.allow_shlib_undefined
to TRUE when creating a shared library.
--- binutils/bfd/elflink.h.undef 2003-08-07 09:04:31.000000000 -0700
+++ binutils/bfd/elflink.h 2003-08-12 10:38:32.000000000 -0700
@@ -4380,7 +4380,7 @@ elf_link_output_extsym (struct elf_link_
{
if (! ((*finfo->info->callbacks->undefined_symbol)
(finfo->info, h->root.root.string, h->root.u.undef.abfd,
- NULL, 0, TRUE)))
+ NULL, 0, ! finfo->info->allow_shlib_undefined)))
{
eoinfo->failed = TRUE;
return FALSE;
--- binutils/ld/ld.texinfo.undef 2003-07-28 07:41:43.000000000 -0700
+++ binutils/ld/ld.texinfo 2003-08-12 11:59:28.000000000 -0700
@@ -1141,14 +1141,19 @@ first definition will be used.
@kindex --no-allow-shlib-undefined
@item --allow-shlib-undefined
@itemx --no-allow-shlib-undefined
-Allow (the default) or disallow undefined symbols in shared objects.
+Allow or disallow undefined symbols in shared objects.
The setting of this switch overrides @samp{--no-undefined} where
shared objects are concerned. Thus if @samp{--no-undefined} is set
but @samp{--no-allow-shlib-undefined} is not, the net result will be
that undefined symbols in regular object files will trigger an error,
but undefined symbols in shared objects will be ignored.
-The reason that @samp{--allow-shlib-undefined} is the default is that
+The default is @samp{--allow-shlib-undefined} when creating a shared
+object and @samp{--no-allow-shlib-undefined} when creating a
+executable.
+
+The reason that @samp{--allow-shlib-undefined} is the default for
+shared objects is that
the shared object being specified at link time may not be the same one
that is available at load time, so the symbols might actually be
resolvable at load time. Plus there are some systems, (eg BeOS) where
--- binutils/ld/ldmain.c.undef 2003-06-30 08:05:28.000000000 -0700
+++ binutils/ld/ldmain.c 2003-08-12 11:46:31.000000000 -0700
@@ -290,7 +290,7 @@ main (int argc, char **argv)
link_info.traditional_format = FALSE;
link_info.optimize = FALSE;
link_info.no_undefined = FALSE;
- link_info.allow_shlib_undefined = TRUE;
+ link_info.allow_shlib_undefined = FALSE;
link_info.allow_multiple_definition = FALSE;
link_info.allow_undefined_version = TRUE;
link_info.keep_memory = TRUE;
--- binutils/ld/lexsup.c.undef 2003-06-30 08:05:28.000000000 -0700
+++ binutils/ld/lexsup.c 2003-08-12 11:49:35.000000000 -0700
@@ -473,6 +473,7 @@ parse_args (unsigned argc, char **argv)
struct option *really_longopts;
int last_optind;
const char *demangler = NULL, *style = NULL;
+ bfd_boolean seen_allow_shlib_undefined = FALSE;
shortopts = xmalloc (OPTION_COUNT * 3 + 2);
longopts = xmalloc (sizeof (*longopts) * (OPTION_COUNT + 1));
@@ -793,9 +794,11 @@ parse_args (unsigned argc, char **argv)
break;
case OPTION_ALLOW_SHLIB_UNDEFINED:
link_info.allow_shlib_undefined = TRUE;
+ seen_allow_shlib_undefined = TRUE;
break;
case OPTION_NO_ALLOW_SHLIB_UNDEFINED:
link_info.allow_shlib_undefined = FALSE;
+ seen_allow_shlib_undefined = TRUE;
break;
case OPTION_ALLOW_MULTIPLE_DEFINITION:
link_info.allow_multiple_definition = TRUE;
@@ -950,6 +953,8 @@ parse_args (unsigned argc, char **argv)
link_info.shared = TRUE;
else
einfo (_("%P%F: -shared not supported\n"));
+ if (!seen_allow_shlib_undefined)
+ link_info.allow_shlib_undefined = TRUE;
break;
case OPTION_PIE:
if (config.has_shared)
More information about the Binutils
mailing list