Re: plmerge core dumps...

[Richard Frith-Macdonald]

> On 13 Feb 2020, at 14:15, David Chisnall <gnustep@theravensnest.org> wrote:
> 
> On 13/02/2020 10:35, Richard Frith-Macdonald wrote:
>> Is it a bug in the linker?
> 
> It is, but it is a bug that shows up *only* with ld -r.  LLD did not support 
> ld -r for a long time and that made no difference to over 90% of the things 
> in the FreeBSD ports collection.  It is a very rarely used corner case for 
> the linker and so likely to be very poorly tested (it also has quite poorly 
> defined semantics, which is part of the problem).
> 
> GNUstep Make uses this for 'subprojects'.  We hit this early because -base 
> Additions is a subproject.  These are compiled as .o files and then linked to 
> form a single .o file using ld -r.  Most modern build systems would typically 
> just pass the list of .o files to the parent project to link, but GNUstep 
> Make tries to create a single subproject.o.
> 
> It is good that -base tests this corner case of -make, because it would 
> otherwise hit external users, but I am not convinced by the value of this 
> option in GNUstep Make overall (though, as I have said before, I am also not 
> convinced of the value of investing time and engineering resources in 
> maintaining a custom build system that does not compose well with any other 
> project's build system).

Thanks for that information.

My (limited) understanding of -r is that it's for incremental linking, where 
the file produced by the linker can itself be used to be linked into an 
executable. 

So is the problem then in the generation of the subproject rather than in the 
final linking?

If so, perhaps we could solve this by altering gnustep-make to add 
'-fuse-ld=gold' to the command line used to build a subproject (and perhaps 
when building a bundle)?