This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: passing optimization flags to the linker required for builds with gcc -flto
Type: Stage: resolved
Components: Build Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: doko, iritkatriel, lemburg, rpetrov
Priority: normal Keywords: needs review, patch

Created on 2010-04-26 11:00 by doko, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
make-lto.diff doko, 2010-04-26 11:00 review
Messages (9)
msg104217 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2010-04-26 11:00
Building with -flto (GCC 4.5.0) requires passing the very same optimization flags to the linker (lto1) as well. The attached patch just does this.  Tested on Linux only, I don't know what will/could break on on other systems/compilers.

Tested with a static build (--disable-shared) on x86_64. pybench results improve by 5% when building with 4.5.0 instead of 4.4.3, and by another 5% by building with -flto.
msg104221 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2010-04-26 11:22
Matthias Klose wrote:
> 
> New submission from Matthias Klose <doko@debian.org>:
> 
> Building with -flto (GCC 4.5.0) requires passing the very same optimization flags to the linker (lto1) as well. The attached patch just does this.  Tested on Linux only, I don't know what will/could break on on other systems/compilers.

On some systems, this may very well break, due to
configruations where LDFLAGS and CFLAGS contain
the same options.

While this is normally not much of a problem, some compilers may complain
about this.

E.g. GCC on Mac OS X complains about duplicate use of the -sysroot
option.

It's probably better to just pass OPT to the linker instead.
msg104222 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2010-04-26 11:27
> It's probably better to just pass OPT to the linker instead.

not enough, because -fno-strict-aliasing might be passed in BASE_CFLAGS.
msg104466 - (view) Author: Roumen Petrov (rpetrov) * Date: 2010-04-28 21:46
LDSHARED not always is compiler and I'm not sure that linkers always accept compiler flags .
After fix of issue xxx about CFLAGS and issues a, b, c, for LDFLAGS now all is passed to python build system and users could set argument to both variables : CFLAGS and LDFLAGS .
msg104505 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2010-04-29 13:42
Matthias Klose wrote:
> 
> Matthias Klose <doko@debian.org> added the comment:
> 
>> It's probably better to just pass OPT to the linker instead.
> 
> not enough, because -fno-strict-aliasing might be passed in BASE_CFLAGS.

Shouldn't -fno-strict-aliasing be added to OPT instead of
BASE_CFLAGS ? After all, it's an optimization settings.
msg104520 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2010-04-29 15:20
my understanding is that the builder is allowed to overwrite OPT, but not BASE_CFLAGS.
msg104865 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2010-05-03 18:11
Matthias Klose wrote:
> 
> Matthias Klose <doko@debian.org> added the comment:
> 
> my understanding is that the builder is allowed to overwrite OPT, but not BASECFLAGS.

The builder should actually be allowed to override the complete
CFLAGS and LDFLAGS settings, but for historic reasons, this is
currently not possible and you're right: OPT was meant to be overridden
by the user and BASECFLAGS is reserved for configure use.

Since just adding the CFLAGS to the linker invokation breaks on
various platforms (the linker doesn't expect compiler flags or
complains due to duplicate flags), this simple route will not work.

I suppose the best way to do this is by adding an extra check
to configure.in that tests whether the new GCC 4.5 option is supported
and also check whether CFLAGS can be passed to the
linker. If this test succeed, the configure script could then
add CFLAGS to the linker invokations or perhaps merge CFLAGS into
LDFLAGS.
msg220445 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-06-13 14:39
Is this still relevant as GCC 4.9.0 was released on April 22, 2014?
msg380479 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2020-11-06 22:23
I think this was resolved by issue9189.
History
Date User Action Args
2022-04-11 14:57:00adminsetgithub: 52781
2020-12-02 23:00:30iritkatrielsetstatus: pending -> closed
resolution: fixed
stage: resolved
2020-11-06 22:23:58iritkatrielsetstatus: open -> pending
nosy: + iritkatriel
messages: + msg380479

2019-03-15 23:11:55BreamoreBoysetnosy: - BreamoreBoy
2014-06-13 14:39:24BreamoreBoysetnosy: + BreamoreBoy
messages: + msg220445
2010-05-03 18:11:16lemburgsetmessages: + msg104865
2010-04-29 15:20:12dokosetmessages: + msg104520
2010-04-29 13:42:12lemburgsetmessages: + msg104505
2010-04-28 21:46:52rpetrovsetnosy: + rpetrov
messages: + msg104466
2010-04-26 11:27:17dokosetmessages: + msg104222
2010-04-26 11:22:42lemburgsetnosy: + lemburg
title: passing optimization flags to the linker required for builds with gcc -flto -> passing optimization flags to the linker required for builds with gcc -flto
messages: + msg104221
2010-04-26 11:00:41dokocreate