Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Feb 2021 15:05:06 +0000
From:      bugzilla-noreply@freebsd.org
To:        ports-bugs@FreeBSD.org
Subject:   [Bug 253275] [exp-run] base system PIE default
Message-ID:  <bug-253275-7788-qgXBo4lyoY@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-253275-7788@https.bugs.freebsd.org/bugzilla/>
References:  <bug-253275-7788@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253275

--- Comment #16 from Ed Maste <emaste@freebsd.org> ---
(In reply to Dawid Gorecki from comment #14)
> Some ports build static libraries and it seems that currently the best wa=
y to
> fix this is by setting WITHOUT_PIE.

Yes. This affects two classes of ports:

1. those that build their own static libraries using the base system Mk
infrastructure, such as devel/libphk

Example error:

ld: error: can't create dynamic relocation R_X86_64_32 against local symbol=
 in
readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext'=
 to
allow text relocations in the output
>>> defined in ../../libphk.a(phk_argv.o)
>>> referenced by phk_argv.c
>>>               phk_argv.o:(PhkArgvParse) in archive ../../libphk.a

A patch for this one is now open in D28790 https://reviews.freebsd.org/D287=
90

2. those that link against static libraries provided by the base system, su=
ch
as net/freevrrpd

ld: error: can't create dynamic relocation R_X86_64_32 against local symbol=
 in
readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext'=
 to
allow text relocations in the output
>>> defined in /usr/lib/libnetgraph.a(sock.o)
>>> referenced by sock.c:78 (/poudriere/data/src-PR253275/lib/libnetgraph/s=
ock.c:78)
>>>               sock.o:(NgMkSockNode) in archive /usr/lib/libnetgraph.a

For this one, PIE disabled in the port's Makefile in r566067.

> Another reason that I've seen is caused by setting CFLAGS=3D"${CFLAGS}" in
> MAKE_ARGS. I'm not really sure how bmake works in this case, but I think =
that
> it starts ignoring any further processing of CFLAGS and we are left with
> CFLAGS from sys.mk and no modifications made in bsd.prog.mk are taken into
> account. This happens for www/mathopd. I removed MAKE_ARGS for that and it
> built fine. -DFREEBSD_SENDFILE was also properly passed further. I haven't
> tested if it works after building though, but I don't see any reason why =
it
> shouldn't.

Right - port Makefiles are processed w/o using bsd.opts.mk, and so in that
context CFLAGS does not contain -fPIE. Then the submake for the software it=
self
is invoked as make CLFAGS=3D<whatever> ... (as a result of MAKE_ARGS) and t=
hat
overrides bsd.prog.mk's attempt to add -fPIE.

I tried building www/mathopd with and without MAKE_ARGS set, and without it
there are a number of additional CFLAGS set, in addition to -fPIE:

-MD  -MF.depend.base64.o -MTbase64.o -std=3Dgnu99 -Wno-format-zero-length
-nobuiltininc -idirafter /usr/lib/clang/11.0.1/include -fstack-protector-st=
rong
   -Qunused-arguments

so it would definitely need testing.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-253275-7788-qgXBo4lyoY>