More custom toolchain issues

[Nomura RH]

Hi,

First of all, I'd really like to thank eli-schwartz for the support they gave in my previous issue. I wasn't able to thank them properly because the thread got closed before I had a chance to reply.

In that thread I was encouraged to ask questions about Meson codebase's inner workings, as there are no docs for them. I'm trying to add support for a new toolchain, and I've gotten most things to work. There are a few things I am currently stuck on:

1. When linking a static library target to an executable, Meson encloses the argument needed to link the library within single quotes (in my case this is just the path to the .a file, no -l needed). Unfortunately, my linker chokes on them. If I manually edit the generated build.ninja and remove the quotes, the link occurs successfully. This only happens with the library argument, all other link args end up unquoted. Is this behavior compiler-specific, or (as I suspect), a general Meson thing?

2. From what I understood, Meson supports compiling assembly pretty much only through the compiler's front-end (I know about generators, but they are more of a workaround than a solution, as they make build files toolchain-specific since you have to hardcode arguments and whatnot).

But, you guessed it, the compiler I'm working with isn't able to do that. I have to find a way to tell Meson to invoke the assembler directly. How should I go about it? Is this even possible right now, or should I wait for/contribute to proper asm support?  I see that there is limited support for assemblers (MASM, NASM and YASM), but those seem to be edge cases. 

3. This is low priority, but Meson seems to generate thin archives by default if the static linker supports doing so. My toolchain's linker, which normally works as both the dynamic and static linker, can link GNU ar libraries; however, it does not support thin archives. Is there a way to tell Meson to generate normal archives? I couldn't find anything in the documentation.

[Alan Coopersmith]

On 3/23/23 06:36, Nomura RH wrote:
> 3. This is low priority, but Meson seems to generate thin archives by default if
> the static linker supports doing so. My toolchain's linker, which normally works
> as both the dynamic and static linker, can link GNU ar libraries; however, it
> does not support thin archives. Is there a way to tell Meson to generate normal
> archives? I couldn't find anything in the documentation.

The linker on my platform also doesn't support thin archives (they're a GNU ld
invention, and I don't know if any non-GNU linkers support them yet) - so I had
to modify meson to know not to try to make thin archives on Solaris:

https://github.com/mesonbuild/meson/pull/11050

So you'd presumably need to add your toolchain's linker to the growing list at:

https://github.com/mesonbuild/meson/blob/4fedf19f41a99e0abd5ed18916e42e12e420c6bf/mesonbuild/linkers/linkers.py#L211-L220

(Or maybe meson should reverse the polarity of this list and only use thin
archives when using the linkers known to support this new feature.)

--
-Alan Coopersmith- alan.coo...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris

[Eli Schwartz]

On 3/23/23 12:39 PM, Alan Coopersmith wrote:
> The linker on my platform also doesn't support thin archives (they're a
> GNU ld
> invention, and I don't know if any non-GNU linkers support them yet) -
> so I had
> to modify meson to know not to try to make thin archives on Solaris:
>
> https://github.com/mesonbuild/meson/pull/11050
>
> So you'd presumably need to add your toolchain's linker to the growing
> list at:
>
> https://github.com/mesonbuild/meson/blob/4fedf19f41a99e0abd5ed18916e42e12e420c6bf/mesonbuild/linkers/linkers.py#L211-L220
>
>
> (Or maybe meson should reverse the polarity of this list and only use thin
>  archives when using the linkers known to support this new feature.)

Ah, so instead of or in addition to checking if the archiver supports
making them, check if the dynamic linker can swallow them?

Would it be sufficient to check that the dynamic linker is
GnuDynamicLinker (so, bfd, gold, mold) or LLVMDynamicLinker (ld.lld)? Is
there any other case that matters?

I *think* I recall that the issue was using a GNU binutils ar in
combination with a linker that doesn't support everything that a
binutils ar can produce, right?


--
Eli Schwartz

[Alan Coopersmith]

Yes, now that you mention it, I think this was building packages with
/usr/gnu/bin ahead of /usr/bin in $PATH since they required things such
as GNU msgfmt instead of Solaris msgfmt, which also meant GNU ar was
found instead of Solaris ar, so thin archives were able to be built,
but could not used at link time with the Solaris linker.