[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: mixed up LDFLAGS on amd64 buildds?



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=\"silgraphite-devel@lists.sourceforge.net\"
> -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


Reply to: