Bug 21702 - ar cannot handle (slim) LTO object files when in MRI script mode
Summary: ar cannot handle (slim) LTO object files when in MRI script mode
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.28
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2017-07-03 14:06 UTC by Martin Schulze
Modified: 2017-08-02 11:16 UTC (History)
1 user (show)

See Also:
Last reconfirmed: 2017-08-01 00:00:00

Example project that exhibits the problem (563 bytes, application/gzip)
2017-07-03 14:06 UTC, Martin Schulze
Proposed patch (484 bytes, patch)
2017-08-01 11:29 UTC, Nick Clifton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Schulze 2017-07-03 14:06:59 UTC
Created attachment 10239 [details]
Example project that exhibits the problem

This problem turned up while cross-compiling Qt 5.9.0 with LTO enabled.
ar gives the error "plugin needed to handle lto object" and generates an output file which results in undefined reference errors when linked.

You can reproduce this by running make in the attached project tree. (Obviously you need x86_64-w64-mingw32-{ar,gcc} for this to work.)
The run will result in the aformentioned errors instead of a successfully built binary. The output is as follows:

$ make
x86_64-w64-mingw32-gcc -c -flto -o func.o func.c
x86_64-w64-mingw32-ar -M < mri_script
x86_64-w64-mingw32-ar: func.o: plugin needed to handle lto object
x86_64-w64-mingw32-gcc -flto main.c -o main -L. -lfunc
/tmp/cc7mkhTU.ltrans0.ltrans.o:<artificial>:(.text+0x1b): undefined reference to `func'
/tmp/cc7mkhTU.ltrans0.ltrans.o:<artificial>:(.text+0x22): undefined reference to `func2'

I also added a make target main.non-mri that uses command line parameters for ar instead of the mri script. 
This invocation works as expected and builts an executable that can be run via wine.

Additional Information:

I am running this on Arch Linux 64bit:

$ x86_64-w64-mingw32-ar --version
GNU ar (GNU Binutils) 2.28

I did not post this on MinGW bugtracker as they seem to only handle bugs under Windows and this is a cross-compilation problem.
I also decided against the GCC bugtracker as this seems to be a problem with the archiver.
Comment 1 Martin Schulze 2017-07-05 11:51:57 UTC
I just noticed that the problem is reproducible with "normal" ar.
Comment 2 Nick Clifton 2017-08-01 09:39:09 UTC
Hi Martin,

  This is a build/system installation issue more than anything.  Assuming 
  that ar has been configured with --enable-plugins set[1] then the problem
  is that ar is not finding the plugin that it needs.  They are two ways 
  that it can find the plugin.  The first is via a command line option to ar 
  itself, vis: --plugin=<path-to-gcc-lto-plugin>.  This is the better 
  solution, IMHO, although it does mean that you will have to update your 
  build framework.

  The second method is that ar (and the other binutils that support plugins)
  will look in the directory /usr/lib/bfd-plugins for the plugin.  So if you
  copy gcc's liblto_plugin into this directory everything should start to 
  work.  I am not a fan of this method since it relies upon having admin
  access on the build machine, and it is easy to forget that the directory
  is there, and then have problems because an out of date plugin is being 


[1] I am not familiar with Arch Linux, but I suspect that plugin support
is probably enabled.  Most distributions do that now.
Comment 3 Martin Schulze 2017-08-01 10:00:46 UTC
Hi Nick,
thanks for your reply.

Yes, Arch compiles with --enable-plugins. Otherwise the linking while using the command line (ar rcs ...) wouldn't work too.

I already tried to add the --plugin option to no avail.
Furthermore, Arch's gcc package defaults to creating the symlink /usr/lib/bfd-plugins/liblto_plugin.so -> /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/liblto_plugin.so so it should also be found via this method (as it seems to be with the `ar rcs ...` call).

I think the problem is that the plugin is not loaded in MRI mode where it should be.

This is illustrated nicely by the fact that following call works as expected (without any plugin option):

ar rcs libfunc.non-mri.a func.o

While these two both give an error:

ar -M < mri_script
ar: func.o: plugin needed to handle lto object

ar --plugin=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/liblto_plugin.so  -M < mri_script
ar: func.o: plugin needed to handle lto object
Comment 4 Nick Clifton 2017-08-01 11:29:53 UTC
Created attachment 10298 [details]
Proposed patch

Hi Martin,

  Ah - I was confused by comment #1 which made me think that the problem also
  applied in non-MRI mode.

  Anyway, please can you try out this patch and let me know if it works for

  I am not an MRI expert, but I suspect that the patch might need to be 
  extended to cope with other things that can be done with MRI scripts.
  If you find anything like this please let me know.

Comment 5 Martin Schulze 2017-08-02 09:55:17 UTC
Sorry about the confusion, I see now that it was worded ambiguously.
I tried the patch and it works.
Comment 6 cvs-commit@gcc.gnu.org 2017-08-02 11:13:48 UTC
The master branch has been updated by Nick Clifton <nickc@sourceware.org>:


commit 70b0cf90bc6c071895b989666bcf3e6eca7b99ce
Author: Nick Clifton <nickc@redhat.com>
Date:   Wed Aug 2 12:12:37 2017 +0100

    Add support for creating archives of slim-LTO modules using MRi script commands.
    	PR 21702
    	* arsup.c (ar_addmod): Add plugin support for the MRI ADDMOD
Comment 7 Nick Clifton 2017-08-02 11:15:02 UTC
Hi Martin,

  OK - I have applied the patch.  If more problems like this arise, please feel free to reopen this PR, or create a new one.

Comment 8 Martin Schulze 2017-08-02 11:16:56 UTC
I'll keep my eyes open. Thanks for the fast solution.