Re: binutils: s390x: fails to link systemd binaries using LTO
On 2017-06-21 00:21, Michael Biebl wrote: > Hi Aurelien > > Am 20.06.2017 um 23:56 schrieb Aurelien Jarno: > > Could you please Cc the s390x porters next time? That would make us > > notice the issue faster. > > Hm, when filing the bug report I used X-Debbugs-CC and got this > confirmation: > > As you requested using X-Debbugs-CC, your message was also forwarded to > debian-s390@lists.debian.org > > Did this not reach the correct mailing list? The mailing list is correct. That said, I don't see any track of the original email in my mbox nor on the web archive. It might also be a problem with the BTS. > > The problem is related to the fact that gold is not available on s390x. > > It seems gold is less strict than ld in having to link with each used > > library. The problem can be fully reproduced on amd64 by using ld instead > > of gold: > > > > --- a/meson.build > > +++ b/meson.build > > @@ -312,7 +312,7 @@ link_test_c = files('tools/meson-link-test.c') > > foreach arg : ['-Wl,-z,relro', > > '-Wl,-z,now', > > '-pie', > > - '-Wl,-fuse-ld=gold', > > + '-Wl,-fuse-ld=ld', > >] > > > > have = run_command(check_compilation_sh, > > > > > > Now to come back to the problem, the test is linked against > > src/libsystemd/libsystemd.a which uses pthread_sigmask. It looks > > therefore normal to add -lpthread to link it. > > Thanks for having a look. Will forward this issue to systemd upstream > after verifying that adding -lpthread fixes the issue. Thanks. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: binutils: s390x: fails to link systemd binaries using LTO
Hi Aurelien Am 20.06.2017 um 23:56 schrieb Aurelien Jarno: > Could you please Cc the s390x porters next time? That would make us > notice the issue faster. Hm, when filing the bug report I used X-Debbugs-CC and got this confirmation: As you requested using X-Debbugs-CC, your message was also forwarded to debian-s390@lists.debian.org Did this not reach the correct mailing list? > The problem is related to the fact that gold is not available on s390x. > It seems gold is less strict than ld in having to link with each used > library. The problem can be fully reproduced on amd64 by using ld instead > of gold: > > --- a/meson.build > +++ b/meson.build > @@ -312,7 +312,7 @@ link_test_c = files('tools/meson-link-test.c') > foreach arg : ['-Wl,-z,relro', > '-Wl,-z,now', > '-pie', > - '-Wl,-fuse-ld=gold', > + '-Wl,-fuse-ld=ld', >] > > have = run_command(check_compilation_sh, > > > Now to come back to the problem, the test is linked against > src/libsystemd/libsystemd.a which uses pthread_sigmask. It looks > therefore normal to add -lpthread to link it. Thanks for having a look. Will forward this issue to systemd upstream after verifying that adding -lpthread fixes the issue. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: binutils: s390x: fails to link systemd binaries using LTO
On 2017-06-19 23:50, Michael Biebl wrote: > On Tue, 30 May 2017 22:21:04 +0200 Michael Biebl wrote: > > Package: binutils > > Version: 2.28-5 > > Severity: normal > > User: debian-s390@lists.debian.org > > Usertags: s390x > > > > Hi, > > > > we run into a strange issue when trying to compile systemd git master > > using meson. The build/link failure is s390x specific so I've CCed the > > s390x porters mailing list. The problem is easily reproducible on the > > zelenka porterbox. with the following commands: > > > > sessionid=$(schroot -b -c sid) > > dd-schroot-cmd -c $sessionid apt-get update > > dd-schroot-cmd -c $sessionid apt-get upgrade -y > > dd-schroot-cmd -c $sessionid apt-get build-dep systemd -y > > dd-schroot-cmd -c $sessionid apt-get install meson git -y > > schroot -r -c $sessionid > > git clone https://github.com/systemd/systemd > > cd systemd > > export LANG=C.UTF-8 > > meson -Db_lto=true -Dlink-udev-shared=false build > > ninja -C build > > > > This will lead to a failure to link the systemd-networkd, > > test-network-tables and test-network binaries. I've attached the > > relevant excerpt from the build log. > > > > Since this issue seems to be arch specific, this appears to be a problem > > in the s390x toolchain and not systemd itself. > > > > We would appreciate if the s390(x) porters could have a look. Could you please Cc the s390x porters next time? That would make us notice the issue faster. > Any feedback fro the s390 porters? The problem is related to the fact that gold is not available on s390x. It seems gold is less strict than ld in having to link with each used library. The problem can be fully reproduced on amd64 by using ld instead of gold: --- a/meson.build +++ b/meson.build @@ -312,7 +312,7 @@ link_test_c = files('tools/meson-link-test.c') foreach arg : ['-Wl,-z,relro', '-Wl,-z,now', '-pie', - '-Wl,-fuse-ld=gold', + '-Wl,-fuse-ld=ld', ] have = run_command(check_compilation_sh, Now to come back to the problem, the test is linked against src/libsystemd/libsystemd.a which uses pthread_sigmask. It looks therefore normal to add -lpthread to link it. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#852572: s390-tools: Update udevadm path
On Wed, 25 Jan 2017 14:42:36 +0100 bi...@debian.org wrote: > According to codesearch [1] your package s390-tools does hard-code the > udevadm path as /sbin/udevadm. > > Please change that to /bin/udevadm. You might also consider not hard-coding the path at all, and simply rely on PATH being set properly. This should be a safe assumption, especially since the binary is now in /bin Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#852572: s390-tools: Update udevadm path
On Wed, 25 Jan 2017 14:42:36 +0100 bi...@debian.org wrote: > Package: s390-tools > Version: 1.36.1-1 > Severity: normal > User: pkg-systemd-maintain...@lists.alioth.debian.org > Usertags: udevadm > > Hi, > > since Jessie, the udevadm binary is available as /bin/udevadm. > To not break existing scripts, which use the old /sbin/udevadm path, > the udev package currently ships a compat symlink which we would like > to drop eventually (in buster or buster+1). > > According to codesearch [1] your package s390-tools does hard-code the > udevadm path as /sbin/udevadm. > > Please change that to /bin/udevadm. With stretch being released and buster open for development, it would be a great opportunity to get this fixed now. So please consider adding this change in your next upload. If you are worried about backports: /bin/udevadm is already available in Debian jessie (oldstable) or Ubuntu trusty (14.04LTS). So it's safe to use the /bin/udevadm path. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
What to do during the Holidays? Read ZebraBooks, of course!
You know better than anyone, the holidays are coming soon! Having trouble viewing this email? click here Dear mum of a tiny holidaymaker, Dear dad of a baby beach bum, You know better than anyone, the holidays are coming soon! Yippee (with a hint of 'Help!').What are you going to do with your little mermaids and mermen during all that free time?Read ZebraBooks, of course! With their own personalised book featuring their name, you'll win them over (and, maybe, get a few minutes of peace)!Discover now the book of your child by cliking here! (There is a dicount of £8 until the 25th of June, yeah, so hurrry up )!We promise you won't be disappointed. If you no longer wish to receive our emails, click here