Bug 235547

Summary: Mk/Uses/objc.mk: fix build of objc ports with GCC-based architectures
Product: Ports & Packages Reporter: Piotr Kubaj <pkubaj>
Component: Ports FrameworkAssignee: Mark Linimon <linimon>
Status: Closed Not Accepted    
Severity: Affects Only Me CC: linimon, theraven
Priority: ---    
Version: Latest   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
patch
none
updated patch to objc.mk none

Description Piotr Kubaj freebsd_committer freebsd_triage 2019-02-06 05:29:51 UTC 
Created attachment 201784 [details]
patch

After https://svnweb.freebsd.org/ports?limit_changes=0&view=revision&revision=492056, gnustep-base doesn't build (tested on powerpc64):
https://talos.anongoth.pl/data/powerpc64-default/2019-02-03_19h13m04s/logs/gnustep-base-1.26.0_1.log

The reason is that there are bugs in lld for powerpc64, clang itself is ok.

After changing to Binutils ld, it builds: https://talos.anongoth.pl/data/powerpc64-default/2019-02-05_05h49m32s/logs/gnustep-base-1.26.0_1.log

Hardware sponsored by IntegriCloud.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2019-02-06 13:37:16 UTC 
Created attachment 201787 [details]
updated patch to objc.mk

IIUC the suggested patch changes the behavior on tier-1.  I propose a patch not to do so.  In addition, don't we need to include a dependency on binutils in the tier-2 case?
Comment 2 Piotr Kubaj freebsd_committer freebsd_triage 2019-02-06 13:53:05 UTC 
(In reply to Mark Linimon from comment #1)
I tried linking using base ld and it seems to work, so no binutils from ports are needed.
Comment 3 David Chisnall freebsd_committer freebsd_triage 2019-02-06 16:32:56 UTC 
Please can you test whether the -base test suite works (gmake check in the build directory)?  On amd64, you can link with BFD ld, but the resulting library doesn't actually work, which is why we enforce lld.  A few things don't work with lld, but do work with gold and so we use gold for those (they're marked LLD_UNSAFE).  Setting LD=ld is almost certainly wrong, because if ld is ld.bfd then this produces nonfunctional binaries for most Objective-C code.

Does just setting LLD_UNSAFE unconditionally on powerpc64 for Objective-C things work?  This will make them fall back to gold with the existing logic, and gold appears to work for Objective-C at least as well as lld (on amd64).
Comment 4 David Chisnall freebsd_committer freebsd_triage 2019-02-06 16:37:13 UTC 
The log file is also a bit confusing.  It appeas to be passing -fobjc-runtime=gnustep-1.8 to the builds.  The latest changes set this to gnustep-2.0, which was an ABI-breaking change and is responsible for triggering the issues with BFD ld.  Please make sure that this is what you see in the compile lines when testing.
Comment 5 Piotr Kubaj freebsd_committer freebsd_triage 2019-02-07 07:55:55 UTC 
Hm, ok. It doesn't work. I guess we can close it :(
Comment 6 David Chisnall freebsd_committer freebsd_triage 2019-02-07 09:00:17 UTC 
I'd be quite happy just marking anything that uses objc as broken on platforms that clang doesn't support.  GCC supports an archaic dialect of Objective-C and anyone that actually tries to use it will likely have a poor experience.
Comment 7 Piotr Kubaj freebsd_committer freebsd_triage 2019-02-08 07:29:12 UTC 
(In reply to David Chisnall from comment #6)
No problem, it doesn't work anyway.

There's WiP to migrate to Clang and elfv2 for FreeBSD 13 so I hope we'll soon be able to unbreak it.