On Mon, 2016-01-04 at 20:36 -0800, Mark Millard wrote: > I had in Bug 205904 reported that trying "portmaster -DK > textproc/expat2" in a -march=armv7-a -mcpu=cortex-a7 context (on an > rpi2b) gets (for -r293129 and its /usr/bin/ tools): > > > unresolvable R_ARM_MOVW_ABS_NC relocation against symbol > > `malloc@@FBSD_1.0' > > in an attempted link operation. > > I've now added a comment saying in part: > > > Investigating the issue I had the portmaster activity use the > > /usr/local/arm-gnueabi-freebsd/bin/ tools instead (via > > /etc/make.conf changes) and in that context the message is > > different but it was still an error: > > > > > relocation R_ARM_MOVW_ABS_NC against `malloc' can not be used > > > when making a shared object; recompile with -fPIC > > > > > > Trying again with -fPIC does let the portmaster command complete in > > this /usr/local/arm-gnueabi-freebsd/bin/ based tool context. > > > > > > Going back and trying -fPIC in the /usr/bin/ based tools context > > also lets the portmaster command complete. (That context without > > -fPIC did not directly indicate to try -fPIC in its messages.) > > > > > > So maybe part of the issue is having compiler arguments like -fPIC > > show up in commands for contexts like -march=armv7-a -mcpu=cortex > > -a7 without manual intervention in each case. For ports: some parts > > of a more complicated port might need[] such and other parts might > > not. > > I used /etc/make.conf to force -fPIC being present. > > I started this investigation to try some things after Ian Lepore's > -r292964 for the /usr/bin/ binutils. I picked on textproc/expat2 > initially as something fairly simple and limited to C. (clang++ has > problems under SCTLR bit[1]==1 [alignment required] on arm that make > clang++ Bus Error during most C++ compiles). > > === > Mark Millard > markmi at dsl-only.net
All of this is a complex way of saying "there is a bug in the expat2 port" (that being that it tries to build a shared library from object files that were compiled without -fpic). Adding -fpic via make.conf is absolutely not a fix or even a marginally viable workaround. -- Ian _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"