Static SAL problem on macOS

[simonjwright]

(at any rate, if they use tasking and the using program doesn’t)

While building libadalang for macOS, I found that the static SAL wasn't properly built. The symptom was that while trying to build the contrib/highlight example, there were a lot of missing files in the link.

I traced this to the tasking component, libgnarl.

The reason for this turns out to be that macOS doesn't provide a native objcopy, which gprlib wants to use to insert a special section called .GPR.linker_options in the packed-together object code. You can tell this because (if you build with at least -vl) you see

/opt/gcc-11.1.0/bin/objcopy --add-section .GPR.linker_options=l.linker_options p__l_0.o
Warning: unable to locate objcopy /opt/gcc-11.1.0/bin/objcopy. Linker options for SAL will not be stored.

I thought, would llvm-objcopy work? -- the answer is No, because for Mach-O

• the argument to --add-section needs to consist of <segment>,<section> (I don't know what segment to use)
• the section name is limited to 16 characters (by experiment), i.e. .GPR.linker_opti.

This would seem to imply that Homebrew's objcopy couldn't work either?

I seem to remember that ages ago I was in favour of static SALs, but now I have to ask what benefit they bring to the table? Wouldn't it be simpler to just ignore Library_Interface if building a static library?

[anisimkov]

https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gnat_ugn_unw/Introduction-to-Stand-alone-Libraries.html#Introduction-to-Stand-alone-Libraries You can check Project'Canonical_Target or Project'Target attributes and to do not provide Library_Interface on MacOS

[t-14]

I seem to remember that ages ago I was in favour of static SALs, but now I have to ask what benefit they bring to the table?

They bring to the table standalone elaboration (compared to regular libraries which are elaborated as part of the main application) and the possibility to deploy to users only the specs of the interface.

Wouldn't it be simpler to just ignore Library_Interface if building a static library?

Well, you'll lose standalone-ness. It's for you to decide if you do or don't care about that.

As we don't support MacOS I am closing this PR.

[simonjwright]

Well, you'll lose standalone-ness. It's for you to decide if you do or don't care about that.

On the whole I would rather have a library which works. Imagine, if you will, how happy I am to have spent the last several hours finding out why this didn’t work.

Oh, and by the way, even when I put a copy of llvm-objcopy on my PATH in ~/bin/objcopy the error messages from gprlib were still as if the problem was arising in /opt/gcc-11.1.0/bin/objcopy.

[t-14]

On the whole I would rather have a library which works

No doubt, but that's the reason why we don't support macOS - it just has too many quirks.

Oh, and by the way, even when I put a copy of llvm-objcopy on my PATH in ~/bin/objcopy the error messages from gprlib were still as if the problem was arising in /opt/gcc-11.1.0/bin/objcopy.

I am not sure what you mean, can you clarify?