Previously there were at least 5 different ways MACHINE_ARCH could be set,
some statically and some at run time, and in many cases these settings
differed, leading to issues at pkg_add time where there was conflict
between the setting encoded into the package and that used by pkg_install.
Instead, move to a single source of truth where the correct value based on
the host and the chosen (or default) ABI is determined in the bootstrap
script. The value can still be overridden in mk.conf if necessary, e.g.
for cross-compiling.
ABI is now set by default and if unset a default is calculated based on
MACHINE_ARCH. This fixes some OS, e.g. Linux, where the wrong default was
previously chosen.
As a result of the refactoring there is no need for LOWER_ARCH, with
references to it replaced by MACHINE_ARCH. SPARC_TARGET_ARCH is also
removed.
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.
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.
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.
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.
The problem was already reported to the upstream but it caught
seemingly no attention:
http://gcc.gnu.org/ml/gcc-help/2010-07/msg00164.html
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.
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.
This compiler requires binutils 2.17 which A) doesn't build on DragonFly
and B) is a significant downgrade over the system binutils. DragonFly
users should look at lang/gnat-aux for a pkgsrc compiler which is based
on gcc 4.6. lang/gcc46 doesn't build on DragonFly either, but it may be
worth fixing that package. This one isn't worth the effort for us.
This is the list of problem reports (PRs) from GCC's bug tracking
system that are known to be fixed in the 4.5.3 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.5.3
On the PowerPC compiler, the altivec builtin functions vec_ld and
vec_st have been modified to generate the Altivec memory instructions
LVX and STVX, even if the -mvsx option is used. In the initial GCC
4.5 release, these builtin functions were changed to generate VSX
memory reference instructions instead of Altivec memory instructions,
but there are differences between the two instructions. If the VSX
instruction set is available, you can now use the new builtin
functions vec_vsx_ld and vec_vsx_st which always generates the VSX
memory instructions.
Packaged by Marko Schütz, improved by Kai-Uwe Eckhardt.
This is the gcc 4.5 compiler suite.
This package has a test target. For testing (only), this
package requires devel/dejagnu and devel/autogen.
