mixed up LDFLAGS on amd64 buildds?
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
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.
The package built fine at an earlier version on May 20th with no
changes to that area since then..
I can see similar build fails in the log of flush. Is this intended?
TIA,
Daniel
Reply to: