Bug#845193: [Pkg-openssl-devel] Bug#845193: dpkg: recent -specs PIE changes break openssl
On 2016-12-28 17:01:10 [+0100], Kurt Roeckx wrote: > On Wed, Dec 28, 2016 at 02:59:18PM +0100, Sebastian Andrzej Siewior wrote: > > On 2016-12-08 01:20:06 [+0100], Guillem Jover wrote: > > > Hi! > > Hi, > > > > > The actual problem here, is that for whatever reason on x32 and only > > > x32, the build system is (as I noted in #845193#10) calling link_a.gnu > > > instead of the link_o.gnu target, which tries to link a static library > > > composed of PIE objects into a shared library, which makes it fail. > > > > so is there anything we need to do on the openssl side? > > Figure out why it uses link_a instead of link_o, and maybe fix it? So I assumed that this is something not related to openssl but I've been wrong then. And I didn't get why that "-specs" thing is used for PIE but… So we crash in the testsuite while doing | ssltest -key keyU.ss -cert certU.ss -c_key keyU.ss -c_cert certU.ss -cipher AES128-SHA -bytes 8m and according to gdb somewhere in the asm corner. So going from x86_64_asm to no_asm makes it build. Is there a reason why we should fix asm for x32 in the old openssl while it seems to work in 1.1.0? Otherwise I would drop the asm for x32 and be done with it. btw: During the build I saw |gcc: note: pie specs /usr/share/dpkg/pie-compile.specs ignored when pie is not enabled |gcc: note: pie specs /usr/share/dpkg/pie-link.specs ignored when pie is not enabled after each gcc line. This pops up also with openssl 1.1.0 but I don't see it in any for of the build logs (for 1.0.2 or 1.1.0) so it must be new. > Kurt Sebastian
Bug#845193: [Pkg-openssl-devel] Bug#845193: dpkg: recent -specs PIE changes break openssl
On Wed, Dec 28, 2016 at 02:59:18PM +0100, Sebastian Andrzej Siewior wrote: > On 2016-12-08 01:20:06 [+0100], Guillem Jover wrote: > > Hi! > Hi, > > > The actual problem here, is that for whatever reason on x32 and only > > x32, the build system is (as I noted in #845193#10) calling link_a.gnu > > instead of the link_o.gnu target, which tries to link a static library > > composed of PIE objects into a shared library, which makes it fail. > > so is there anything we need to do on the openssl side? Figure out why it uses link_a instead of link_o, and maybe fix it? Kurt
Bug#845193: [Pkg-openssl-devel] Bug#845193: dpkg: recent -specs PIE changes break openssl
On 2016-12-08 01:20:06 [+0100], Guillem Jover wrote: > Hi! Hi, > The actual problem here, is that for whatever reason on x32 and only > x32, the build system is (as I noted in #845193#10) calling link_a.gnu > instead of the link_o.gnu target, which tries to link a static library > composed of PIE objects into a shared library, which makes it fail. so is there anything we need to do on the openssl side? > Thanks, > Guillem Sebastian
Bug#845193: [Pkg-openssl-devel] Bug#845193: dpkg: recent -specs PIE changes break openssl
Hi! On Wed, 2016-11-30 at 22:00:12 +0100, Kurt Roeckx wrote: > On Wed, Nov 30, 2016 at 07:55:55PM +, Thorsten Glaser wrote: > > Kurt Roeckx dixit: > > >> Unfortunately, I have no idea; 1.1 builds, 1.0 doesn’t. > > > > > >But both are actually in installed state now? > > Yes because I built it in a chroot in which I downgraded dpkg > > to .10, which led to a completely fine build of openssl1.0 > > with testsuite enabled even. > > > > >And if only 1.0 is affected, I'm not sure why it's assigned to the > > >openssl source package. > > > > I’m not sure why Guillem reassigned the bug either, considering > > I cloned it in the first place to have one part in openssl1.0 > > and one in dpkg (or, more likely, gcc-6)… > > So I'm rather confused. I at least see some mention of a log with > -fPIC before the -specs, and then failing to link because it's not > build using -fPIC but the specs override that to use -fPIE. So I > would need to find a way to move the -fPIC after the flags set by > dpkg. But I don't actually find any log on buildd.debian.org that > shows that problem. > > In any case, 1.1 seems to place the -fPIC after the CFLAGS from > dpkg, so I guess moving it around will fix things. When using the specs files the order is irrelevant, at least relative to options vs specs. So moving the flags after the specs should not change anything, see this example session on amd64: ,--- $ gcc -pie -fPIE -specs=/usr/share/dpkg/no-pie-compile.specs \ -specs=/usr/share/dpkg/no-pie-link.specs -o test test.c $ readelf -h test|grep Type Type: DYN (Shared object file) $ gcc -specs=/usr/share/dpkg/no-pie-compile.specs \ -specs=/usr/share/dpkg/no-pie-link.specs -pie -fPIE -o test test.c $ readelf -h test|grep Type Type: DYN (Shared object file) $ gcc -specs=/usr/share/dpkg/no-pie-compile.specs \ -specs=/usr/share/dpkg/no-pie-link.specs -o test test.c $ readelf -h test|grep Type Type: EXEC (Executable file) $ gcc -specs=/usr/share/dpkg/no-pie-compile.specs \ -specs=/usr/share/dpkg/no-pie-link.specs \ -specs=/usr/share/dpkg/pie-compile.specs \ -specs=/usr/share/dpkg/pie-link.specs -o test test.c $ readelf -h test|grep Type Type: DYN (Shared object file) `--- The actual problem here, is that for whatever reason on x32 and only x32, the build system is (as I noted in #845193#10) calling link_a.gnu instead of the link_o.gnu target, which tries to link a static library composed of PIE objects into a shared library, which makes it fail. Thanks, Guillem
Bug#845193: [Pkg-openssl-devel] Bug#845193: dpkg: recent -specs PIE changes break openssl
On Wed, 2016-11-30 at 19:55:55 +, Thorsten Glaser wrote: > Kurt Roeckx dixit: > >And if only 1.0 is affected, I'm not sure why it's assigned to the > >openssl source package. It's not. > I’m not sure why Guillem reassigned the bug either, considering > I cloned it in the first place to have one part in openssl1.0 > and one in dpkg (or, more likely, gcc-6)… Yes, and that's why I reassigned one part precisely to openssl1.0 and not openssl. :) Thanks, Guillem
Bug#845193: [Pkg-openssl-devel] Bug#845193: dpkg: recent -specs PIE changes break openssl
Kurt Roeckx dixit:
>But the errors I've always been seeing is a segfault during the
>tests, and I have no idea what that is about.
That didn't happen for me, but I found a wrong codegen bug in a
testsuite recently (probably not the cause here), we had kernel
issues (4.7 is broken, 4.8 is mostly ok though) and are still
trying to figure out libc issues that differ depending on CPU
model (stuff like AMD vs. Intel)… this is all a minefield.
bye,
//mirabilos
--
> emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig
> bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;)
Hallo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
... pine-User, und das auch noch gewohnheitsmäßig ("Oooohhh"). [aus dasr]
Bug#845193: [Pkg-openssl-devel] Bug#845193: dpkg: recent -specs PIE changes break openssl
On Wed, Nov 30, 2016 at 07:55:55PM +, Thorsten Glaser wrote: > Kurt Roeckx dixit: > > >> Unfortunately, I have no idea; 1.1 builds, 1.0 doesn’t. > > > >But both are actually in installed state now? > > Yes because I built it in a chroot in which I downgraded dpkg > to .10, which led to a completely fine build of openssl1.0 > with testsuite enabled even. > > >And if only 1.0 is affected, I'm not sure why it's assigned to the > >openssl source package. > > I’m not sure why Guillem reassigned the bug either, considering > I cloned it in the first place to have one part in openssl1.0 > and one in dpkg (or, more likely, gcc-6)… So I'm rather confused. I at least see some mention of a log with -fPIC before the -specs, and then failing to link because it's not build using -fPIC but the specs override that to use -fPIE. So I would need to find a way to move the -fPIC after the flags set by dpkg. But I don't actually find any log on buildd.debian.org that shows that problem. In any case, 1.1 seems to place the -fPIC after the CFLAGS from dpkg, so I guess moving it around will fix things. But the errors I've always been seeing is a segfault during the tests, and I have no idea what that is about. Kurt
Bug#845193: [Pkg-openssl-devel] Bug#845193: dpkg: recent -specs PIE changes break openssl
Kurt Roeckx dixit: >> Unfortunately, I have no idea; 1.1 builds, 1.0 doesn’t. > >But both are actually in installed state now? Yes because I built it in a chroot in which I downgraded dpkg to .10, which led to a completely fine build of openssl1.0 with testsuite enabled even. >And if only 1.0 is affected, I'm not sure why it's assigned to the >openssl source package. I’m not sure why Guillem reassigned the bug either, considering I cloned it in the first place to have one part in openssl1.0 and one in dpkg (or, more likely, gcc-6)… bye, //mirabilos -- Stéphane, I actually don’t block Googlemail, they’re just too utterly stupid to successfully deliver to me (or anyone else using Greylisting and not whitelisting their ranges). Same for a few other providers such as Hotmail. Some spammers (Yahoo) I do block.
Bug#845193: [Pkg-openssl-devel] Bug#845193: dpkg: recent -specs PIE changes break openssl
On Wed, Nov 30, 2016 at 12:07:44PM +, Thorsten Glaser wrote: > Kurt Roeckx dixit: > > >So can someone explain what needs to be fixed in openssl? The > >order of the CFLAGS needs to be changed? > > Unfortunately, I have no idea; 1.1 builds, 1.0 doesn’t. But both are actually in installed state now? And if only 1.0 is affected, I'm not sure why it's assigned to the openssl source package. Kurt
Bug#845193: [Pkg-openssl-devel] Bug#845193: dpkg: recent -specs PIE changes break openssl
Kurt Roeckx dixit: >So can someone explain what needs to be fixed in openssl? The >order of the CFLAGS needs to be changed? Unfortunately, I have no idea; 1.1 builds, 1.0 doesn’t. If you have an amd64 host (recent enough but not kernel 4.7) you can add syscall.x32=y to GRUB_CMDLINE_LINUX and then use your favourite out of pbuilder/cowbuilder/sbuild to try things in an x32 chroot. bye, //mirabilos -- Stéphane, I actually don’t block Googlemail, they’re just too utterly stupid to successfully deliver to me (or anyone else using Greylisting and not whitelisting their ranges). Same for a few other providers such as Hotmail. Some spammers (Yahoo) I do block.
Bug#845193: [Pkg-openssl-devel] Bug#845193: dpkg: recent -specs PIE changes break openssl
On Wed, Nov 30, 2016 at 05:38:45AM +0100, Guillem Jover wrote: > Control: reassign -1 openssl1.0 > > On Thu, 2016-11-24 at 14:52:33 +, Thorsten Glaser wrote: > > clone 845193 -1 > > reassign -1 dpkg > > retitle -1 dpkg: please do not add -specs= flags only on some architectures > > thanks > > > > Guillem Jover dixit: > > >> I cannot build openssl1.0 any longer. Downgrading all binary > > >> packages from src:dpkg to 1.18.10 makes the build succeed. > > > > Interestingly enough, src:openssl (1.1) works, so… > > > > >So, I think I'll reassign this to openssl1.0, if no other feedback > > > > … this is probably legit. But I would *still* like to raise > > another point. > > Ok, thanks, doing so now. So can someone explain what needs to be fixed in openssl? The order of the CFLAGS needs to be changed? Kurt
