current content of '/usr/bin/gapi2-parser': #!/bin/sh export PATH=/usr/lib/gtk-sharp-2.0:$PATH mono /usr/lib/gtk-sharp-2.0/gapi-parser.exe "$@" 'gapi-parser.exe' is installed at '/usr/lib64/gtk-sharp-2.0'. On 17.0 profiles it doesn't matter because '/usr/lib' is a link to '/usr/lib64' On 17.1 profile all builds which using this scripts are broken. see attachment as example.
Created attachment 516760 [details] build.log
same at '/usr/bin/gapi2-fixup'
This also means that all the gac files are installed under /usr/lib64/mono/gac, which the mono compiler then doesn't check (since it installs them its own under /usr/lib/mono/gac). This causes packages (such as dev-util/bless) not to work because of the following error: ``` Unhandled Exception: System.TypeLoadException: Could not load type of field 'BlessMain:DataViewBox' (0) due to: Could not load file or assembly 'gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f' or one of its dependencies. assembly:gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f type:<unknown type> member:(null) signature:<none> [ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could not load type of field 'BlessMain:DataViewBox' (0) due to: Could not load file or assembly 'gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f' or one of its dependencies. assembly:gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f type:<unknown type> member:(null) signature:<none> ``` This can be resolved by commenting out the `dotnet_multi_comply` line of the gtk-sharp ebuild, and it installs and bless runs correctly. It's not clear how best to correct this, but I guess ebuilds should install their gac files into the same directory as the installed version of mono's gac? I'm not sure how to determine that, but otherwise multilib is going to prevent most mono libraries from being usable...
Any progress on this? It's still an issue.
Is this a dupe of bug 664396? It should also block the tracker for 17.1 profile issues: bug 506276.
*** Bug 664396 has been marked as a duplicate of this bug. ***
*** Bug 710016 has been marked as a duplicate of this bug. ***
Over a year, and no action. I wonder if the solution here (at least short term) is not to drop dotnet_mutlilib-comply, but to edit the three scripts installed in /usr/bin/gapi2-(codegen|fixup|parser) to point the the exe files where they actually get installed. The more I look at this issue, the more I wonder if dotnet related packages may need to install some stuff to /usr/lib and some to /usr/lib64 (such as any .so files).
Just for those interested (since we're *still* running into this), there was a reply in 2019 on the gentoo dotnet repo. https://github.com/gentoo/dotnet/issues/398 It doesn't provide much hope for the future and references another bug that offers the workaround of symlinking /usr/lib64/gac to /usr/lib/gac, which doesn't seem ideal, but also seems little better than rewriting the gtk-sharp ebuild not to use dotnet_multilib-comply (available in my overlay) which also resolves the issue. The other bug also features a comment that suggests little hope for a long term fix: https://github.com/gentoo/dotnet/issues/378#issuecomment-516065718
*** Bug 733166 has been marked as a duplicate of this bug. ***
Created attachment 653408 [details] modified ebuild for gtk-sharp-2.12.45 I made several of the comments on that issue. I just get the feeling that there is minimal support for dotnet in Gentoo, and in particular, nobody wants to take on the large project of deciding which mono/dotnet stuff belongs where, and then going through all the packages to adjust accordingly. In this particular case, I've created (attached) a modified ebuild, which just sed's the three binaries (shell scripts) to point to the associated .exe files in lib64 instead of lib, as that is where they get installed on my system. I suppose having them point to $libdir would be better just in case you're on a 32 bit system. The patch referred to in the new PATCHES is not new, and already exists in the current files folder.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ab7fb81441611777b70102b20272c068cb2b9669 commit ab7fb81441611777b70102b20272c068cb2b9669 Author: Jakov Smolic <jakov.smolic@sartura.hr> AuthorDate: 2021-05-23 12:35:43 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2021-05-23 12:35:43 +0000 dev-dotnet/gtk-sharp: Remove last-rited pkg Closes: https://bugs.gentoo.org/769041 Closes: https://bugs.gentoo.org/509398 Closes: https://bugs.gentoo.org/645786 Closes: https://bugs.gentoo.org/509396 Closes: https://bugs.gentoo.org/643048 Closes: https://bugs.gentoo.org/573520 Closes: https://bugs.gentoo.org/659422 Signed-off-by: Jakov Smolic <jakov.smolic@sartura.hr> Signed-off-by: David Seifert <soap@gentoo.org> dev-dotnet/gtk-sharp/Manifest | 1 - .../gtk-sharp-2.12.21-mono-ambiguous-range.patch | 15 ------ dev-dotnet/gtk-sharp/gtk-sharp-2.12.21.ebuild | 62 ---------------------- dev-dotnet/gtk-sharp/metadata.xml | 5 -- profiles/package.mask | 8 --- 5 files changed, 91 deletions(-)
