| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
For a long time, when cross-building, say from native=amd64 to
target=powerpc, it was necessary to:
1. cross-build a _powerpc_ package called cross-libtool-base-powerpc,
and then
2. install the powerpc package _natively_ with `pkg_add -m x86_64' to
override the architecture check that normally forbids this kind of
shenanigans,
in order to cross-build anything that uses libtool as a tool.
This is partly because libtool doesn't follow the normal GNU
convention of `./configure --build=<native platform> --host=<platform
package will run on> --target=<platform package is configured to
operate on>' -- in this example, build=amd64, host=amd64,
target=powerpc.
Instead, libtool expects to be cross-built itself, even if it's going
to run as a tool. It's not as bonkers as it sounds at first: libtool
is just a shell script, and it caches various information about the
(cross-building!) toolchain it is built with so it can use that
information later when it is run as a tool itself to cross-compile
other software.
To make this work, we need to create the toolchain wrappers for
libtool _as if_ we were cross-building even if we are building a
native package. So mk/tools uses a new flag TOOLS_USE_CROSS_COMPILE
instead of USE_CROSS_COMPILE, and libtool internally sets
MACHINE_ARCH=${TARGET_ARCH} (in the example above, powerpc) to make
it look like we're cross-building. The new TOOLS_CROSS_DESTDIR is an
alias for the (defaulted) CROSS_DESTDIR, which must now be set
unconditionally in mk.conf in order for libtool to know where the
cross-destdir will be; _CROSS_DESTDIR remains empty when building any
native packages (including the native cross-libtool package).
Finally, we need to make the resulting package be a native package,
with MACHINE_ARCH set to the one that it will be installed on (in the
example above, amd64), so I added an indirection _BUILD_DEFS.${var}
to replace var on its own in the build definitions that get baked
into the package, shown by `pkg_info -B'. Setting
_BUILD_DEFS.MACHINE_ARCH=${NATIVE_MACHINE_ARCH} ensures that this
mutant hybrid cross-built libtool still produces a native package.
All of this logic is gated on setting USE_CROSS_COMPILE in mk.conf or
LIBTOOL_CROSS_COMPILE in the package makefile, so it should be safe
for non-cross-builds -- when USE_CROSS_COMPILE=no and you're not
building cross-libtool, everything is as before.
|
|
|
|
This is needed by packages that require hand-holding in building PIE. Also a
post-build check for MKPIE is performed by default when PKG_DEVELOPER=YES.
|
|
Discovered in pkgtools/pkg, where libpkg/pkg.pc was left unmodified.
|
|
When "bmake clean depends" was called for a package where the various
cookie files already existed, these would enable different rules than a
clean package directory.
Since "bmake clean" deletes all the cookie files before "bmake depends"
starts, in these combined command lines the cookie files must be treated
as absent.
|
|
This is based on the decision The NetBSD Foundation made in 2008 to
do so, which was already applied to src.
This change has been applied to code which is likely not in other
repositories.
ok board@, reviewed by riastradh@
|
|
When not using cwrappers, so far PKGSRC_MKPIE was only automatically
applied when linking using gcc(1) (when enabled). This is now also the
case for packages using ld(1) to link executables.
|
|
This solves an issue with the command sink component of the MKPIE
wrapper for GCC, where the contents of the _MKPIE_CFLAGS.gcc and
_MKPIE_LDFLAGS.gcc variables was guessed. It is now communicated to
cmd-sink-mkpie-gcc through the environment instead.
|
|
- Revisit (and rename) support for FORTIFY as PKGSRC_USE_FORTIFY (instead
of PKGSRC_USE_FORT) for easier support outside NetBSD/gcc;
- PKGSRC_USE_SSP is no longer enabled by default when PKGSRC_USE_FORTIFY
is enabled;
- PKGSRC_MKPIE builds executables as PIE (to leverage userland ASLR)
- PKGSRC_USE_RELRO builds with a read-only GOT to prevent some exploits
from functioning.
Tested on NetBSD/amd64 by myself, in every combination, with and without
pkgtools/cwrappers. MKPIE is not supported at the moment with cwrappers.
Also, MKPIE is known to still break a number of packages when enabled (and
actually supported).
Tested on SunOS by jperkin@, thank you!
As discussed on tech-pkg@, the default behavior is not changed, except
where noted above.
ok bsiegert@
|
|
It turns out a handful of AIX binutil-like utilities are particular
about type of object files they should examine. Instead of piping
through flags for each utility everywhere, it is easier to just export
'OBJECT_MODE=[32|64]' instead.
From Eric N. Vander Weele.
|
|
AIX is particular about the type of object files `ar` should examine.
This should be set explicitly to coincide with the user's defined $ABI.
Contributed by Eric N. Vander Weele.
|
|
Up to now, using subst.mk may have led to file corruption during active
package development. This happened when a sed(1) command had a syntax
error, in which case the whole sed(1) command was terminated, leaving an
empty original file behind.
This commit changes that behavior by applying the sed(1) commands to
the original file and saving the result in a temporary file. Only
after that succeeded is the original file overwritten.
During this rewrite, SUBST_POSTCMD has been removed, since it was
only used in one place (mk/wrapper), and since it relied on the exact
sequence of the internal commands. No package in either main pkgsrc
or pkgsrc-wip uses this variable right now.
|
|
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.
|
|
to the same value anyway. Also removes a comment from 2005 which was
possibly wrong at the time it was committed, given the same construct
has been used in bsd.buildlink3.mk unchanged since 2004.
|
|
|
|
|
|
|
|
|
|
All recent packages featuring Ada code have a hard dependency on the
lang/gnat-aux compiler package. The valid values for USE_LANGUAGES
are c, c99, c++, fortran, fortran77, java, objc, so specifying a
specific compiler was necessary up into now.
One problem with lang/gnat-aux is that it is installed at ${LOCALBASE}
where the lang/gccXX compilers are installed at ${LOCALBASE}/gccXX.
The latter compilers have no possibility of sharing conflicting files
unlike lang/gnat-aux. Rather than fundamentally update the GCC 4.6-based
lang/gnat-aux to avoid these conflicts, a new Ada-capable compiler
based on GCC 4.7 was created with the intent of being supported by
mk/compiler.mk and mk/compiler/gcc.mk.
The Ada packages will be effectively migrated from lang/gnat-aux to the
new lang/gcc-aux compiler, but lang/gcc-aux will remain as a standalone
package as it is the only GCC 4.6-based compiler that builds on
DragonFly and serves it as a world and kernel compile option.
In addition to the current language wrappers, lang/gcc-aux adds
wrappers for "ada" (unique to gcc-aux, hardlinked to gcc driver),
and the gnat, gnatmake, gnatbind, gnatlink, gnatchop, gnatprep,
and gnatls programs. Supporting all of these allows the wrapper
system to be used with Ada packages; currently wrappers are mostly
disabled on them.
The lang/gcc47 implicitly adds support for the "objc-c++" language by
adding it to the USE_LANGUAGES list, but it wasn't really supported.
An attempt was made to better support objc-c++, but this new enumeration
probably still needs work or needs to be removed completely.
Logic for Ada support:
1) All lang/gccXX compilers have version numbers ranging from 2.8.1 to 9.
2) lang/gcc-aux uses the release date as its version number in the form of
YYYYMMDD with a minimum value of 20120614, so there is no version
overlap.
3) When at least one element of USE_LANGUAGES is "ada", the value of
20120614 is added to the set of GCC_REQD which selects lang/gcc-aux.
4) The _NEED_NEWER_GCC check is disabled. It fails and isn't relevant;
unless a package sets GCC_REQD over 20120614, the only way to select
lang/gcc-aux is to specify the Ada language and only one compiler
known to gcc.mk can support it.
|
|
|
|
Workaround for missing hard link support on Haiku, PR#43398.
|
|
a whitespace in the command search path.
|
|
is disabled. In that case, the post processing is doing nothing anyway.
|
|
|
|
- provide cpp wrapper using cc -E
- provide c++_r wrapper working like c++
- provide -rpath handling for cc
- fix some debug messages to provide the correct script name
|
|
|
|
- Add cc_r/xlc_r wrapper using the same rules as xlc itself.
It is used for example by Perl.
- Improve the RPATH emulation:
- Always set -blibpath, use /usr/lib:/lib as default
- If -blibpath is exlicitly given, add to the default
- Additionally append any -Wl,-rpath given.
|
|
The PKG_FAIL_REASON isn't executed by default, no idea why, but this
makes it a bit cleaner why the compiler wrapper will fail and fixes the
more important AIX case.
|
|
former are already more specific.
|
|
|
|
and then call it as a shell function. Note that the shell function is
not called "cache", since some shells have problems when a function has
the same name as a variable.
This speeds up the wrapper by as little as 75 percent for the final link
command of editors/abiword on SunOS-5.10-sparc (before: 20 seconds,
after: 5 seconds).
|
|
|
|
should be both faster and easier to read.
|
|
wrapper for gcc and cc as type "CPP", although these aren't C
preprocessors. By preventing the code from overwriting files, this works
now.
|
|
- USE_CROSS_COMPILATION activates it, CROSS_DESTDIR specifies root of
the target filesystem
- derive _CROSS_DESTDIR from CROSS_DESTDIR or MAKEOBJDIR
- buildlink3.mk prefixes the files to symlink with _CROSS_DESTDIR
- compiler/gcc.mk knows about the target prefix (e.g. i386--netbsdelf)
- PKG_DBDIR is prefixed with _CROSS_DESTDIR
- package-install and bin-install are not called with su
- install and strip are redirected to the tool version
- links for the target specific ar, as, ld, nm, objdump, ranlib and
strip are added
- compiler wrapper detect if linking is requested or not
- special command sinks for CPP and CC/CXX add the cross-compile magic:
- modify include dirs to get the target /usr/include
- modify linker dirs and runpath to use target /usr/lib at link time,
but keep correct rpath entries
Supported-by: Google SoC 2007
Basic tests by he@ on Sparc. Review from jlam@.
|
|
Apparently, the tools directory isn't in the PATH at the point where
this code is executed.
Fixes PR 35487.
|
|
space.
|
|
|
|
|
|
Fixes PR 31444. Fixes PR 31447. Both problems reported by Rumi Szabolcs.
|
|
wrapper_abi variable. This is used in the MIPSpro wrapper to reject any
package that tries to compile a file for the wrong ABI. This is not just
a warning because such a package most likely has more severe problems.
The gcc -Wall option seems to be similar to the MIPSpro -fullwarn
option, so map them.
|
|
|
|
transformations can decide whether they happen in a C or a C++ compiler.
Now the wrappers don't depend on the basename of the executed compiler
wrapper anymore.
Fixes PR 35555.
|
|
-Wall to different arguments.
|
|
|
|
the code a lot more readable.
|
|
generic one. That way, the unknown options are reported properly on all
platforms.
|
|
|
|
make the wrapper code less frightening. For example, instead of
arg="${arg#-Wl,}"
$debug_log $wrapperlog " (transform-sunpro-cc) to: $arg"
addtocache=yes
one can simply write
transform_to "${arg-Wl,}"
The functions that are currently implemented are: transform_to,
transform_discard, transform_to_nocache, transform_discard,
transform_pass and transform_pass_unknown.
|
|
|
