[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Support GCC runtime
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).
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).
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.
The current diff is available here:
Or you can view the files directly via the interface:
We've used the above patch (and variations on it) for a while, and it
seems to work well.
Jonathan Perkin - Joyent, Inc. - www.joyent.com
Main Index |
Thread Index |