Re: [PATCH] Add plugin interface to LD [2/4] Claim files and add symbols.

[Dave Korn <dave dot korn dot cygwin at gmail dot com>]

[ Sorry to return to this issue, but I still haven't fixed it yet. ]

On 23/09/2010 07:13, Ralf Wildenhues wrote:
> * Dave Korn wrote on Thu, Sep 23, 2010 at 08:25:42AM CEST:
>> On 23/09/2010 06:36, Ralf Wildenhues wrote:
>>> * Dave Korn wrote on Thu, Sep 23, 2010 at 07:31:41AM CEST:
>>>> --- a/ld/Makefile.am
>>>> +++ b/ld/Makefile.am
>>>> @@ -1989,7 +1989,7 @@ if ENABLE_PLUGINS
>>>>  noinst_LTLIBRARIES = libldtestplug.la
>>>>  libldtestplug_la_SOURCES = testplug.c
>>>>  libldtestplug_la_CFLAGS= -g -O2
>>>> -libldtestplug_la_LDFLAGS = -no-undefined -rpath /nowhere
>>>> +libldtestplug_la_LDFLAGS = -no-undefined -rpath /nowhere -Wl,$(LIBIBERTY)
>>> Why the '-Wl,' prefix?  I'd have expected $(LIBIBERTY) to be added to
>>> libldtestplug_la_LIBADD.
>>   libiberty isn't built under libtool control at all, AFAIK, and is only ever
>> built as a static archive, so I was under the impression I've got to pass it
>> around behind libtool's back like this.
> 
> Not because of that, no.
> 
>>> If you need to work around libtool warning about adding static library
>>> deps to a shared library, then I suggest at least -Wc, rather than -Wl,
>>> but still I think you will run into troubles on static-only systems.
>>   What kind of problems?
> 
> Ordering.  You can't rely on libtool expanding -Wl, link flags after the
> objects, meaning that libiberty may not be picked up at all.  (With
> static linking, objects and libraries are evaluated in a strict command
> line order, so all needed libraries must come after objects that need
> them.)

  Seems I'm not the only one who has this problem.  The makefile for GCC's
lto-plugin links libiberty like so:

> liblto_plugin_la_LIBADD = $(LIBELFLIBS) ../libiberty/pic/libiberty.a