tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Issues with gcc48, plans for gcc49



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,

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com


Home | Main Index | Thread Index | Old Index