On Thu, Jan 31, 2019 at 06:44:13PM +0100, Uwe Kleine-König wrote: > On 1/31/19 3:26 PM, Luc Van Oostenryck wrote: > > > > Does 'uname -m' or 'uname -s' returns 'gnu' on Hurd? > > ukleinek@exodar:~$ uname -s > GNU > ukleinek@exodar:~$ uname -m > i686-AT386 OK, thanks. > >> and on x32 I got: > >> > >> /usr/bin/ld: compile-i386.o: relocation R_X86_64_32S against `.data' can not be used when making a PIE object; recompile with -fPIC > >> /usr/bin/ld: final link failed: nonrepresentable section on output > >> collect2: error: ld returned 1 exit status > > > > I didn't had this when testing on x32 but I see that here the compiler > > is called here with: > > -specs=/usr/share/dpkg/pie-link.specs > > -Wl,-z,relro -Wl,-z,now > > The first one is clearly part of the problem, maybe in combination > > with the other two. > > From where do they come? Why? It's not used for amd64 and other archs. > > The linker flags come in from the automatic hardening that is suggested > to use for Debian packages. In the amd64 buildlog I see: > > ... > gcc-8 -Wl,-z,relro -Wl,-z,now -Wl,--as-needed compile.o libsparse.a > compile-i386.o -o compile > ... > > not sure where the -specs=... part comes from. compile-i386 I think the cause may be that if PIE is wanted (via the -specs=...) then -fPIC is also needed at compile time. So, I guess that the -specs is given via LDFLAGS but not CFLAGS. ... (Googling a bit more) It seems it was a known problem but it was fixed in 2016 (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843714 ). Is it possible that the x32 port use an old version of dpkg? -- Luc
