tech-pkg archive

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

Re: Using a replacement linker with pkgsrc

* On 2020-06-25 at 22:47 BST, Brook Milligan wrote:

> > On Jun 25, 2020, at 1:23 PM, Jonathan Perkin <> wrote:
> > 
> > I mean set the "always-libgcc" option, i.e. add
> > 
> >  PKG_OPTIONS.gcc49+= always-libgcc
> > 
> > to your mk.conf.
> Perfect.  That fixed the problem and I now see
> gcc49/lib64/ installed.
> I am guessing that I would need to enable this for any version of
> gcc I might also want to build from pkgsrc.  Is that the
> expectation?

Yeh, I think it has made its way to most versions of gcc.  FWIW you
can also use:

  PKG_DEFAULT_OPTIONS+=  always-libgcc

which I have set for all of my Linux builds, rather than repeating for
every version.

> Why is this not the default?  It would seem that if we build a
> pkgsrc compiler we would always want all the associated libraries,
> but perhaps I am missing something.

I don't really know, but there appear to be two schools of thought in
this area.

One is to try and handle everything automatically and somewhat
magically, attempting to pull in different compilers when the native
compiler does not satisfy GCC_REQD, and somehow ensure that all of the
different runtime libraries or compilers do not conflict.  The default
of not using always-libgcc attempts to work around this by not
installing the pkgsrc libgcc in order to prefer the native libgcc, but
clearly it has issues.

The alternative, and the one that I am strongly in favour of, is zero
magic, where it is up to the user to decide up-front what compiler
they will use to build all of their packages.  This requires them to
think a bit in advance about what baseline they will use, and ensure
that it is bootstrapped first, but results in only a single version of
the GCC runtime being used across all packages, avoids lots of
potential library-related issues, and is much simpler.

AIUI I'm in the minority here though, hence the current defaults.

Jonathan Perkin  -  Joyent, Inc.  -

Home | Main Index | Thread Index | Old Index