Re: Recommended way to pass CFLAGS/LDFLAGS through libtool

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

 



On 04/09/2018 06:07 PM, Yaakov Selkowitz wrote:
On 2018-04-09 04:40, Florian Weimer wrote:
On 04/09/2018 11:21 AM, Yaakov Selkowitz wrote:
On 2018-04-09 03:59, Florian Weimer wrote:
Is there a recommend way to get libtool to pass through all flags
specified in CFLAGS and LDFLAGS unchanged, and have the GCC compiler
driver sort out which flags to pass to the compiler/assembler/linker?

$ libtool --mode=compile --help
[snip]
This mode accepts the following additional options:
[snip]
    -Wc,FLAG          pass FLAG directly to the compiler

$ libtool --mode=link --help
[snip]
The following components of LINK-COMMAND are treated specially:
[snip]
    -Wc,FLAG
    -Xcompiler FLAG   pass linker-specific FLAG directly to the compiler
    -Wl,FLAG
    -Xlinker FLAG     pass linker-specific FLAG directly to the linker

That doesn't solve the problem because there is a difference between
passing a flag to the *linker* and passing it to the *compiler driver*
while linking.

But, often when this happens, it is the fault of a poorly written
configure.ac or Makefile.am.  Where exactly are you seeing an issue?

Everywhere?  libtool does not pass -specs= arguments in LDFLAGS to the
linker invocation.

Then patch libtool.  I have in the past for similar issues, e.g.:

https://github.com/cygwinports/libtool/blob/master/2.4.5-pass-ldflags.patch

You will then have to assure that autoreconf is run within packages to
pick up the change.

We also have this in the %configure macro:

[ "%_configure_libtool_hardening_hack" = 1 ] && [ x != "x%{_hardened_ldflags}" ] && \
      for i in $(find . -name ltmain.sh) ; do \
%{__sed} -i.backup -e 's~compiler_flags=$~compiler_flags="%{_hardened_ldflags}"~' $i \
      done ; \

So we rewrite ltmain.sh in the source tree, which is extremely hackish and contributes to the difficult-to-explain variance in build behavior.

Should we factor this out from %configure, so that it can be used for packages which do not use autoconf with libtool, only the latter?

Such we change the guidelines to always run autoreconf? This would also help with new architecture bringup because those often need autotools fixes, but it will choke on really old or manually patched upstream configure scripts.

In any case, I think we need to document the available options and upsides and downsides.

Thanks,
Florian
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux