GCC 10.1 released

[InBetweenNames]

https://gcc.gnu.org/pipermail/gcc/2020-May/232334.html

This issue has been made to track GCC 10.1 as a system wide compiler. There's a few differences with GCC 10 last time I checked that might make this a not so straightforward upgrade compared to the 9 series. If you are on GCC 10 right now, you can use this thread to share your experiences.

[InBetweenNames]

Of particular interest is the new lto-dump utility: https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Invoking-lto-dump.html#Invoking-lto-dump

[InBetweenNames]

As mentioned in another issue:

GCC now defaults to -fno-common. As a result, global variable accesses are more efficient on various targets. In C, global variables with multiple tentative definitions now result in linker errors. With -fcommon such definitions are silently merged during linking. 

[Jannik2099]

Please share all -fno-common related compile failures with https://bugs.gentoo.org/705764

[skinkie]

Trying to compile media-gfx/imagemagick-7.0.10.9 which fails with gcc 10 and lto. Without LTO it compiles.

[Althorion]

It seems like a good spot to go back and reevaluate which workarounds are still needed. What would be the best way to do so? Just directly edit the ltoworkarounds.conf file? Unmerge it and copy-paste it back?

[Jannik2099]

pretty much yes. gcc 10 brought a lot of fixes to LTO, I'd start with that

[PeeJay]

dev-python/dbus-python-1.2.16 is causing errors. Adding dev-python/dbus-python *FLAGS-=-flto* to ltoworkarounds.conf fixes it.

libtool: link: /usr/bin/x86_64-pc-linux-gnu-nm -B  dbus_bindings/.libs/abstract.o dbus_bindings/.libs/bus.o dbus_bindings/.libs/bytes.o dbus_bindings/.libs/conn.o dbus_bindings/.libs/conn-methods.o dbus_bindings/.libs/containers.o dbus_bindings/.libs/debug.o dbus_bindings/.libs/exceptions.o dbus_bindings/.libs/float.o dbus_bindings/.libs/generic.o dbus_bindings/.libs/int.o dbus_bindings/.libs/unixfd.o dbus_bindings/.libs/libdbusconn.o dbus_bindings/.libs/mainloop.o dbus_bindings/.libs/message-append.o dbus_bindings/.libs/message.o dbus_bindings/.libs/message-get-args.o dbus_bindings/.libs/module.o dbus_bindings/.libs/pending-call.o dbus_bindings/.libs/server.o dbus_bindings/.libs/signature.o dbus_bindings/.libs/string.o dbus_bindings/.libs/validation.o   |  | /bin/sed 's/.* //' | sort | uniq > .libs/_dbus_bindings.exp
./libtool: eval: line 1774: syntax error near unexpected token `|'
./libtool: eval: line 1774: `/usr/bin/x86_64-pc-linux-gnu-nm -B  dbus_bindings/.libs/abstract.o dbus_bindings/.libs/bus.o dbus_bindings/.libs/bytes.o dbus_bindings/.libs/conn.o dbus_bindings/.libs/conn-methods.o dbus_bindings/.libs/containers.o dbus_bindings/.libs/debug.o dbus_bindings/.libs/exceptions.o dbus_bindings/.libs/float.o dbus_bindings/.libs/generic.o dbus_bindings/.libs/int.o dbus_bindings/.libs/unixfd.o dbus_bindings/.libs/libdbusconn.o dbus_bindings/.libs/mainloop.o dbus_bindings/.libs/message-append.o dbus_bindings/.libs/message.o dbus_bindings/.libs/message-get-args.o dbus_bindings/.libs/module.o dbus_bindings/.libs/pending-call.o dbus_bindings/.libs/server.o dbus_bindings/.libs/signature.o dbus_bindings/.libs/string.o dbus_bindings/.libs/validation.o   |  | /bin/sed 's/.* //' | sort | uniq > .libs/_dbus_bindings.exp'
make[2]: *** [Makefile:1284: _dbus_bindings.la] Error 2
make[2]: *** Waiting for unfinished jobs....
libtool: link: ( cd "test/.libs" && rm -f "dbus_py_test.la" && ln -s "../dbus_py_test.la" "dbus_py_test.la" )
libtool: link: /usr/bin/x86_64-pc-linux-gnu-nm -B  dbus_glib_bindings/.libs/module.o   dbus-gmain/.libs/libdbus-gmain.a |  | /bin/sed 's/.* //' | sort | uniq > .libs/_dbus_glib_bindings.exp
./libtool: eval: line 1774: syntax error near unexpected token `|'
./libtool: eval: line 1774: `/usr/bin/x86_64-pc-linux-gnu-nm -B  dbus_glib_bindings/.libs/module.o   dbus-gmain/.libs/libdbus-gmain.a |  | /bin/sed 's/.* //' | sort | uniq > .libs/_dbus_glib_bindings.exp'
make[2]: *** [Makefile:1295: _dbus_glib_bindings.la] Error 2
make[2]: Leaving directory '/var/tmp/portage/dev-python/dbus-python-1.2.16/work/dbus-python-1.2.16-python2_7'
make[1]: *** [Makefile:1626: all-recursive] Error 1
make[1]: Leaving directory '/var/tmp/portage/dev-python/dbus-python-1.2.16/work/dbus-python-1.2.16-python2_7'
make: *** [Makefile:1022: all] Error 2

