When building mono in an environment that more closely resembles the LFS requirements (LIBDIR_x86=lib; LIBDIR_amd64=lib64; SYMLINK_LIB=no), mono.eclass forcibly moves all the mono assemblies from /usr/lib/mono to /usr/lib64/mono. As mono itself is built in such a way that it only looks in /usr/lib/mono for the assemblies, no mono program can be built without first creating an extra symlink from "/usr/lib/mono" to "../lib64/mono". As the .Net assemblies are (effectively) architecture independent, or, at least, not 64-bit ELF objects, they can be properly placed in /usr/lib.
*** Bug 377455 has been marked as a duplicate of this bug. ***
Only question I have with this is what about dll.so files. Which are aot compiled and therefore arch dependent.
(In reply to comment #2) > Only question I have with this is what about dll.so files. Which are aot > compiled and therefore arch dependent. There are none. All files in /usr/lib*/mono on my system have one of the following types, according to file(1) (none of which are specific to my 64-bit system): ASCII HTML document text ASCII text ASCII text, with CRLF line terminators ASCII text, with no line terminators data exported SGML document, ASCII text PE32 executable (console) Intel 80386 Mono/.Net assembly, for MS Windows PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows UTF-8 Unicode (with BOM) text XML document text The "data" files are all arch-independent .mdb debug information files, similar to the ELF .debug files you get with splitdebug.
Created attachment 284829 [details, diff] initial patch for eclass
I think I'm seeing this now that I'm migrating x86 -> amd64. I can't rebuild any of that *-sharp packages, because they can't find their stuff in /usr/lib. What's the latest on this, anyone know?
