Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 645786 - dev-dotnet/gtk-sharp-2.12.21 - /usr/bin/gapi2-parser outputs wrong library path
Summary: dev-dotnet/gtk-sharp-2.12.21 - /usr/bin/gapi2-parser outputs wrong library path
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: dotnet
URL: https://github.com/gentoo/dotnet/issu...
Whiteboard:
Keywords:
: 664396 710016 733166 (view as bug list)
Depends on:
Blocks: no-symlink-lib
  Show dependency tree
 
Reported: 2018-01-26 06:54 UTC by Mirko Guenther
Modified: 2020-08-06 18:51 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log,23.85 KB, text/plain)
2018-01-26 06:54 UTC, Mirko Guenther
Details
modified ebuild for gtk-sharp-2.12.45 (gtk-sharp-2.12.45-r1.ebuild,1.28 KB, text/plain)
2020-08-06 18:51 UTC, Jack
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mirko Guenther 2018-01-26 06:54:15 UTC
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.
Comment 1 Mirko Guenther 2018-01-26 06:54:43 UTC
Created attachment 516760 [details]
build.log
Comment 2 Mirko Guenther 2018-01-26 07:20:11 UTC
same at '/usr/bin/gapi2-fixup'
Comment 3 Mike Auty gentoo-dev 2018-07-08 17:02:19 UTC
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...
Comment 4 Mike Auty gentoo-dev 2018-10-25 23:57:19 UTC
Any progress on this?  It's still an issue.
Comment 5 Jack 2019-06-08 21:31:22 UTC
Is this a dupe of bug 664396?  It should also block the tracker for 17.1 profile issues: bug 506276.
Comment 6 Mike Auty gentoo-dev 2020-02-21 23:21:29 UTC
*** Bug 664396 has been marked as a duplicate of this bug. ***
Comment 7 Mike Auty gentoo-dev 2020-02-21 23:25:54 UTC
*** Bug 710016 has been marked as a duplicate of this bug. ***
Comment 8 Jack 2020-07-26 21:24:28 UTC
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).
Comment 9 Mike Auty gentoo-dev 2020-08-05 08:57:18 UTC
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
Comment 10 Mike Auty gentoo-dev 2020-08-05 09:06:25 UTC
*** Bug 733166 has been marked as a duplicate of this bug. ***
Comment 11 Jack 2020-08-06 18:51:30 UTC
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.