search

gentoo / dotnet

[MIRROR] Newer mono, .NET languages, and libraries
https://gitweb.gentoo.org/repo/proj/dotnet.git
79 stars 57 forks source link

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

Closed cyborgyn closed 3 years ago

cyborgyn commented 3 years ago

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

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

cyborgyn commented 3 years ago

Associated issues: https://github.com/gentoo/dotnet/issues/498

cyborgyn commented 3 years ago

Associated pull-request: https://github.com/gentoo/dotnet/pull/502

ArsenShnurkov commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 https://github.com/gentoo/dotnet/pull/502 and https://github.com/gentoo/dotnet/pull/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 commented 3 years ago

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...