Re: using clang from pkgsrc to build packages?

[Havard Eidnes <he%uninett.no@localhost>]

>> ... on NetBSD/amd64 8.0, pkgsrc defaults to build e.g.
>> gnustep-base with clang, but fails with this excerpt from
>
> I had no idea.  This is a wrinkle, but I think our choices are
>
>   don't worry and let it be
>
>   stop abusing PKGSRC_COMPILER, and fail the build if the chosen
>   compiler is gcc

../../devel/gnustep-make/gnustep.mk appears to make a concious
decision to default to build gnustep with clang, as a matter of
fact it says "ONLY_FOR_COMPILER=clang", if the "fragile" option
is not used (which appears to default to off).

> Regarding the issue:
>
>> (and more undefined _Unwind* symbols).  Hm, the libobjc.so it
>> links with is from gnustep-objc, and contrary to the base system
>> libobjc.so, it doesn't have a run-time dependency on libgcc_s.so
>> which defines these symbols:
>>
>> d3: {16} ldd /usr/pkgsrc/devel/gnustep-base/work/.buildlink/lib/libobjc.so
>> /usr/pkgsrc/devel/gnustep-base/work/.buildlink/lib/libobjc.so:
>>         -lpthread.1 => /usr/lib/libpthread.so.1
>>         -lc.12 => /usr/lib/libc.so.12
>
> On netbsd-7 amd6:
>
> $ ldd /usr/pkg/lib/libobjc.so.4.6.0
> /usr/pkg/lib/libobjc.so.4.6.0:
>          -lpthread.1 => /usr/lib/libpthread.so.1
>          -lgcc_s.1 => /usr/lib/libgcc_s.so.1
>          -lc.12 => /usr/lib/libc.so.12

I know, and it's that way in 8.0 too.  But that's not the
libobjc.so which gnustep-base tries to link against, it instead
tries to link against the one produced by gnustep-objc, which
does not have a recorded run-time dependency on libgcc_s.so, and
therefore ends up with the Unwind symbols as undefined.

In some sense I can see that it feels wrong to let the
replacement compiler for gcc still depend on and use bits from
gcc; not sure whether that's the reasoning behind the current
state of affairs, but then again, I don't see where else those
bits are supposed to come from.

Suggestions for how to fix this "properly" warmly welcomed.

Regards,

- Håvard