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.
noticed by diger in pkgsrc-users@.
While here, enable useradd only for the case groupadd exists,
because former useradd is interactive command, not usable with pkgsrc framework.
