Re: mixed up LDFLAGS on amd64 buildds?

Kurt Roeckx <[email protected]>
Newsgroups gmane.linux.debian.ports.amd64
Message-ID <[email protected]>
On Fri, Jun 01, 2012 at 04:19:30PM +0700, Daniel Glassey wrote:
> Hi,
> My package grcompiler version 4.2~pre5 is failing to build on the
> amd64 buildd brahms and now barber as well.
> 
> The log is for 4.2~pre5-2 on brahms is at:
> https://buildd.debian.org/status/fetch.php?pkg=grcompiler&arch=amd64&ver=4.2~pre5-1&stamp=1338365349
> 
> The log is for 4.2~pre5-2 on barber at:
> https://buildd.debian.org/status/fetch.php?pkg=grcompiler&arch=amd64&ver=4.2~pre5-2&stamp=1338528478
> 
> In 4.2~pre5-2 debhelper 9 is being used so it is supposed to be
> getting the hardening flags
> 
> gcc -DPACKAGE_NAME=\"grcompiler\" -DPACKAGE_TARNAME=\"grcompiler\"
> -DPACKAGE_VERSION=\"4.2\~pre5\" -DPACKAGE_STRING=\"grcompiler\
> 4.2\~pre5\" -DPACKAGE_BUGREPORT=\"[email protected]\"
> -DPACKAGE_URL=\"\" -DPACKAGE=\"grcompiler\" -DVERSION=\"4.2\~pre5\"
> -DHAVE_ICONV=1 -DICONV_CONST= -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
> -DHAVE_DECL_PROGRAM_INVOCATION_SHORT_NAME=1 -I.   -D_FORTIFY_SOURCE=2
> -Dunix -DGDLPP -DPKGDATADIR=\"/usr/share/grcompiler\" -g -O2
> -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security
> -Werror=format-security -DNDEBUG -c -o gdlpp-usecpp.o `test -f
> 'usecpp.c' || echo './'`usecpp.c
> 
> gcc -Dunix -DGDLPP -DPKGDATADIR=\"/usr/share/grcompiler\" -g -O2
> -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security
> -Werror=format-security -DNDEBUG  -Wl,-z,relro -o gdlpp gdlpp-cpp1.o
> gdlpp-cpp2.o gdlpp-cpp3.o gdlpp-cpp4.o gdlpp-cpp5.o gdlpp-cpp6.o
> gdlpp-memory.o gdlpp-usecpp.o  -fPIE -pie -Wl,-z,relro -Wl,-z,now
> -ldl -lm   -L/usr/lib/x86_64-linux-gnu -licui18n -licuuc -licudata
> -ldl -lm
> 
> /usr/bin/ld: gdlpp-cpp1.o: relocation R_X86_64_32 against
> `.rodata.str1.1' can not be used when making a shared object;
> recompile with -fPIC

gdlpp-usecpp.o clearly wasn't build using -fPIE, which should
also be in the CFLAGS (if you wanted to have PIE enabled)

dpkg-buildflags shows this when enabling pie:
CFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
FFLAGS=-g -O2
LDFLAGS=-fPIE -pie -Wl,-z,relro

> It looks from here like LDFLAGS is being set to -fPIE -pie
> -Wl,-z,relro -Wl,-z,now on the build machine unconditionally and isn't
> coming from dpkg-buildflags. I can't replicate that on a porterbox.

We do not set anything special on the buildds.  We clearly don't
default to enabling pie.  But it looks like it's CFLAGS / LDFLAGS
from a invokation of dpkg-buildflags with different
DEB_BUILD_MAINT_OPTIONS

The only thing we might set up in DEB_BUILD_MAINT_OPTIONS is a
parallel option.


Kurt
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.