https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076
--- Comment #22 from Andre Vehreschild <vehre at gcc dot gnu.org> --- (In reply to Jerry DeLisle from comment #21) ... > Additional information with these patches. I see the following installation > with make install. > > :~/dev/usrav/lib/gcc$ ls x86_64-pc-linux-gnu/16.0.0/ > 32 crtbeginT.o crtfastmath.o crtprec80.o include-fixed libcaf_shmem.la > libgcc.a plugin crtbegin.o crtend.o crtprec32.o finclude > install-tools libcaf_single.a libgcc_eh.a crtbeginS.o crtendS.o > crtprec64.o include libcaf_shmem.a libcaf_single.la libgcov.a > > You will see the various libcaf libraries install in a subdirectory 'gcc' of > the lib directory. The lib directory is the 32-bit librairies. Er, not to my understanding. lib/gcc/x86_64-pc-linux-gnu/16.0.0 contains a mixture of 32/64-bit files. For example the crtend.o on my 64-bit system is a ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped Therefore I am convinced that also the libcaf_shmem.a in that directory will contain 64-bit object files. > There are no such files in or subdirectory in the lib64 subdirectory which > is for the 64-bit version of the libraries. That's correct. But in lib64 also no caf_single is present. That is also only in lib/x86_... At the moment libcaf_shmem is provided only as a static link library, just like caf_single. I.e., when linking against libcaf_single works, the same should be possible for libcaf_shmem. I can only ask you to do a clean build and maybe also drop the installation directory. Sometimes build systems find funny things and then this oddities happen.
