On 2018/09/10 17:20, Christian Weisgerber wrote:
> We have two ports (net/utox, www/mozplugger) that do something like this
>
> ld -r -b binary -o foo.o foo.blob
>
> to create an object file with a .data section from a binary blob.
> This works fine with ld.bfd, but ld.lld
>
> ld: error: target emulation unknown: -m or at least one .o file required
>
> requires an additional -m<emulation> argument. The value for this
> is arch-specific in an unpredictable way. I had to dig it out of
> the lld source.
>
> We need a mapping from arch to emulation. Do we want to abstract
> this into arch-defines.mk, or do we just add it to the two affected
> ports?
>
> For arch-defines.mk, we could use something like the diff below:
>
> Index: arch-defines.mk
> ===================================================================
> RCS file: /cvs/ports/infrastructure/mk/arch-defines.mk,v
> retrieving revision 1.52
> diff -u -p -r1.52 arch-defines.mk
> --- arch-defines.mk 8 Aug 2018 09:19:40 -0000 1.52
> +++ arch-defines.mk 10 Sep 2018 14:49:35 -0000
> @@ -31,6 +31,13 @@ RUST_ARCHS = amd64 i386 aarch64
> CLANG_ARCHS = aarch64 amd64 arm i386
> # arches using LLVM's linker (ld.lld); others use binutils' ld.bfd
> LLD_ARCHS = aarch64 arm
> +# see llvm/tools/lld/ELF/Driver.cpp
> +LLD_EMUL =
> +.for A E in aarch64 aarch64elf arm armelf amd64 elf_amd64 i386 elf_i386
> +. if ${MACHINE_ARCH} == $A
> +LLD_EMUL = $E
> +. endif
> +.endfor
>
> # arches where ports devel/llvm builds - populates llvm ONLY_FOR_ARCHS
> # as well as available for PROPERTIES checks.
arch-defines seems the right place - it might be helpful to add the
"-m" in ${LLD_EMUL} so that it can be used directly in command lines,
rather than have consumers check whether it's non-empty and add "-m"
themselves?
