| Message ID | 20201017221743.160029-4-nolange79@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [v2,1/4] package/Makefile.in: use gcc wrappers for binutils tools | expand |
Norbert, All, On 2020-10-18 00:17 +0200, Norbert Lange spake thusly: > glibc requires compilation barriers between files, and will > fail with LTO enabled. > So force LTO off by appending -fno-lto to the flags, but only > if the GCC version is recent enough that an LTO build would > be possible. > > Signed-off-by: Norbert Lange <nolange79@gmail.com> Applied to master, thanks. Are the other C libraries (uClibc, musl) also affected by such an issue? Regards, Yann E. MORIN. > --- > package/glibc/glibc.mk | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk > index 4721177d83..6d07495edc 100644 > --- a/package/glibc/glibc.mk > +++ b/package/glibc/glibc.mk > @@ -67,6 +67,11 @@ ifeq ($(BR2_ENABLE_DEBUG),y) > GLIBC_EXTRA_CFLAGS += -g > endif > > +# glibc explicitly requires compile barriers between files > +ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_4_7),y) > +GLIBC_EXTRA_CFLAGS += -fno-lto > +endif > + > # The stubs.h header is not installed by install-headers, but is > # needed for the gcc build. An empty stubs.h will work, as explained > # in http://gcc.gnu.org/ml/gcc/2002-01/msg00900.html. The same trick > -- > 2.28.0
Yann E. MORIN <yann.morin.1998@free.fr> schrieb am So., 9. Jan. 2022, 23:31: > Norbert, All, > > On 2020-10-18 00:17 +0200, Norbert Lange spake thusly: > > glibc requires compilation barriers between files, and will > > fail with LTO enabled. > > So force LTO off by appending -fno-lto to the flags, but only > > if the GCC version is recent enough that an LTO build would > > be possible. > > > > Signed-off-by: Norbert Lange <nolange79@gmail.com> > > Applied to master, thanks. > > Are the other C libraries (uClibc, musl) also affected by such an issue? > Likely, and unless they are tested with LTO I would not trust them to not have weird runtime issues. Ideally there would be a whitelist for packages doing fine with LTO, for now I can only vouch for the couple I am using LTOed since years. Since a few distros now use LTO by default, hopefully things will get better. Norbert
On 10/01/2022 00:09, Norbert Lange wrote: > > > Yann E. MORIN <yann.morin.1998@free.fr <mailto:yann.morin.1998@free.fr>> schrieb > am So., 9. Jan. 2022, 23:31: > > Norbert, All, > > On 2020-10-18 00:17 +0200, Norbert Lange spake thusly: > > glibc requires compilation barriers between files, and will > > fail with LTO enabled. > > So force LTO off by appending -fno-lto to the flags, but only > > if the GCC version is recent enough that an LTO build would > > be possible. > > > > Signed-off-by: Norbert Lange <nolange79@gmail.com > <mailto:nolange79@gmail.com>> > > Applied to master, thanks. > > Are the other C libraries (uClibc, musl) also affected by such an issue? > > > Likely, and unless they are tested with LTO I would not trust them to not have > weird runtime issues. > > Ideally there would be a whitelist for packages doing fine with LTO, for now I > can only vouch for the couple I am using LTOed since years. Up to now, the idea was that packages that support LTO would check for it themselves in their configure step and enable it if available. It would be a good idea though to add a global option to enable LTO, similar to SSP etc. The first step for that would be to add a hidden symbol that indicates if the toolchain has LTO, and that gets selected by the toolchains that have LTO. Then we have to look at each external toolchain to verify if LTO is available, and add a checker function to validate that it is correct. Finally, we can randomly turn on the LTO option in the genrandconfig script, and fix the fallout on abo. Regards, Arnout > > Since a few distros now use LTO by default, hopefully things will get better. > > Norbert > > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org > https://lists.buildroot.org/mailman/listinfo/buildroot >
diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk index 4721177d83..6d07495edc 100644 --- a/package/glibc/glibc.mk +++ b/package/glibc/glibc.mk @@ -67,6 +67,11 @@ ifeq ($(BR2_ENABLE_DEBUG),y) GLIBC_EXTRA_CFLAGS += -g endif +# glibc explicitly requires compile barriers between files +ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_4_7),y) +GLIBC_EXTRA_CFLAGS += -fno-lto +endif + # The stubs.h header is not installed by install-headers, but is # needed for the gcc build. An empty stubs.h will work, as explained # in http://gcc.gnu.org/ml/gcc/2002-01/msg00900.html. The same trick
glibc requires compilation barriers between files, and will fail with LTO enabled. So force LTO off by appending -fno-lto to the flags, but only if the GCC version is recent enough that an LTO build would be possible. Signed-off-by: Norbert Lange <nolange79@gmail.com> --- package/glibc/glibc.mk | 5 +++++ 1 file changed, 5 insertions(+)