multiple definition of `libxsmm_scratch_pools' (and other symbols)

[yurivict]

Beginning from clang version 11 the default has changed from allowing global variables to be defined in the headers (-fcommon) to not allowing it (-fno-common).

Now the build fails due to the symbols like libxsmm_scratch_pools being defined in libxsmm_main.h:

/usr/local/bin/ld: build/intel64/generator_spgemm_csr_bsparse_soa.o:(.bss.libxsmm_scratch_malloc_fn+0x0): multiple definition of `libxsmm_scratch_malloc_fn'; build/intel64/generator_common.o:(.bss.libxsmm_scratch_malloc_fn+0x0): first defined here
/usr/local/bin/ld: build/intel64/generator_spgemm_csr_bsparse_soa.o:(.bss.libxsmm_scratch_pools+0x0): multiple definition of `libxsmm_scratch_pools'; build/intel64/generator_common.o:(.bss.libxsmm_scratch_pools+0x0): first defined here
/usr/local/bin/ld: build/intel64/generator_spgemm_csr_bsparse_soa.o:(.bss.libxsmm_scratch_scale+0x0): multiple definition of `libxsmm_scratch_scale'; build/intel64/generator_common.o:(.bss.libxsmm_scratch_scale+0x0): first defined here
/usr/local/bin/ld: build/intel64/generator_spgemm_csr_bsparse_soa.o:(.bss.libxsmm_target_archid+0x0): multiple definition of `libxsmm_target_archid'; build/intel64/generator_common.o:(.bss.libxsmm_target_archid+0x0): first defined here
/usr/local/bin/ld: build/intel64/generator_spgemm_csr_bsparse_soa.o:(.bss.libxsmm_threads_count+0x0): multiple definition of `libxsmm_threads_count'; build/intel64/generator_common.o:(.bss.libxsmm_threads_count+0x0): first defined here

Log: http://beefy18.nyi.freebsd.org/data/head-amd64-default/p549079_s365919/logs/libxsmm-1.10_6.log (IPv6 URL)

[hfp]

Ok, this is similar to what GCC 10.x did, but I need to account for Clang 11.x the same way. Thank you for the heads-up!

[hfp]

This requires to build/install ports-mgmt/pkg and devel/llvm11 (following this guide).

[yurivict]

No.

You need to fix what C++ compiler doesn't allow any more by default.
Installing a port would bring the same clang-11 packaged in a different way.

[hfp]

I have the infrastructure for applying "common" as an attribute which means this issue can be solved without relying on a compiler flag. This is important since LIBXSMM allows header-only usage, i.e., a 3rd party build system may build our sources. I am currently installing clang-11 as per my comment because I want to reproduce the problem (I tried 11/nightly under Linux/Debian and I did not run into the same problems as solved for GCC 10.x hence I want to reproduce the issue first).

[hfp]

( This boils down to the question how did you get to this error? As far I can see, FreeBSD does not yet provide Clang-11 per pkg; so I found building it myself out of the ports-tree is perhaps the best choice. )

[yurivict]

FreeBSD 13-CURRENT has clang-11 as default compiler in its base.

The llvm11-11.0.0.r2 package also installs clang-11 on all OS versions.

[yurivict]

This line:

libxsmm-1.16.1/src/libxsmm_main.h:LIBXSMM_APIVAR_PRIVATE(unsigned int libxsmm_scratch_pools);

causes the issue because it defines this variable in the header.

You need to add the qualifier extern to it.

[hfp]

Thank you for the details. I am getting an instance of FreeBSD 13-CURRENT (I was still on 12.1).

[hfp]

This issue was solved starting in LIBXSMM v1.15. I just realized late that the report is based on v1.10 (Btw, I cannot access the log). LIBXSMM v1.10 was released (long) before GCC v10 or Clang v11 and there is no intent to back-port this resolution.

Wrt FreeBSD, I think the ports' Makefile can be cleaned up regarding post-install step as well as files/patch-Makefile (CFLAGS/-fcommon, -install-all: install samples, etc.). I adjusted our install-all target to better suit FreeBSD.

[hfp]

Feel free to report any issue that you encounter when packaging for FreeBSD incl. workarounds you need otherwise!

[yurivict]

Thanks!