Paul Grevers wrote:
> I am not 100% sure how this works, but by enabling the commented out
> code in debian/rules about -fPIE and -fPIC again (line 21/22), the
> builds completes successfully. I found [1] when I searched for
> "relocation against dynamic symbol", that is why I looked in that direction.
>
> The other remarked that made me think this is the solution is a comment
> in /usr/include/hardening-wrapper/hardening.make [2]:
> "
> In cases where mixed shared objects and executable objects are being
> built, "-fPIC" needs to actually replace "-fPIE", since gcc won't
> distinguish between them yet.
> "
> Although that doesn't explain why on other arches it does work.
>
> Paul
>
> [1] http://www.cmake.org/Wiki/CMake_IA64_FPIC_problem
> [2]
> http://anonscm.debian.org/loggerhead/hardening/master/annotate/head:/hardening-wrapper/hardening.make
Hi,
I was responsible for adding that commented out "-fPIE conflicts with -fPIC"
message in grass's debian/rules, I left it in there to make backports to
Wheezy easier. Glad to learn it helps for ia64 on sid too!
I'm better at shell scripts than at Makefiles, but should the code in
debian/rules
roughly look this this? (I guess all munged onto one continued\ line)
{{{
include /usr/share/hardening-includes/hardening.make
CFLAGS=$(shell dpkg-buildflags --get CFLAGS)
LDFLAGS=$(shell dpkg-buildflags --get LDFLAGS)
# in Wheezy (and Jessie ia64) -fPIE conflicts with -fPIC. See example in
# the hardening.make file.
if [ `uname -m` = "ia64" ] ; then
CFLAGS += $(HARDENING_CFLAGS_PIC) \
$(filter-out $(HARDENING_DISABLE_PIE_CFLAGS_FILTER),$(HARDENING_CFLAGS))
else
# in Jessie & Sid the problem seems fixed so we can proceed normally.
CFLAGS+=$(HARDENING_CFLAGS)
LDFLAGS+=$(HARDENING_LDFLAGS)
fi
}}}
or is there a better way to do arch-specific lines with the aid of debhelper?
for a longer term fix, should we forward this bug to the ia64 arch Debian
people?
fwiw, on the GRASS dev mailing list, Markus Neteler wrote:
[ http://article.gmane.org/gmane.comp.gis.grass.devel/55499 ]
[...].
>
> In an old thread here there is a suggestion:
> http://software.intel.com/en-us/forums/topic/267748
> "On Itanium-based systems running Linux, when the -shared switch is
> used to create a Dynamic Shared Object (.so), there may be some
> relocation against dynamic symbol" messages generated during the ld
> phase
> ...
>
> To fix this problem, add the switches -i_dynamic and -nofor_main to
> the command line.
> "
>
> see also
> http://www.opendx.org/cgi-bin/forum/YaBB.pl?num=1139610671/1
>
> A Debian geek may know...
>
> Markus
---------------------------------------
[offtopic, re. #672719]
Paul Gevers wrote:
> Hmm, were did you get the impression that ppc64 and s390x actually did
> build? They seem to be still failing as far as I can tell, but not
> blocking anything as grass has never been build successfully on those archs.
oh, my mistake then; just that they weren't showing up as blocking in the
PTS QA page.
> Do you want me to test this on a porterbox?
yes please :)
> Could you point me to your patch-from-trunk patch that you wanted to apply
> to fix the ppc64 and s390x FTBFS?
I think they'll need these patches as described in #672719 to work again:
https://trac.osgeo.org/grass/changeset/57855
https://trac.osgeo.org/grass/changeset/57856
thanks,
Hamish
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
