Re: loading bundles stopped working

[Sebastian Reitenbach]

Am Dienstag, November 27, 2018 19:26 CET, Matt Rice <ratmice@gmail.com> schrieb:

> On Mon, Nov 26, 2018 at 7:18 AM David Chisnall
> <gnustep@theravensnest.org> wrote:
> >
> > On 26/11/2018 15:03, Sebastian Reitenbach wrote:
> > >  From the stacktrace, It's the last NSCAssert1 that fires, right after 
> > > that line:
> > > backend = NSClassFromString (@"GSBackend");
> >
> > Yup.  That makes me think either:
> >
> > - The dlopen failed.
> > - The dlopen returned success, but didn't call the constructor, so it
> > didn't call __objc_exec_class.
> > - The library was loaded but some memory was corrupted.
>
> ISTR constructor call order is undefined, and openbsd (has/had) a
> called constructors in an order which was
> reversed from the order that glibc calls them, so possibly
> a) openbsd changed their order,
> b) something was added which relies upon the order of calls happening
> in the glibc order
>
> could cause the second? i.e. the constructor would eventually be
> called, but hasn't been called yet.

The thing that changed was the linker, at 22nd of October, the default linker
on amd64 platform changed from the good old bfd linker to the lld linker from
llvm.

As a workaround for the time being, I pass -fuse-ld=bfd, as David suggested,
to unbreak all the GNUstep applications in the ports tree. So the lld linker is
doing something different to the resulting binary than the old bfd linker did.

Will it help to run nm, or objdump or the like on the binary, or the libraries
to compare output between what it produces when using lld or bfd linkers?

Sebastian

>
> > > So before that, there's the other NSCAssert1, [theBundle load], and since
> > > this doesn't fire, I think loading it, went OK?
> > > But I might well be on the wrong track.
> >
> > Can you disable the breakpoint on __objc_exec_class until just before
> > the [theBundle load] line, then enable it and make sure that it's called
> > *after* the dlopen call?  Can you also check in the code that we're
> > actually checking the return from dlopen correctly (I'm pretty sure we are).
> >
> > If all this works, can you check in each __objc_exec_class call and see
> > if one of the classes that it loads is called GSBackend?  If so, then it
> > looks as if there's still something wrong with the hash table in
> > libobjc2.  I think I back-ported all of the fixes to the 1.9 branch, but
> > I might have missed one...
> >
> > David
> >
> > _______________________________________________
> > Discuss-gnustep mailing list
> > Discuss-gnustep@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnustep