Re: loading bundles stopped working

[Sebastian Reitenbach]

Hi,

I've to revive this old thread.


Am Sonntag, Dezember 30, 2018 14:51 CET, schrieb David Chisnall 
<gnustep@theravensnest.org>:

> On 25/11/2018 18:30, Sebastian Reitenbach wrote:
> > Hi,
> >
> > since a good months ago, on OpenBSD -current amd64, bundle loading stopped 
> > working. I'm not sure what caused it, at least nothing with regard to objc 
> > and gnustep, since I haven't touched the packages since then.
>
> I have now managed to reproduce this on FreeBSD.  It appears that lld
> does not like GNUstep-back (or SOPE, for that matter) and generates a
> subtly broken library.  Using gold to link -back and lld for everything
> else appears to work.
>
> I now have (locally, not yet committed upstream) the FreeBSD packages
> using the v2 ABI and GUI apps running.  I found a couple of small clang
> bugs, both of which are now fixed upstream (one prevents -base configure
> from running, but doesn't prevent anything real from working - it is 
> only a problem if you create a program or library that doesn't contain
> any Objective-C classes, but does use Objective-C).  I've also merged
> the changes for the new constant string representations into -base.
>
> I'm still debugging a few things.  Cenon crashes on startup (before
> entering main, could be another LLD incompatibility).  Gorm is quite 
> broken with the new ABI because it adds a bunch of categories that
> expose @private fields from classes in AppKit: this is not allowed now
> that @private is enforced by the linker (I don't believe it works on 
> Apple platforms either, for the same reason - the ivar offset variables
> are only publicly exported for things that are part of the public
> interface).  It's still possible to access ivars via reflection, but you
> then have an opportunity to check that the Ivar that the runtime returns
> is not NULL.  I'll try to push some fixes for these things in the next
> few days.
>

 I'm on OpenBSD -current amd64, which meanwhile
comes with clang version 8.0.1 (tags/RELEASE_801/final) (based on LLVM 8.0.1).

Also, in the meantime, I updated to libobjc2-2.0, and enforce using new
ABI with passing in -fobjc-runtime=gnustep-2.0 to all linking, as well as
when building libobjc2, I set OLDABI_COMPAT=Off to be sure nothing 
accidently ignores the fobjc-runtime properly. Other GNUstep packages
are latest releases.

However, when I drop the -fuse-ld=bfd, in order to lld, I still run into the
floating point exceptions I saw a year ago. I link everything GNUstep with
bfd instead of lld. So, now that I link -base with lld, it seems to prevent
an update of icu4c. Not sure what the breakage is, but some fellow packager
pointed that out to me.

Should these clang fixes you mentioned be in 8.0.1 ? When I look here [1]
to the changelog from 03 Feb 2019, as you explained above, your solution to
it is just building -back and SOPE with the old linker instead of building 
everything.

So instead of linking everything, esp. -base with lld, I should only link -back
and SOPE with bfd, and all the rest will hopefully work linked with lld.
Would that be the recommneded way to go ahead, or is there meanwhile some
other better way I'm not aware of yet?

cheers,
Sebastian


[1] https://www.freshports.org/lang/gnustep-base/