[thubble]

@PeeJay That looks like https://bugs.gentoo.org/708340 - you need to install sys-devel/binutils-2.34-r1 which is currently unkeyworded.

[InBetweenNames]

FYI: I managed to find exactly the -fno-common bugs in GentooLTO that aren't filed on the Gentoo Bugzilla:

app-crypt/staticgpg
app-text/mupdf
dev-lang/R
dev-lang/erlang
dev-lang/orc
dev-libs/dbus-glib
dev-libs/ffcall
dev-libs/fribidi
dev-libs/gobject-introspection
dev-libs/libltdl
dev-libs/libmspack
dev-libs/libpipeline
dev-python/dbus-python
dev-python/nautilus-python
dev-util/pkgconf
gnome-base/gnome-control-center
gnome-base/librsvg
gui-apps/wl-clipboard
media-gfx/imagemagick
media-libs/gstreamer
media-libs/openal
media-sound/mpg123
media-sound/sox
media-sound/wavpack
net-analyzer/openvas-manager
net-libs/libmbim
net-libs/libqmi
net-misc/iputils
net-misc/modemmanager
net-misc/socat
net-misc/vinagre
net-vpn/libreswan
net-print/cups-filters
sys-apps/usbredir
sys-devel/bmake
sys-power/upower
x11-libs/gtk+
x11-libs/pango
x11-libs/xcb-util-cursor
x11-libs/xcb-util-xrm

If anyone knows of a way of automating the posting of that to the Bugzilla, please let me know! It seems like a rather tedious task to enter each individual package as a bug.

[InBetweenNames]

OK, after re-testing each package, I narrowed it down to this list:

dev-libs/ffcall
dev-libs/libmspack
media-sound/wavpack
dev-libs/dbus-glib
dev-libs/fribidi
x11-libs/xcb-util-cursor
dev-python/dbus-python
dev-libs/libpipeline
sys-apps/usbredir
x11-libs/xcb-util-xrm
net-libs/libmbim
sys-power/upower
net-misc/modemmanager
x11-libs/pango
media-sound/sox
media-sound/mpg123
dev-python/nautilus-python

[InBetweenNames]

Reference #484

[InBetweenNames]

Reference #23

[InBetweenNames]

Reference #38

[InBetweenNames]

After re-testing with the lt_cv_sys_global_symbol_pipe and lt_cv_sys_global_symbol_to_cdecl hack, the only package that doesn't build is dev-python/nautilus-python

[petronio]

I'll be re-testing my branch as well with the new binutils and GCC 10. Hopefully it removes all the sed replacement errors and I can just close it out.

[InBetweenNames]

@petronio I'll be publishing a new sys-config/ltoize version momentarily with a new bashrc.d hook that can be set conditionally per package, or globally via make.conf, that will apply the sed hack for you. If you're still having trouble, consider trying that out.

[petronio]

@InBetweenNames So far looks like it'll be fine. I unmasked binutils-2.34-r1 and installed that. So far three of the packages I had lto disabled on built and installed fine.

[InBetweenNames]

Great! I'm going to do a GCC 10 test run and if that works well, I will send out a notice saying when GentooLTO will officially change to the new compiler.

[jonesmz]

When you say that gentooLTO will officially change to the new compiler, are you meaning that GCC 10 will be keyworded as stable? Or simply that gentooLTO will be able to work fine with GCC 10?

I'm not excited about having GCC 10 made stable on my system unless the stability is from the main portage tree.

[InBetweenNames]

