Support GCC runtime

["Jonathan Perkin" <jperkin%joyent.com@localhost>]

Hi,

Background
==========

  SmartOS, and possibly other systems, do not provide a native GCC,
  and instead rely on pkgsrc to provide it.  Packages which rely on
  the GCC runtime (libgcc/libstdc++ etc) thus need to depend upon the
  entire GCC package, which is much larger than necessary if all you
  want to do is run binaries.  This is exacerbated when devel/binutils
  is pulled in as well, as is again the case on SmartOS.

  Additionally, we would like to support building with an external
  compiler but using the pkgsrc runtime.  This aids in bulk builds,
  when you do not want to depend upon a full gcc package for every
  single build (USE_PKGSRC_GCC is broken anyway in this use-case).

Proposal
========

  We split gcc47 into separate -compiler and -runtime packages, and
  retain a meta package for gcc47 which includes both.  Packages can
  now depend upon just the -runtime package for _GCC_USE_SHLIB.

  In order for an external compiler to be used in conjunction with the
  pkgsrc runtime, we introduce a new USE_PKGSRC_GCC_RUNTIME user
  variable, which instruments a -specs override to ensure the pkgsrc
  runtime is used.  It is left to the user to ensure that the external
  compiler and the pkgsrc runtime are compatible.

  Finally, we add logic to ensure that _USE_GCC_SHLIB=yes is set only
  when necessary - previously this was set unconditionally on Solaris,
  resulting in the runtime being a dependency even when it wasn't
  required.  Currently, this is triggered either when USE_LIBTOOL is
  enabled, or a new USE_GCC_RUNTIME package variable is set.

  The rationale for the above is that we need to cover the case where
  shared libraries are being produced.  pkgsrc already enables the
  runtime based on USE_LANGUAGES, but there is no detection currently
  for C-based shared libraries.  Thus, USE_LIBTOOL is an easy way to
  get the majority of coverage, and USE_GCC_RUNTIME can be set by
  packages which produce shared libraries, but do not use libtool (of
  which I can only find a handful).

Caveats
=======

  This means two builds of gcc, as there doesn't seem to be an easy
  way to just build the parts necessary.  Multi-packages would be a
  huge win here as we are duplicating the entire build twice only to
  remove certain bits from the install, is anyone working on this? :)

  The USE_LIBTOOL/USE_GCC_RUNTIME stuff isn't particularly clean, but
  I don't know of a better way - any ideas?

  We need to special case the dependency on the runtime to avoid
  packages which themselves are dependencies of the runtime.
  Currently this is devel/libtool-base and devel/binutils.  The
  hardcoding of package paths in mk/compiler/gcc.mk isn't something
  I'm proud of, but again I don't know of a better way.

  Related to the above, we really could do with fixing USE_PKGSRC_GCC,
  as currently it is pretty much useless, given there are many
  packages which are dependent of gcc itself, leading to immediate
  circular dependencies.  Adding a list of dependent packages to an
  exclusion would fix it, but even more ugly than above.

Code
====

  The current diff is available here:

    
https://github.com/joyent/pkgsrc/compare/jsonn:trunk...joyent:joyent_gccruntime

  Or you can view the files directly via the interface:

    https://github.com/joyent/pkgsrc/tree/joyent_gccruntime/lang/gcc47
    https://github.com/joyent/pkgsrc/tree/joyent_gccruntime/lang/gcc47-compiler
    https://github.com/joyent/pkgsrc/tree/joyent_gccruntime/lang/gcc47-runtime

We've used the above patch (and variations on it) for a while, and it
seems to work well.

Thanks,

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