Am Donnerstag, November 01, 2018 22:44 CET, "Sebastian Reitenbach" <sebas...@l00-bugdead-prods.de> schrieb:
> Am Donnerstag, November 01, 2018 21:50 CET, Stuart Henderson > <s...@spacehopper.org> schrieb: > > > On 2018/10/30 17:49, Christian Weisgerber wrote: > > > Marc Espie: > > > > > > > > I'm more inclined to remove USE_LLD again. > > > > > What actual use do you envision for either USE_LLD=Yes on !clang > > > > > or USE_LLD=No on clang archs? > > > > > > > > the vmm bios ? doesn't it require some kind of weird 16 bit support. > > > > > > That's a singular case that can be handled by passing in LD=ld.bfd > > > if we can't find a solution with lld. > > > > > > Once we get over the Mesa blocker, I need to talk sthen@ into doing > > > an i386 bulk build with lld. I expect some additional fallout > > > compared to amd64 due to crufty non-PIC asm code, but should anything > > > turn up that can't be made to work with lld, it will likely be a > > > candidate for deletion. > > > > > > I don't exactly forsee a use for USE_LLD on non-x86 either. > > > > Given what we've seen with various readline related ports and now Qt > > (link succeeds, runtime fails) it does seem like it might be useful > > for porters to be able to flip back if they need to test and compare > > behaviour until we've got a bit more experience .. > > > > Also, I'm looking into the problem of www/sogo, see the backtrace I just sent, > it smells like ld being the culprit. This is objective-c stuff, not havily > used > throughout the ports tree outside x11/gnustep. I haven't yet tested > all the desktop goo. > I'll try this patch here to switch back to ld.bfd, and see if it makes a > difference. I manually fiddled with bsd.port.mk to set LD_PROGRAM to ld.bfd, rebuilt everything: gnustep-libobjc2/gnustep-make/gnustep-base/sope/sogo afterward it starts up fine. So, the linker change is the culprit here as well. Sebastian > > Sebastian >
