On 04/30/2018 04:08 PM, Pavel Raiskup wrote:
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.
I meant that two similar-looking packages have different behavior
because one uses %configure and ends up rewriting ltmain.sh, and another
does not. It's not clear why invoking %configure would have this effect.
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.
The main goal would be to make it usable without %configure, not to
disable it with %configure.
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.
There's isn't much that is trivial in this area. 8-(
We could have a brp-* check, but then you'd still need to figure out
*why* maintainers disable it.
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
That depends on how you look at it. Source + buildroot would be more
deterministic because it takes the upstream release engineering
environment out of the question.
- 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.
Yes, those are complicated trade-offs.
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.
Agreed. We could include them here:
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md
Although it is not strictly related.
(I haven't had any success in updating the thoroughly outdated packaging
guidelines, so I had to start something separate.)
Thanks,
Florian
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
