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