GCC 10 will be the standard recommended configuration for GentooLTO, yes -- much like how we moved using previous releases. Note that upstream Gentoo is also very interested in using GCC 10, with many issues tracking -fcommon and the like in the main Portage tree. But we're not rushing into anything, here. It's supported, you can start using GCC 10 right now if you want even (and we do need people to start doing that), but we haven't tried it enough to see about any showstoppers with it for GentooLTO by default. For now, I'd like to wait a week or two and test it out more thoroughly before announcing the official switchover date. If there are showstoppers, then we'll wait for GCC 10.2, but GCC has so far been good about prioritizing regressions in recent releases. I think it's likely everything will be fine.

If you're concerned about your system stability even after the switchover date is announced, you might consider holding back using GCC 9, but note that workarounds will be tested with GCC 10 only, and might not be accepted if an issue is present with GCC 9 and not with GCC 10. Alternatively, consider running -O2 -ftree-vectorize -flto -march=native, perhaps with -mprefer-vector-width=128 if appropriate, which should be a conservative improvement over the stock Gentoo configuration.

[jonesmz]

My only concern was that GCC 10.1 not suddenly find itself stable on my system.

I'm happy to accept breakage by using GCC 9 with gentooLTO if that's an unsupported configuration.

[cryptopsy0]

Are the workarounds in ltoworkarounds.conf automatically applied? I am still getting fribidi pipe error that goes away with nolto forced by env

https://raw.githubusercontent.com/InBetweenNames/gentooLTO/05965d113f5da37fc5428de658fb3c25016bf3c9/sys-config/ltoize/files/package.cflags/ltoworkarounds.conf

[cryptopsy0]

neovim broken:
http://sprunge.us/ye8Lwc

[cryptopsy0]

some emerge -e @System with nolto fix that worked and some that it didn't help:

# nolto fix
dev-libs/fribidi nolto
dev-libs/libpipeline nolto
sys-devel/getttext nolto
sys-devel/gcc nolto
app-crypt/p11-kit nolto
sys-fs/fuse nolto
app-crypt/gcr nolto

#broken even with nolto
gnome-base/gnome-keyring nolto
sys-auth/polkit nolto
app-crypt/gpgme nolto
app-text/djvu nolto
x11-libs/gtk+ nolto
dev-utils/cmake nolto
x11-libs/pango nolto
gnome-base/librsvg nolto
net-libs/gnutls nolto
net-misc/curl nolto
app-text/opensp nolto
sys-apps/man-db nolto
app-crypt/libsecret nolto
dev-libs/gmp nolto
dev-libs/boehm-gc nolto
media-libs/lcms nolto
dev-libs/mpfr nolto
media-libs/glu nolto
x11-libs/cairo nolto

nolto is an env that i force with /etc/portage/package.env
There was no point continuing with emerge -e @world. Gcc-10.1

[InBetweenNames]

The pipe error can be fixed with a new workaround introduced. I haven't documented it yet (haven't had time) but you can try setting NOCOMMON_OVERRIDE_LIBTOOL=yes on affected packages to see if that works around it. It's a bug in old versions of libtool found in those packages.

[ghost]

I'm new to GentooLTO, but I come to say that neovim fixed by accepting keyword 9999.

[Phoenix591]

x11-libs/cairo nolto is needed. It built with lto, but was broken (missing link to pthread, I ran into libcairo.so: error: undefined reference to 'pthread_mutexattr_settype' when trying to build the second thing that required it, app-text/texlive-core-2020-r5 , the first thing that built ok was harfbuzz fyi) until I rebuilt it, and now its properly linked to pthread.

[shelterx]

Yes, Curl fails, any fix for it?

[petronio]

@shelterx Are you having build or runtime issues? If it's runtime, check that your CURL_SSL variable matches whatever you have as the use flag in the curl package. They made changes to the package recently and it's a bit confusing and breaks things.

[shelterx]

Hmm... seems like it was the pipe error which @InBetweenNames provided a fix for above, I didn't see the actual error yesterday blind.

EDIT: Well, it didn't help with NOCOMMON_OVERRIDE_LIBTOOL=yes.

 |  | /bin/sed 's/.* //' | sort | uniq > .libs/libcurl.exp
../libtool: eval: line 1777: syntax error near unexpected token `|'

[telans]

You might want to bump your binutils, if it's not at the latest

[shelterx]

I tried with a newer binutils, didn't help.
It's weird tho, on another gentoo machine I have curl doesn't dump the above error.

[shelterx]

Now curl built fine, I don't know what fixed it but I used unstable binutils... suddenly it worked after running emerge -c after a system upgrade.

[ghost]

I am new to Gentoo LTO and somewhat new to gentoo as well. How do you define NOCOMMON_OVERRIDE_LIBTOOL=yes per package from the instructions in the wiki?