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's dependencies (the way MS link does)
Richard Henderson <rth@redhat.com> writes:
> On Tue, Aug 12, 2003 at 09:44:28AM -0700, Ian Lance Taylor wrote:
> > I think this is a bug. The GNU linker is reporting an error where it
> > should report a warning.
>
> Eh, maybe. If the user had used -rpath-link, as prompted,
> ld would have found libB.so from libA.so's dependencies.
Sure, but the -rpath-link message is a warning, not an error, as I
think it should be.
> I don't think downgrading this to a warning is a good idea.
> Too often it will be ignored.
Hmmm. To me it really is just a warning. There are a number of ways
in which everything could work out fine. We're not talking here about
an undefined symbol in the program itself. We're talking about an
undefined symbol in a shared library against which the program is
linked.
However, I could see keeping it as an error for
--no-allow-shlib-undefined, as H.J. suggested, and reversing the
default so that --no-allow-shlib-undefined is the default while
--allow-shlib-undefined permits undefined symbols. This would of
course be predicated on cleaning up --allow-shlib-undefined so that it
has only one meaning instead of two.
In fact, that approach seems to me like it might be closer to the
original intent of --allow-shlib-undefined, based on the ChangeLog
entry which created it:
2000-11-18 Fred Fish <fnf@be.com>
* lexsup.c (OPTION_ALLOW_SHLIB_UNDEFINED): Define.
(ld_options): Entry for --allow-shlib-undefined.
(parse_args): Handle OPTION_ALLOW_SHLIB_UNDEFINED.
* ldmain.c (main): Initialize link_info.allow_shlib_undefined
to false.
Nick reversed the default here:
http://sources.redhat.com/ml/binutils/2003-02/msg00232.html
Ian