been broken due to NATIVE_MACHINE_ARCH no longer being set to x86_64. Fix
this by introducing HOST_MACHINE_ARCH which refers to the underlying host
architecture rather than bmake's native architecture, thus differentiating
between cross-compiling and multilib.
This is currently only set on Linux as the only OPSYS which currently
requires such a test, but can be expanded to other OPSYS as necessary.
- No _GCC_* anything in mk/bsd.prefs.mk;
- No compiler flags in platform files.
Tested again on NetBSD/amd64, with and without cwrappers, with the same
outcome.
With feedback from jperkin@
- 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.
of software such as Ruby to build on Tiger/PowerPC.
Tested with & without on a G4 with Tiger & Leopard.
It was not needed on Leopard as the linker defaults to a target of 10.5 &
setting it back broke the bootstrap process.
Reviewed by wiz@ long ago.
TOOLS_PATH.readelf is set. This is a PKG_DEVELOPER feature and it's
likely the developer is smart enough to either have it already available
in $PATH or be able to install it (e.g. via devel/binutils) if required.
directory hierarchy to be created but not removed. This is triggered by
the GNU getcwd-path-max.m4 configure test used in lots of GNU software,
and causes the builds to fail in pbulk as 'make clean' cannot complete.
For now we provide a cached result for the test to avoid running it,
using a 'no' value as the test is for a specific glibc bug.
This bug has been brought to Apple's attention by the NixOS developers,
raised as https://openradar.appspot.com/radar?id=6160634819379200. For
now we mark only 10.11.0 (15.0.0) as having the bug - it remains to be
seen whether Apple will fix it in the upcoming .1 release.
the SDK path if we need to.
This avoids issues on Yosemite and Xcode 7, which drops support for the 10.10
SDK. Trying to determine the SDK path fails, but the failure is not cached in
the xcrun database, so each call to a compiler tool is unecessarily delayed (by
around 3 seconds on my build hosts).
For users still on Yosemite who have upgraded to Xcode 7, the solution is to
install the Command Line Tools so that /usr/include is populated and used.
without arguments, strip(1) will attempt to strip all symbols by default,
and when it is unable to do this will fail with a non-zero exit status.
Passing '-u -r' to strip(1) would in theory resolve the issue, but there
is no simple of way of doing this due to the way strip is called by the
native install program through XCode. We would need to build a patched
bsdinstall for Darwin, so for now we just disable stripping on install,
as many packages have had to do individually up until now.
This works in a similar way to the ELF checks, but uses otool(1) to list the
library name and its dependencies, and the checks fail if there are WRKDIR
references or if the -install_name of the library does not match $PREFIX, as
well as ensuring that any libraries from pkgsrc are correctly registered as
full dependencies.
Removes support for the user to set USE_CHECK_SHLIBS_ELF, but there were no
reasonable reasons for doing so in the past anyway, and it may be masking
issues in platform files we should fix.
This is pretty much the same change as with SSP, and completes it with
support for fortify (like USE_FORT in NetBSD's base system). Like SSP, this
is disabled by default for the moment. Like in NetBSD's base system,
enabling fortify explicitly also enables SSP by default - but SSP can still
be disabled explicitly in this situation.
All four combinations tested on NetBSD/amd64.
With this change, the check if the current architecture is supported is
only performed if SSP is enabled in the first place. This should not
change the current behavior; tested on NetBSD/amd64.
Suggested by wiz@
This is enabled with PKGSRC_USE_SSP in mk.conf(5), as documented there.
Most NetBSD platforms are supported (when compiling with gcc).
After consensus on tech-pkg@.
Initial patchset to add support by rodent@
Further adjustments made based on feedback by joerg@
Tested by myself with numerous bulkbuilds thanks to Patrick Wildt @ Bitrig
Reviewed by bsiegert@ joerg@ wiz@
package creation.
There are very few things in pkgsrc that needs more than one hour per
process on decently fast hardware, so setting that as (soft) limit for
bulk builds avoids the infinite loops seen in some other packages. There
are a few select exceptions, i.e. flightgear-data needs more than one
hour for pkg_create when using xz. This flag allows selectively giving
those places more time without wasting resources in the broken cases.
rather than trying to consolidate into a single fnmatch. There aren't that
many of them, and it will aid the integration of cwrappers which doesn't
support globs.
Base xsrc on netbsd-5 has not really worked with pkgsrc for a while,
because various programs need newer versions of various X pieces. The
2014Q2 official bulk builds are missing about 1500 packages as a
result of this. Therefore, switch to modular on netbsd-5 (as netbsd-4
has been for a very long time), which should result in more useful
binary packages for netbsd-5 for 2014Q3.
(There is a notion of updating netbsd-5 base xsrc to more modern xorg.
If that happens, and there's a 5.x formal release, and builds show
that pkgsrc with native succeeds on it, this can perhaps be flipped
back. Odds are that's not going to happen, and it's overwhelmingly
unlikely to happen soon.)
Anyone who prefers to stay with native can set X11_TYPE=native in
mk.conf.
Note that this is about pkgsrc and specifically the default
dependencies for pkgsrc programs that use X11, so the native servers
are unaffected and can be run from /usr/X11R7, the same as they are
now, without any changes being necessary. (This message is in fact
being typed on a system with a native server, native xterm and modular
libs for pkgsrc.)
Discussed on tech-pkg, tech-x11 multiple times over the last 6 months
or so, and specifically encouraged by wiz@.
a blanket removal of any long options, richard@ is concerned this may affect
packages which use the long options now available in newer SunOS ld.
Whilst here, transform --rpath to -R, used by a few packages.
