Match cwrappers' expectations and place an argument per line in the
configuration. Tokenize the arguments when writing the configuration
instead of inside cwrappers.
This should fix PKGSRC_MKPIE.
This is based on a patch submitted on 16/04/2017 on tech-pkg@ and
adapted by joerg@ for pkgtools/cwrappers. It only consists in the
missing part to actually generate PIE executables with cwrappers if
configured to do so (currently disabled by default). The aim is really
to produce safer binaries where ASLR is in use.
This part in pkgsrc is only supported on NetBSD (x86) with GCC at the
moment.
Tested on NetBSD/amd64, with and without cwrappers, with and without
PKGSRC_MKPIE (all four combinations).
wrapped version by full path. This fixes some cases where the wrappers
have been bypassed. lang/lua52 triggered the investigation as it failed
to link against libreadline, which should have been translated to
libedit. Tested by jperkin and myself with full bulk builds.
wrappers when USE_CWRAPPERS is enabled, saving a reasonable amount of
I/O during builds, mostly due to avoiding the transform/untransform sed
file generations.
WRAPPER_DIR and WRAPPER_BINDIR are used by various packages to override
or point to specific wrappers, and these now point to the cwrappers
directory when enabled, removing the need for CWRAPPERS_BIN_DIR
duplication and fixing packages which previously were using legacy
wrappers by accident.
A number of targets are now duplicated between bsd.wrapper.mk and
cwrappers.mk, the intention being that the legacy wrappers will be
deprecated once cwrappers is verified on all supported platforms. If
that turns out to take longer than expected, we will probably want to
introduce a wrapper.mk to abstract them away before loading the
appropriate back-end.
directories of the compiler/linker when using cwrappers. Command line
flags will often put them before the corresponding flags for
PREFIX/include and PREFIX/lib, so the version from outside .buildlink
would be prefered. The other way around is much less likely to be a
problem and normally the expected case. Bump required cwrappers version
for the necessary exact-match feature.
Motivation: with "USE_CWRAPPERS=yes" on the default case-insensitive
OS X filesystem, linking the wrappers was failing, stopping the
build. For example:
===> Creating toolchain wrappers for mess822-0.58nb3
ln: .../pkgsrc-current/mail/mess822/work/.cwrapper/bin/cc: File exists
*** Error code 1
Stop.
I never noticed this with the old wrappers, but they've also been
failing to link "CC" as an alias to "c++"; it's just that the failure
has been silent and I've never noticed a build failure for lack of
a "CC" wrapper, despite there probably never having been such a
wrapper.
Given that jperkin's SmartOS bulk build with this change produced
results similar to last week's non-cwrappers trunk build, we can
conclude that across platforms, the need for a "CC" wrapper is very
limited and we needn't try (and sometimes fail) to create one by
default.
