Page MenuHomePhabricator

[libomptarget][amdgpu] use --allow-shlib-undefined to link on FreeBSD
ClosedPublic

Authored by dim on Aug 7 2021, 12:40 PM.

Details

Summary

On FreeBSD, the environ symbol is undefined at link time for shared
libraries, but resolved by the dynamic linker at runtime. Therefore,
allow the symbol to be undefined when creating a shared library, by
using the --allow-shlib-undefined linker flag, instead of -z defs
(a.k.a --no-undefined).

Diff Detail

Event Timeline

dim created this revision.Aug 7 2021, 12:40 PM
dim requested review of this revision.Aug 7 2021, 12:40 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 7 2021, 12:40 PM
Herald added a subscriber: wdng. · View Herald Transcript
JonChesterfield accepted this revision.Aug 7 2021, 2:52 PM

That'll work. It means freebsd gets less link time sanity checking though.

The correct fix might be to use a platform abstraction over environment access. There's probably one in the llvm libraries we can use.

This revision is now accepted and ready to land.Aug 7 2021, 2:52 PM
dim removed a subscriber: sstefan1.Aug 8 2021, 4:52 AM

That'll work. It means freebsd gets less link time sanity checking though.

The correct fix might be to use a platform abstraction over environment access. There's probably one in the llvm libraries we can use.

Well, the environ usage actually comes from llvm/lib/Support. :) But it's a known problem; typically shared libraries don't really have their own environ, it's supposed to be provided by the main program loading those shared libraries. But glibc solves this by providing the symbol itself as a weak alias. In https://reviews.freebsd.org/D30842 there's a discussion going on about something similar for FreeBSD's libc, but it's not decided yet...

Thanks for the context!

So glibc puts the environ symbol in the crt that is linked into the top level executable and a weak symbol in dynamic libraries. That sounds like something that does not work - weak symbols are a link time thing, not a load time thing - but a short walk down that rabbit hole suggests glibc's loader used to replace weak symbols with strong ones when both were present. I vaguely wonder if that is the case if the main executable is missing the dynamic symbol table. No doubt glibc has adequately aligned things to that this continues to work as intended.

I am curious what the behaviour of weak symbol in a dynamic library + normal symbol in main (or another dynamic library) is on the various libc implementations but will resist pulling on that string for now.

I do wonder if we should add a special case to LLD to ignore undefined environ and __progname for shared library outputs since I'm not sure how/whether to proceed with https://reviews.freebsd.org/D30842.