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
OK, some more Qyoto fun. :-( Ben (MathStuf), I think this one is for you too. :-) Does Mono always dlopen the unversioned so?
I'm not a C# guru. Is all that's needed a Requires: on Mono or is something more specific necessary?
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.
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.
(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.
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
I see this fixed in kdebindings-4.3.5-1 at least, closing.