Bug 551860 - Qyoto.Qt seems to require libqyotoshared.so
Summary: Qyoto.Qt seems to require libqyotoshared.so
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kdebindings
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Ben Boeckel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 550601
TreeView+ depends on / blocked
 
Reported: 2010-01-02 16:14 UTC by Mamoru TASAKA
Modified: 2010-10-05 19:57 UTC (History)
9 users (show)

Fixed In Version: 4.3.5-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-10-05 19:57:14 UTC


Attachments (Terms of Use)
strace log for themonospot-qt (207.74 KB, text/plain)
2010-01-02 16:14 UTC, Mamoru TASAKA
no flags Details

Description Mamoru TASAKA 2010-01-02 16:14:17 UTC
Created attachment 381296 [details]
strace log for themonospot-qt

Description of problem:
(Currently I am trying to review themonospot-gui-qt package:
 bug 550601)

$ themonospot-qt 

Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for Qyoto.Qt ---> System.TypeInitializationException: An exception was thrown by the type initializer for Qyoto.SmokeInvocation ---> System.DllNotFoundException: qyotoshared
  at (wrapper managed-to-native) Qyoto.SmokeMarshallers:InstallIntPtrToCharStarStar (Qyoto.SmokeMarshallers/GetIntPtr)
  at Qyoto.SmokeMarshallers.SetUp () [0x00000] in <filename unknown>:0 
  at Qyoto.SmokeInvocation.InitRuntime () [0x00000] in <filename unknown>:0 
  at Qyoto.SmokeInvocation..cctor () [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at Qyoto.Qt..cctor () [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at ThemonospotGuiQt.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0 

It seems that Qyoto.Qt requires libqyotoshared.so (as well as
libqyotoshared.so.X) (Note that I don't know qyoto well).
With creating libqyotoshared.so symlink, themonospot-qt surely
launches

Version-Release number of selected component (if applicable):
qyoto-4.3.85-4.fc13.i686
themonospot-gui-qt-0.1.3-4.fc.i686 (under review on bug 550601)


How reproducible:
100%

Steps to Reproduce:
1. $ themonospot-qt
2.
3.
  
Actual results:
strace log attached

Expected results:
themonospot-qt should launch

Comment 1 Kevin Kofler 2010-01-05 13:11:10 UTC
OK, some more Qyoto fun. :-( Ben (MathStuf), I think this one is for you too. :-)

Does Mono always dlopen the unversioned so?

Comment 2 Ben Boeckel 2010-01-10 02:31:58 UTC
I'm not a C# guru. Is all that's needed a Requires: on Mono or is something more specific necessary?

Comment 3 Kevin Kofler 2010-01-11 06:46:47 UTC
This one is not just a missing Requires, the problem is more subtle: libqyotoshared.so is a devel symlink, but it seems to be needed at runtime. Somehow the C# code in Smoke or Qyoto is looking only for an unversioned library. A workaround would be to put the symlink into the main package.

Comment 4 Mamoru TASAKA 2010-01-12 14:24:18 UTC
I don't know about mono either, however I also think that
currently simplying moving %_libdir/libqyotoshared.so from -devel
to main package is better as a workaround.

Comment 5 Christian Krause 2010-03-06 01:56:50 UTC
(In reply to comment #3)
> This one is not just a missing Requires, the problem is more subtle:
> libqyotoshared.so is a devel symlink, but it seems to be needed at runtime.
> Somehow the C# code in Smoke or Qyoto is looking only for an unversioned
> library. A workaround would be to put the symlink into the main package.    

Yes, indeed this is just a workaround. ;-)

Mono handles it the following way:

If a mono assembly should call a function of an external (native) library, it will be referenced in the the c# source using the [DllImport("foo")] directive. Without any further hints the mono runtime environment will search for various variants of "<prefix>foo<suffix>" (especially it will also search for /usr/lib/libfoo.so).

This is exact the behaviour which was observered here.

This can be fixed in various ways:
1) use the full versioned library name in the DllImport (not very flexible, especially if the mono assembly should run unmodified on various platforms)

2) use *.config files:
These files are named like /path/mono-assembly.{exe,dll}.config and help the mono runtime to find the correct library. 

qyoto seems to be shipped with a .config file:
cat /usr/lib/mono/gac/qt-dotnet/4.5.0.0__194a23ba31c08164/qt-dotnet.dll.config
<configuration><dllmap dll="libqyotoshared" target="libqyotoshared.so.1"/></configuration>

The problem is, that upstream has recently changed their sources and started to use something like this:
./qyoto/src/SmokeMarshallers.cs:        [DllImport("qyotoshared", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]

This means, that the dllmap in the .config file does not apply anymore: "qyotoshared" as used in DllImport is not that same as "libqyotoshared" in the .config file. And if the mono runtime does not get a hint, it will solely use the algorithm described above. Since the following name will be tried as well: /usr/lib/lib<name_from_dllimport>.so in will find the unversioned libqyotoshared.so link. ;-)

I'm not sure whether upstream is aware of this, the described problem is still in their SVN.

This problem can be easily solved by changing /usr/lib/mono/gac/qt-dotnet/4.5.0.0__194a23ba31c08164/qt-dotnet.dll.config to something like this (untested):

<configuration><dllmap dll="qyotoshared" target="libqyotoshared.so.1"/></configuration>

HTH.

Comment 6 Bug Zapper 2010-03-15 13:44:45 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 7 Rex Dieter 2010-10-05 19:57:14 UTC
I see this fixed in kdebindings-4.3.5-1 at least, closing.


Note You need to log in before you can comment on or make changes to this bug.