The find-prefix infrastructure was required in a pkgviews world where
packages installed from pkgsrc could have different installation
prefixes, and this was a way for a dependency prefix to be determined.
Now that pkgviews has been removed there is no longer any need for the
overhead of this infrastructure. Instead we use BUILDLINK_PREFIX.pkg
for dependencies pulled in via buildlink, or LOCALBASE/PREFIX where the
dependency is coming from pkgsrc.
Provides a reasonable performance win due to the reduction of `pkg_info
-qp` calls, some of which were redundant anyway as they were duplicating
the same information provided by BUILDLINK_PREFIX.pkg.
The ${PREFIX}/include/ansidecl.h installed by devel/binutils is not
necessarily compatible (E.g. binutils-2.25 does not define PARAMS). Adjust
the include path priority so the internal ansidecl.h gets precedence, allowing
cp-demangle.c to use libiberty.h without compilation errors.
each GCC version. Using the variable causes impossible version constraints
when a specific GCC is depended upon but the user is using something newer,
as _GCC_REQD will be set to the higher value.
illumos releases and appears to cause issues there, seen most clearly in
qt3 uic segfaults.
Bump PKGREVISION of both gcc47 and gcc47-libs, gcc47-libs by more than one
as it has lagged behind and must be kept ahead of gcc47.
Do it for all packages that
* mention perl, or
* have a directory name starting with p5-*, or
* depend on a package starting with p5-
like last time, for 5.18, where this didn't lead to complaints.
Let me know if you have any this time.
Makefile:
See ${WRKSRC}/libgcc/config/t-slibgcc-darwin: It uses strip(1) to
create a stub library, not just to remove symbols, so we must not
let strip(1) be a no-op regardless of ${INSTALL_UNSTRIPPED} or the
build fails for missing files.
patches/patch-libgcc_config_t-slibgcc-darwin:
If we don't install libgcc_s.10.[45].dylib, our gcc links binaries
with *both* /usr/lib/libgcc_s.1.dylib and
${GCC_PREFIX}/lib/libgcc_s.1.dylib, which is certainly a bad thing.
patches/patch-libjava_Makefile.in:
Tell libtool the fact that libjvm.so is a module to be opened with
dlopen(3). This is actually needed on Mach-O systems like Darwin.
a) refer 'perl' in their Makefile, or
b) have a directory name of p5-*, or
c) have any dependency on any p5-* package
Like last time, where this caused no complaints.
preference to target_noncanonical so that the user can override if
required, e.g. in a multilib environment where target_noncanonical will
change based on current ABI.
Additionally, ensure that it comes first in the RPATH so that when
using USE_PKGSRC_GCC_RUNTIME with in-pkgsrc gcc we pick up the correct
libraries.
GCC 4.7.2 is the first bug-fix release containing important fixes
for regressions and serious bugs in GCC 4.7.1 with over 70 bugs
fixed since the previous release.
A notable change in GCC 4.7.2 compared to 4.7.1 are ABI bug fixes
related to some C++11 templates (std::list and std::pair). As a result,
code using those templates in C++11 mode is again ABI compatible with
code in C++03/C++98 mode or C++11 mode of GCC 4.6 and earlier, but might
be ABI incompatible with code compiled by GCC 4.7.1 or 4.7.0 in C++11
mode. See http://gcc.gnu.org/gcc-4.7/changes.html for more details.
This is the list of problem reports (PRs) from GCC's bug tracking system
that are known to be fixed in this release. This list might not be complete
(that is, it is possible that some PRs that have been fixed are not listed
here).
http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.7.2
Like i386-FreeBSD, the i386-DragonFly floating point unit uses a 53-bit
mantissa. GCC uses the TARGET_96_ROUND_53_LONG_DOUBLE macro to know
which platforms behave this way.
Unfortunately, setting this macro to 1 breaks precision on Ada, and
leaving it at 0 breaks precision on c/c++ long double handling. However
lang/gcc47 likely will never support Ada, so we'll favor c/c++. This
is only an issue for i386; the setting on x86_64 should be zero as it
uses 64-bit precision.
GCC47 was marked NOT-FOR-DRAGONFLY, so support has been added.
* DragonFly-specific files added via patch mechanism
* Some existing patches modified to add DragonFly configuration items
* dl_iterate_phdr error handling support added (FreeBSD support was altered,
NetBSD and OpenBSD support is commented out)
* The java language is taken off as a default option
On the i386 platform, the compiler will build from a full bootstrap, but
one of the later stages fails on x86_64. It fails to find libstdc++.so.6
even though the previous stage library was built and -B, -L flags point
to it. The cause of the platform-specific build failure isn't clear --
The workaround is to disable the bootstrap on DragonFly so that the compiler
is built in one stage instead of three. This workaround could have been
limited to the x86_64-DragonFly platform only, but currently is applied to
i386-DragonFly too.
