Re: GCC LTO options not correctly handled

Thomas Jahns <[email protected]>
Newsgroups gmane.comp.gnu.libtool.general
Message-ID <[email protected]>
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,
>> -fno-whopr.
> 
> 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.

Thomas

_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.