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.
