Re: [lto-plugin, build] Don't link libiberty.a into liblto-plugin.a

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

On 14/12/2010 18:42, Rainer Orth wrote:

  Hi Rainer,

> When trying a mainline bootstrap on Solaris 11/x86 with a debug version
> of the Sun binutils, I ran into an assertion failure building the static
> liblto-plugin.a:
> 
> $ ar cr .libs/liblto_plugin.a ../libiberty/pic/libiberty.a  lto-plugin.o
> Assertion failed: !is_elf || (pad(lseek(fd, 0, SEEK_CUR), PADSZ) == 0), file ../common/file.c, line 726, function write_member_header
> Abort
> 
> While the assertion failure won't show in a production version and the
> condition has since been fixed to avoid it even in a debug version, it
> seems clear that embedding an archive inside another archive doesn't
> make any sense.
> 
> The following patch fixed the issue for me by avoiding to pass .a files
> directly to libtool, but instead using the appropriate combination of -L
> and -l.  It allowed my bootstraps to finish.

  Bad news I'm afraid.  It broke the plugin on Windows: it doesn't build a DLL
any more, because ...

> *** Warning: linker path does not have real file for library -liberty.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libiberty and none of the candidates passed a file format test
> *** using a file magic. Last file checked: /usr/lib/libiberty.a
> *** The inter-library dependencies that have been dropped here will be
> *** automatically added whenever a program is linked with this library
> *** or is declared to -dlopen it.
> 
> *** Since this library must not contain undefined symbols,
> *** because either the platform does not support them or
> *** it was explicitly requested with -no-undefined,
> *** libtool will only create a static version of it.

  Do you actually have any use for the static version of the plugin?  If not,
and you were just trying to avoid an assertion that won't happen any more, it
would be helpful if you could revert your patch until we've had time to figure
out a fuller fix.

  Ralf, does this mean we need to make a libiberty convenience library somehow?

    cheers,
      DaveK