Bug 42735 - Monodevelop does not start due to libMonoPosixHelper.so in different directory in CentOS 7 64-bit
Summary: Monodevelop does not start due to libMonoPosixHelper.so in different director...
Status: RESOLVED DUPLICATE of bug 41953
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Deployment (show other bugs)
Version: 5.10 (C6SR3)
Hardware: PC Linux
: --- normal
Target Milestone: master
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2016-07-22 10:35 UTC by Mark Final
Modified: 2016-09-30 19:11 UTC (History)
6 users (show)

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


Attachments

Description Mark Final 2016-07-22 10:35:57 UTC
Host: CentOS 7 64-bit

[mark@localhost ~]$ more /etc/redhat-release 
CentOS Linux release 7.2.1511 (Core) 

Previously had Mono 4.x installed on there and everything working fine.


Today, updated through yum to get Mono 4.4.1

[mark@localhost ~]$ mono --version
Mono JIT compiler version 4.4.1 (Nightly 4.4.1.0/4747417 Mon Jul 18 18:20:17 UTC 2016)


Monodevelop no longer starts. Capture of stdout/stderr starts with

ERROR [2016-07-22 11:21:48Z]: Failed to redirect output to log file
System.TypeInitializationException: The type initializer for 'Mono.Unix.Native.Syscall' threw an exception. ---> System.DllNotFoundException: /usr/lib/libMonoPosixHelper.so
  at (wrapper managed-to-native) Mono.Unix.Native.Syscall:get_at_fdcwd ()
  at Mono.Unix.Native.Syscall..cctor () <0x407d3ec0 + 0x0002b> in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at MonoDevelop.Core.LoggingService.RedirectOutputToFileUnix () <0x407d31e0 + 0x000eb> in <filename unknown>:0 
  at MonoDevelop.Core.LoggingService.RedirectOutputToLogFile () <0x407d3150 + 0x00023> in <filename unknown>:0 
INFO [2016-07-22 11:21:48Z]: Starting MonoDevelop 5.10
INFO [2016-07-22 11:21:48Z]: Running on Mono 4.4.1 (Nightly 4.4.1.0/4747417 Mon Jul 18 18:20:17 UTC 2016) (64-bit)
INFO [2016-07-22 11:21:48Z]: Operating System: Linux
Linux localhost.localdomain 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
INFO [2016-07-22 11:21:48Z]: Using GTK+ 2.24.28
INFO [2016-07-22 11:21:48Z]: Add-in loaded: MonoDevelop.Core
INFO [2016-07-22 11:21:48Z]: Add-in loaded: MonoDevelop.Ide
WARNING [2016-07-22 11:21:48Z]: No proxy credential provider was found

and repeats with failures to find libMonoPosixHelper.so in /usr/lib.

Searching for this shared object, finds it in a different directory

[mark@localhost ~]$ locate libMonoPosixHelper.so
/usr/lib64/libMonoPosixHelper.so

These are the yum repos I use

[root@localhost mark]# yum repolist
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
 * base: repo.bigstepcloud.com
 * epel: mirror.kinamo.be
 * extras: repo.bigstepcloud.com
 * updates: repo.bigstepcloud.com
repo id                                                                                      repo name                                                                                                       status
base/7/x86_64                                                                                CentOS-7 - Base                                                                                                  9,007
download.mono-project.com_repo_centos_                                                       added from: http://download.mono-project.com/repo/centos/                                                          696
epel/x86_64                                                                                  Extra Packages for Enterprise Linux 7 - x86_64                                                                  10,359
extras/7/x86_64                                                                              CentOS-7 - Extras                                                                                                  356
updates/7/x86_64                                                                             CentOS-7 - Updates                                                                                               2,026
repolist: 22,444



Note that I have the same version of Mono and Monodevelop in Ubuntu 14.04 64-bit, and this works fine. However, libMonoPosixHelper.so on that host is in /usr/lib, as Monodevelop seems to expect.
Comment 1 Alex Willmy 2016-07-22 14:39:57 UTC
I have the same problem on Fedora 23 with Mono 4.4.1 from the Xamarin repo. Everything worked fine before with Mono 4.2.

There is the dllmap entry in /etc/mono/config for MonoPosixHelper:

<dllmap dll="MonoPosixHelper" target="$mono_libdir/libMonoPosixHelper.so" os="!windows" />

Apparently $mono_libdir is substituted with /usr/lib but libMonoPosixHelper.so is installed in /usr/lib64. 

Creating a symlink in /usr/lib works around the problem:

ln -s /usr/lib64/libMonoPosixHelper.so /usr/lib/libMonoPosixHelper.so
Comment 2 secondary 2016-07-25 00:06:45 UTC
Same problem on Fedora 24 x86_64 (kernel 4.6.4-301) with mono-core-4.4.1.0-0.xamarin.1.x86_64. The official fedora report regarding this issue is at: https://bugzilla.redhat.com/show_bug.cgi?id=1313021.

This is a strange issue to debug - my guess is the build system (Azure0718021751.xamjenkins-builder.b8.internal.cloudapp.net) has different defaults than most CentOS/Fedora derivates:

The problem has two possibles causes

1. (unlikely) The build system's %configure rpm macro expands --libdir to /usr/lib. This becomes assembliesdir, then -DMONO_ASSEMBLIES, via mono/metadata/Makefile.am and that macro is picked up in mono/metadata/mono-config-dirs.c:mono_config_get_assemblies_dir, which defines the default (non-autodetected) assemblies directory. Since this bug was originally reported against CentOS, this is unlikely.

2. (likely) In assembly.c, mono_assemblies_init -> mono_set_rootdir (autodetect codepath) -> set_dirs (linux/posix only), which hardcodes the library suffix as 'lib'.
Comment 3 secondary 2016-07-25 00:30:56 UTC
Actually, on non-windows platforms, mono/metadata/Makefile.am hardcodes the library suffix. The above comment (1) only assigns assembliesdir = ${libdir} when crosscompiling under windows. Otherwise, ie under linux:

    assembliesdir = ${exec_prefix}/lib

So both have to be fixed. Since the entire point of the code is to detect the correct directory during runtime, it doesn't make sense to the library directory from autoconf's ${libdir} into a (yet another) C macro (and then provide a mono/metadata/mono-config-dirs.c:mono_config_get_library_dir() function). Unfortunately, it isn't enough to detect the x86/x86_64 because older pre-multiarch x86_64 platforms use /lib/ instead of /lib64/ (iirc). So ...
Comment 4 secondary 2016-07-25 00:32:35 UTC
* ... doesn't make sense to hardcode the library directory ...
Comment 5 secondary 2016-07-25 00:33:16 UTC
Maybe just revert commit 6b5f6dd0434b66062110cf764688975ecfed646f#diff-0faf0a2be5d06f6c67917e0592b5619b ?

* https://github.com/mono/mono/commit/6b5f6dd0434b66062110cf764688975ecfed646f#diff-0faf0a2be5d06f6c67917e0592b5619b
Comment 6 Rick Tillery 2016-07-25 18:42:05 UTC
Note that monodevlop is not the only mono/.Net app that fails due to this bug.  We have multiple GUI-based apps that also fail.  Non-GUI (i.e. command line) apps work as with previous versions.
Comment 7 Jo Shields 2016-07-28 13:34:31 UTC

*** 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.