pkgsrc-Users archive

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

Re: gobject-introspection is like, the worst.



On Thu, Jun 29, 2017 at 01:28:22PM -0400, D'Arcy Cain wrote:
> On 06/29/17 11:41, Joerg Sonnenberger wrote:
> > > Argh!  I will update the docs.  Is that in mk.conf or the environment? What
> > > about the other constants?
> > > 
> > > Can we make it so that if MKGCC or MKLLVM is "yes" that the other is
> > > automatically set to "no"?
> > 
> > Well, the primary point is that HAVE_LLVM triggers the use of
> > compiler-rt etc in libc. As such, libgcc_s should no longer be used.
> > Since that changes the libc ABI, I can't really just change the gcc spec
> > to match that though.
> 
> My point is that if we set MKLLVM to "yes" when, as you suggested, we have
> to set MKGCC to "no" so why not do something like this wherever we are
> scanning these constants:
> 
>  if MKLLVM == "yes": MKGCC = "no"
>  if MKGCC == "yes": MKLLVM = "no"
> 
> I mean, if they are mutually exclusive why not have the build system deal
> with it?  By the way, I assume that the second test is actually redundant
> assuming what I guess are the defaults.

MKLLVM and MKGCC are independent. You can't build part of GCC's runtime
for various reasons with HAVE_LLVM=yes. I've committed the marker to
force it to use GCC for the rest, but the earlier caveat still applies
-- the GCC configuration will introduce potentially subtile problems by
duplicating functionality in the GCC runtime that is intentionally
moving into libc. That means libgcc_s should not be used, but still
might be. The spec fix discussed might solve that problem, but I don't
know for sure.

> You still haven't answered my question although I am mostly positive what
> the answer is.  Are the constants MKLLVM, MKGCC and HAVE_LLVM set in mk.conf
> or the environment.  I assume the latter.

mk.conf or via -V to build.sh.

Joerg


Home | Main Index | Thread Index | Old Index