[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GCC LTO options not correctly handled

From: Thomas Jahns
Subject: Re: GCC LTO options not correctly handled
Date: Mon, 15 Apr 2019 10:44:34 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 4/12/19 6:04 PM, Bob Friesenhahn wrote:
On Fri, 12 Apr 2019, Laurent Stacul wrote:

As I don't have the ownership on the project, I need to patch (and
provide a patch upstream). But this can be tedious on big projects, so
it would great if libtool don't filter the options like -fno-lto,

The path of least resistance is to use the GCC -Wl, or -Wc, syntax to pass options to the linker or compiler, respectively.  This already works well with Autoconf, Automake, and libtool.

Adding support to libtool to support particular GCC options is the path of greatest resistance.

Compiler and linker options tend to expand continually, and it is not reasonable to support them all.

You are right about that, but libtool considers anything with a -Wl prefix to be directed at itself unfortunately. Also the -Xlinker and -Xcompiler prefix cannot normally be used during configure tests. I maintain a package that uses libtool, and what I have come to rely on is to:

* switch all compilation and link tests to use libtool as early as
  possible (i.e. directly after AC_PROG_CC and LT_INIT)
* mask known flags that need to survive (like icc -shared-intel flag)
  with -Xcompiler and/or -Xlinker

For the reason you state above (the list of problematic flags only becoming longer), this is not entirely safe, but much better than educating users about the known problems.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]