Re: Recommended way to pass CFLAGS/LDFLAGS through libtool

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

 



On Monday, April 30, 2018 2:52:54 PM CEST Florian Weimer wrote:
> 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.

Hack as hell, yes :-(.  Do you have concrete issues with the
difficult-to-explain behavior?  I could help maybe.

That hack is opt-in by %_hardened_build (defined by default though) and
opt-out by '%define _configure_libtool_hardening_hack 0' if that matters.
Same as %_configure_gnuconfig_hack (more than hardening that one is
related to new arches).

> 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?

Dunno, it depends how much troubles that hack brings probably.

My feeling is that this discussion is driven by the hardening initiative,
which is a very good reason on one hand, no doubts;  but on the other hand
we can have very trivial post-build 'brp-*' whatever-script that will
protect us against accidental hardening mistakes.

> 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.

I'd vote against guidelines _forcing_ us to do autoreconf; that would
bring all sort of other issues:

 - additional non-determinism
 - additional BuildRequires, that means larger buildroots (and the set
   of build-requires is sometimes unknown;  there might be some 'make
   dist' dependency which is hard to obtain, there's also gnulib, etc.)
 - harder rebuildability; packages designed for fedora rawhide would be
   harder to rebuild against epel-6 (because there are older autotools),
   and vice versa -- tarballs released when RHEL5 was a thing would be
   harder to rebuild on Rawhide
 - upgrading of autotools themselves would be a bit harder because there
   would be much larger amount of re-autotooled packages; so more FTBFS
   bugs;  this might sound lame but btw., even though maintainers wanted
   it and IMO it would be probably very good thing -- we've never got acks
   for rebasing autotools in RHEL, except for gettext AFAIR

I know Debian guys live somehow with that rule.  Still I don't like it.

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

Alright, some guidelines saying why/when yes/no re-autotoolize would be
handy.

Pavel

> 
> 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 Users]     [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