Open ikelos opened 6 years ago
Has there been any progress on this? A simple fix appears to be removing the call to dotnet_multilib_comply
. All the files installed in /usr/lib/
are exe
s rather than native linux files, and are therefore architecture agnostic. It's really unclear why this is called is called at all, when mono itself installs its gac files in /usr/lib
and the mono-env
has the following lines:
# mono libs can live on /usr/lib as they are not arch specific
QA_MULTILIB_PATHS="usr/lib/"
Please could we get this fixed, as it's causing problems for anything that depends on gtk-sharp... 5:S
This is now more urgent, since the 17.1 profiles have gone stable.
According to FHS architecture independent files should go into /usr/share
/usr/share | Architecture-independent (shared) data.
mono libs CAN depend on ABI (be ABI-dependent). So they should be installed into /usr/lib64/
I think any which depend on ABI need to be properly split between lib64 and lib (for 32 bit versions). /usr/share is also OK as long as downstream packages know to find it there. This really affects the whole gentoo dotnet environment. I currently have lots of dotnet packages failing, and the errors seem to me to point to finding older versions of stuff under /usr/lib, where there are newer versions under /usr/lib64 - which shows me different packages have different ways of both placing and looking for assemblies, libraries, etc.
If nothing else, we need to achieve consistency of packages. I just tripped on this again. I removed all dotnet related packages, and installed mono 5.16, which puts it's gac under /usr/lib. All those dll's seem to be 32 bit (PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows). I then installed xdt-for-monodevelop which installs to /usr/lib64/mono/gac, which is then not found by nuget (2.8.7-r3). I'll be happy to work on patching ebuilds or eclasses, but I'm really not the right person to decide where things SHOULD go, and I'll need help on figuring out what actually needs patching.
sorry for using multiple identities. I try to use them for different projects, but sometimes use the wrong one.
I know it's the wrong place to ask - but packages that install with egacinstall instead of dotnet_multilib_comply also install to /usr/lib64. (for example xdt-for-monodevelop) so what's a possible fix for those?
Please do more research. Some questions for you to learn: 1) why linux requires 3 different types of libraries? (elf32-i386, elf64-x86-64 and elf32-x86-64) 2) does mono use native libraries (like libgdiplus) via platform invoke (PInvoke) technology? 3) if mono uses native libraries from managed libraries (like System.Drawing), how it determines which directory from the first question to choose? see also https://dev.to/jeikabu/loading-native-libraries-in-c-fh6 and "Mono provides a library mapping mechanism" (here, dllmap) 4) how to set GAC location for mono --prefix option for configure, --libdir option (for object code libraries [EPREFIX/lib]) MONO_GAC_PREFIX environment variable, -gacdir is a Mono only gacutil feature[1] 5) how many[1, 2] GAC instances are necessary to run x86_64 and i386 mono processes? What about x32 mode support? .Net framework 2.0 have a new name attribute ProcessorArchitecture [1], and AssemblyName.ProcessorArchitecture property. New attribute "processorArchitecture" in assemblyIdentity element for App.config with values "x86", "amd64", "msil", and "ia64" (see, no x32). Where GAC_MSIL, GAC_64, and GAC are defined, how they are used? There's a fourth GAC, GAC_32! -platform:string C# compiler option (values: anycpu, x86, x64, ARM, ARM64, Itanuim, anycpu32bitpreferred). 6) How a process starts? ""There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "mscorlib.dll", "AMD64"."[1] 7) What about AOT? Where mono places native code which is generated from "AnyCPU" architecture? "Full AOT currently only works on AMD64/ARM."[1]. "The precompiled image is stored in a file next to the original assembly"[1]
After that please write your proposed solution to discuss. Thanks.
As noted in gentoo bug 645786, the
dotnet_multi_comply
causes packages to install their files under/usr/lib64/mono/gac
rather than/usr/lib/mono/gac
, which under the 17.1 profile is no longer a symlink. As such recent versions of mono install and check for their gac files under/usr/lib/mono/gac
and miss libraries such as gtk-sharp which install them under lib64. This currently leads to multiple broken packages (include bless which I maintain) that depend upon such libraries, and would be good to get resolved as soon as possible. Please let me know if you need further information or help testing in order to resolve this issue... 5:)