Re: Remove USE_GCC_RUNTIME?

[Greg Troxel <gdt%lexort.com@localhost>]

nia <nia%NetBSD.org@localhost> writes:

>> How does this interact with use of pkgsrc gcc due to GCC_REQD or
>> USE_*_FEATURES?  Or is it only about the USE_PKGSRC_GCC?
>
> USE_PKGSRC_GCC_RUNTIME is set automatically when GCC_REQD is
> higher than the available GCC version on NetBSD at the moment.
> This is NetBSD exclusive and done by the infrastructure.

Ah, that makes sense, but was not apparent when reading compiler/gcc.mk.

> USE_GCC_RUNTIME is supposed to be set by packages. Packages
> that don't set it but use USE_PKGSRC_GCC_RUNTIME might be broken
> because they don't pull in the  requeired dependency.

So basically, if a package will link with any gcc runtime, it's a bug if
it doesn't get USE_GCC_RUNTIME, now?  And therefore afterwards, it will
be as if it is always set (except we'll skip the set it and test it
bit!)?

>> Why is this about libtool?  What is it doing, that the other build
>> systems don't?  Is libtool, or the rest, buggy?  Or is it that when a
>> package is declared to use libtool this dependency processing happens?
>> 
>> Practically, what will change in built packages, under what
>> circumstances?  I think you are suggesting that pretty much every
>> package that uses C++ should have defined USE_GCC_RUNTIME, unless it
>> somehow used libtool which did this implicitly, but I don't see how that
>> added a dependency.   But it is hard to tell.
>
> Yeah, I'm not sure I understand what libtool is doing that makes
> it unnecessary either... Perhaps the way libstdc++ is resolved
> is different when using libtool archives?

Could be, but it seems like that would not add a pkgsrc dependency.

> My intention is that any package built using a gcc from pkgsrc
> should have an explicit dependency on the corresponding gccX-libs.

That seems slightly overbroad, in that it seems theoretically possible
it wouldn't have to, but it also seems vastly simplifying and that the
amount of over-depending is tiny compared to the human cost of dealing
with the bugs from underdepending.  And, once one starts using gccN, the
odds that somethhing on your system will depend on gccN-libs is nearly
unity anyway, so the actual number of cases where gccN-libs is needed on
a system compared to now should be tiny.

This all seems fine to me.  Would be good for someone who actually
understands to comment also, rather than someone who just likes to ask
questions :-)