15/02/2022 16:31, Bruce Richardson: > On Mon, Feb 14, 2022 at 12:43:13PM +0100, Karl Bonde Torp wrote: > > When building with Meson 0.61.1 on FreeBSD some archives become > > corrupted. This can be avoided by using 'llvm-ar' instead of 'ar'. > > > > Signed-off-by: Karl Bonde Torp <k.t...@samsung.com> > > --- > > buildtools/meson.build | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/buildtools/meson.build b/buildtools/meson.build > > index 400b88f251..e1c600e40f 100644 > > --- a/buildtools/meson.build > > +++ b/buildtools/meson.build > > @@ -31,6 +31,9 @@ if host_machine.system() == 'windows' > > pmdinfo += 'llvm-ar' > > endif > > pmdinfogen += 'coff' > > +elif host_machine.system() == 'freebsd' > > + pmdinfo += 'llvm-ar' > > + pmdinfogen += 'elf' > > else > > pmdinfo += 'ar' > > pmdinfogen += 'elf' > > Based off the instructions you posted later in the thread, I've reproduced > the issue - and then done a little extra investigation. Here is my > understanding: > > * By default on FreeBSD the linking is being done by llvm-ar > * The resulting libraries are being linked as thin archives and "ar" binary > does not seem to be able to process them. > * When building with CC=gcc on FreeBSD, "ar" is used as a linker, and the > resulting archives are regular .a files. > * On Linux, whether building with clang or gcc, "ar" seems to be used as > linker. > > The ideal situation here would be if we could use meson to report itself > what the static linker in use is, but unfortunately while we can query the > dynamic linker using "meson.compiler().get_linker_id()", there doesn't seem > to be an equivalent for the static linker. Therefore, the only option seems > to be a fix as here. Only question remains as to whether we want to only > use llvm-ar for clang builds on FreeBSD or use if for all builds on FreeBSD. > I'm not sure it makes much difference either way, but I'd tend towards > limiting the use of llvm-ar to only clang builds. > > With or without this suggested change, > > Acked-by: Bruce Richardson <bruce.richard...@intel.com>
Applied, thanks.
