Re: plmerge core dumps...

[David Chisnall]

On 13/02/2020 16:51, Richard Frith-Macdonald wrote:
> 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.

Correct.  The v2 ABI depends on a couple of interesting features:

1. The linker creates __start_{section} and __stop_{section} symbols 
within each linked output that give the range of a section.
2. Some COMDAT merging so that the function that calls the Objective-C 
load function is deduplicated and so is the pointer to it in the .ctors 
or .init section (which causes the run-time linker to call it) and the 
data structure that it passes to the linker.

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

It appears as if BFD ld is resolving one or both of these too early, so 
the set of sections provided in the final link does not include the ones 
from the subproject.  I haven't looked too closely which part is failing.

> 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)?

If GNUstep Make had the conventional configure/build split, then I'd 
recommend adding a check that the linker was BFD and aborting if so.  I 
don't want to enforce gold, because LLD also works fine (as does 
LINK.EXE or LLD-LINK.EXE on Windows).  On many platforms, LLD is the 
default linker, it is only GNU/Linux where the default linker does not work.

David