On Thu, Feb 05, 2015 at 01:04:58AM +0000, Viktor Dukhovni wrote:
> On Wed, Feb 04, 2015 at 01:12:16PM -0500, Wietse Venema wrote:
>
> > Very lighty-tested patch follows. No INSTALL documentation until
> > this has been tested.
> >
> > Usage: $ make makefiles pie=yes ...
>
> Works on NETBSD6, with:
>
> pie=yes shared=yes dynamicmaps=yes
> pie=yes shared=no dynamicmaps=no
>
> I also tested with a variant patch which uses "-fPIE" rather than
> "-fPIC" to compile the object files when shared=no, because these
> all end up in executables, rather than shared libraries. Rumour
> has it that's the "more correct" thing to do in that case. This
> also worked on NETBSD6. Slightly modified patch below (note the
> " $CCARGS " to also match leading or trailing -fPI[CE])
MacOS/X (Mavericks) testing reveals that with Apple's llvm/clang,
"shared=yes" yields "PIE" executables by default with no "-pie"
option required.
$ otool -hv bin/postconf
bin/postconf:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL LIB64 EXECUTE 21 2120 DYLDLINK
PIE
In fact attempts to use an explicit "-pie" option yield warnings:
clang: warning: argument unused during compilation: '-pie'
this warning is fatal if one includes "-Werror" in CCARGS.
It is possible, but redundant to include "-Wl,-pie" when building
with shared=yes or when objects are compiled with "-fPIE", as in
both cases the generated executable is automatically "PIE".
Even with "shared=no" and "pie=no" I still get PIE executables.
So we should perhaps just ignore the "pie" option with MacOS/X.
Have not tried Yosetime yet...
--
Viktor.
