Fedora – Purpose of /usr/lib/.build-id/ Directory

Ethernet cards might have (supposedly) unique MAC addresses, but what about virtual interfaces like aliases (e.g. eth0:0), bridges or VPNs? They need an ID too, so an UUID would be a good fit.

By the way, since the question is about NetworkManager and NetworkManager deals with connections, there are scenarios where you can have multiple connections for a device. For example you have a laptop with an Ethernet card which you use both at home and at work. At home you're using only IPv4 like most home users, but at work you're using only IPv6 because the company managed to migrate to it. So you have two different connections which need different IDs, so the MAC address of the Ethernet card can't be used by itself. Therefore an UUID is again a good fit for an ID.

make itself has likely not much to do with the problem. The symptoms are typical of using wrong toolchain and/or libraries. The output indicates that the linker in use is the stock Fedora ld, which on 64bit Fedora would mean a toolchain capable of producing x86_64 binaries.

skipping incompatible /usr/lib/libc.a

tells you, that the linker tried linking with /usr/lib/libc.a but found it (binary) incompatible with the rest of the compiled code in md5_x86_64.o and mfsrv_x86_64.o. This typically arises due to an architecture mismatch - in this case it seems that the build system attempts to link a 64bit object files with a 32bit library (note that the same command for 32bit binary with -m32 went through just fine). Thus it seems that the compiler is not getting the right options when linking the 64bit binary. As a first step in debugging you might want to try building manually - i.e. issuing the failing command in the build tree by hand.

What is also rather surprising (at least for me) in your case is this:

mips-linux-gnu-gcc -EL -Wl,-rpath /export/home/git/minerva-5.x/cs_rootfs_1.2.15/cross_rootfs/lib -L/export/home/git/minerva-5.x/cs_rootfs_1.2.15/cross_rootfs/lib -o mfcln md5.o bitmapfs.o mfcln.o mulfiles.h mulfiles_msg.h md5.h bitmapfs.h
gcc -O -Wall -m32 -c -o md5_x86_32.o md5.c

that is: part of the build using the cross toolchain and part using the native one and in both the 64bit and 32bit flavours. Which might be all right, but looks a bit strange.