dotnet/eclass/gac.eclass egacinstall installes to the wrong directory on AMD64

[cyborgyn]

Either mono GAC configuration is wrong, or the egacinstall method on AMD64:

• Mono has GAC pointing to /usr/lib/mono/gac, instead of /usr/lib64/mono/gac
• egacinstall method installs assemblies into /usr/lib64/mono/gac

This prevents building some packages that depend on each other, without manually moving around those DLLs.

[cyborgyn]

Associated issues:
#498

[cyborgyn]

Associated pull-request:
#502

[ArsenShnurkov]

The decision to split GAC into 3 parts was made in purpose, it's not a mistake. But you can continue your only way. And there are many more such decisions (like unbundling mono, breaking the cycle with mono and libgdiplus and others). That's why created my own overlay.

The correct solution is to patch (extend) mono to make it use proper architecture (x86, x64 or x32)

And you don't need to build msbuild separately, because there is a version of msbuild which is bundled into mono itself.

[cyborgyn]

The decision to split GAC into 3 parts was made in purpose, it's not a mistake. But you can continue your only way. And there are many more such decisions (like unbundling mono, breaking the cycle with mono and libgdiplus and others). That's why created my own overlay.

The correct solution is to patch (extend) mono to make it use proper architecture (x86, x64 or x32)

And you don't need to build msbuild separately, because there is a version of msbuild which is bundled into mono itself.

I mostly agree, but currently this repo seems to be a bit broken. Actually, if that's the decision about the GAC split, than it's wrong. It would break again, on ARM, where there are also 32 & 64 bit API versions available. Btw, this is only desired in case native interop is involved in the DLL in question, but in this case an other one would still needed: CPU independent GAC, wouldn't it? Then in which lib folder to put it, just like in the case of x32?

But right now, it's not really interesting, as it should be fixed up-streams, in mono. Until that happens (who knows when will be an agreement on that), would be nice to be able to use gentoo build system as intuitively, as with other packages. So, consider my proposed patch as a temporary solution, until a proper fix appears. Does it make sense? Or are those things already solved on your overlay? (which one is it?)

[ArsenShnurkov]

I never received the status of gentoo developer, because no mentor accepted me (because of bad character). So I don't have commit rights in dotnet repository, and can't do anything with your PRs.
Probably you need to talk to sam in IRC, and he will advise you to create bug in gentoo bugtracker (bugs.gentoo.org) about getting the access to the dotnet repository.

[ngg]

Hi! I can help you merge PRs to this repo if you'd like.
I'm not in the github org, so I don't receive notifications about issues or PRs, I cannot close anything, but I have push access, so I can merge commits. (And close issues/PRs via commit messages)
Are #502 and #503 ready to merge? I don't use these packages, so I cannot tell, but I'll merge these if you agree that they're ready and work.

[cyborgyn]

Hi! I can help you merge PRs to this repo if you'd like.
I'm not in the github org, so I don't receive notifications about issues or PRs, I cannot close anything, but I have push access, so I can merge commits. (And close issues/PRs via commit messages)
Are #502 and #503 ready to merge? I don't use these packages, so I cannot tell, but I'll merge these if you agree that they're ready and work.

Yes, for me they work, tested on a reverted virtual machine, as new builds. Not tested with a prefix build though...