Jonathan Perkin
2014-07-21 13:45:23 UTC
I've been looking at fixing gcc48 on SunOS, and believe that there are
a number of issues with the way it has been reworked since gcc47:
- We now need to perform a full build for the -libs package. On fast
hardware with MAKE_JOBS=8 this takes around 45 minutes. I prefer
the old method of simply taking the libraries from a successful gcc
build and repackaging them. It seems wasteful doing two full GCC
builds only to throw things away at the end.
- There has been an attempt to move to static PLISTs. Due to the
vast number of platform differences this is going to result in a
huge amount of .if .endif sections. For example on SunOS both
32-bit and 64-bit objects are built, so the entire do-install
section of gcc48-libs needs to be duplicated. Not only that but
the layout differs depending on the MACHINE_ARCH of the build host.
Again, I prefer the old method of simply generating dynamic PLISTs.
- My main concern is the huge number of completely undocumented
patches which are currently applied (75!). Some of them are
clearly toxic, such as the default setting of -fstack-protector.
Given the critical nature of this package, especially with
USE_PKGSRC_GCC, I would rather we limit the patching of it to an
absolute minimum, and ensure that any patches we do apply are very
clearly documented.
- gcc48-libs/buildlink.mk cannot have been tested, as it is still
using the library directory from gcc47-libs which is no longer
valid since the reworking of how the libraries are packaged.
- the full binutils dependency is now on the -libs package, which
doesn't really make sense, and pulls it in unnecessarily for binary
packages.
I started to produce a patch-set for it but I feel it is going to be
far too much effort, and I think it would be better spent integrating
cleaner gcc49 packages using the gcc47 layout, hence this email to
start discussion on that.
Thanks,
a number of issues with the way it has been reworked since gcc47:
- We now need to perform a full build for the -libs package. On fast
hardware with MAKE_JOBS=8 this takes around 45 minutes. I prefer
the old method of simply taking the libraries from a successful gcc
build and repackaging them. It seems wasteful doing two full GCC
builds only to throw things away at the end.
- There has been an attempt to move to static PLISTs. Due to the
vast number of platform differences this is going to result in a
huge amount of .if .endif sections. For example on SunOS both
32-bit and 64-bit objects are built, so the entire do-install
section of gcc48-libs needs to be duplicated. Not only that but
the layout differs depending on the MACHINE_ARCH of the build host.
Again, I prefer the old method of simply generating dynamic PLISTs.
- My main concern is the huge number of completely undocumented
patches which are currently applied (75!). Some of them are
clearly toxic, such as the default setting of -fstack-protector.
Given the critical nature of this package, especially with
USE_PKGSRC_GCC, I would rather we limit the patching of it to an
absolute minimum, and ensure that any patches we do apply are very
clearly documented.
- gcc48-libs/buildlink.mk cannot have been tested, as it is still
using the library directory from gcc47-libs which is no longer
valid since the reworking of how the libraries are packaged.
- the full binutils dependency is now on the -libs package, which
doesn't really make sense, and pulls it in unnecessarily for binary
packages.
I started to produce a patch-set for it but I feel it is going to be
far too much effort, and I think it would be better spent integrating
cleaner gcc49 packages using the gcc47 layout, hence this email to
start discussion on that.
Thanks,
--
Jonathan Perkin - Joyent, Inc. - www.joyent.com
Jonathan Perkin - Joyent, Inc. - www.joyent.com