Bug 24131 - Mono.Unix.Native.Syscall ---> System.DllNotFoundException: lib/libMonoPosixHelper.so
Summary: Mono.Unix.Native.Syscall ---> System.DllNotFoundException: lib/libMonoPosixHe...
Status: RESOLVED DUPLICATE of bug 41953
Alias: None
Product: Runtime
Classification: Mono
Component: packaging (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Duncan Mak
URL:
Depends on:
Blocks:
 
Reported: 2014-10-29 10:42 UTC by Eric Roller
Modified: 2016-09-22 10:35 UTC (History)
9 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments

Description Eric Roller 2014-10-29 10:42:07 UTC
When I compile mono 3.10.0 from tarball to a custom location and use the -libdir option to put library files in the "lib64" directory instead of "lib" the configuration for MonoPosixHelper gets hardcoded to the wrong path causing runtime error.

autogen.sh command:

PREFIX=/path/to/mono
./autogen.sh --prefix=$PREFIX --libdir=$PREFIX/lib64


compilation works as expected but inside the file $PREFIX/etc/mono/config I see the hardcoded path for MonoPosixHelper:

	<dllmap dll="MonoPosixHelper" target="/path/to/mono/lib/libMonoPosixHelper.so" os="!windows" />


First of all this is the wrong hardcoded path. The .so file is located in /path/to/mono/lib64 not /path/to/mono/lib. Second, why use a hardcoded path? Nothing else in the config file has a hardcoded path.

The result is that I get the following error when running mono:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: An exception was thrown by the type initializer for Mono.Unix.Native.Syscall ---> System.DllNotFoundException: /path/to/mono/lib/libMonoPosixHelper.so
  at (wrapper managed-to-native) Mono.Unix.Native.Syscall:get_at_fdcwd ()
  at Mono.Unix.Native.Syscall..cctor () [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <filename unknown>:0 


Removing the hardcoded path is a workaround, but can this be fixed for future versions?:

<dllmap dll="MonoPosixHelper" target="libMonoPosixHelper.so" os="!windows" />
Comment 1 Alexander Köplinger [MSFT] 2016-02-23 11:03:15 UTC
This should be fixed with https://github.com/mono/mono/pull/1937 since we lookup the path dynamically at runtime now.
Comment 2 Simon Egli 2016-07-24 17:59:49 UTC
This bug is still here in CentOS 7, Mono 4.4.1. I needed to create a link of libMonoPosixHelper.so from /usr/lib64 to /usr/lib in order to get Mono 4.4.1 working on CentOS 7.
Comment 3 Fábio 2016-07-24 23:06:45 UTC
I use Fedora 22, x86_64.
I needed to create, too, a link of 'libMonoPosixHelper.so' from /usr/lib64 to /usr/lib in order to get Mono 4.4.2 working.
But, I install to using a Package Manager.
Comment 4 Johannes.Fink 2016-07-25 16:29:34 UTC
I use Fedroa 23, x86:64. 
Same problem here after installing Mono 4.4.1.0-0 from Package Manager.
Comment 5 Simon Egli 2016-07-26 00:58:18 UTC
As an alternative to creating a link, one can edit /etc/mono/config, and replace the prefix of libMonoPosixHelper.so (something like "$mono_lib", I forgot) with "/usr/lib64".
Comment 6 Ondra Pelech 2016-07-27 22:07:05 UTC
same here, this problem started after updating to

  mono-complete-4.4.1.0-0.xamarin.1.x86_64`



this solved it:

  sudo ln -s /usr/lib64/libMonoPosixHelper.so /usr/lib/libMonoPosixHelper.so
Comment 7 Alexander Köplinger [MSFT] 2016-09-22 10:35:59 UTC
This the same problem as #41953

*** This bug has been marked as a duplicate of bug 41953 ***

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