Bug 41953

Summary: Wrong directory name used for libraries on Red Hat & SUSE (lib64 -> lib)
Product: [Mono] Runtime Reporter: Matt Z <matt.zinkevicius>
Component: packagingAssignee: Jo Shields <jo.shields>
Status: RESOLVED FIXED    
Severity: normal CC: alkpli, bernhard.urban, eroller, lassana.nd, markfinal, mono-bugs+mono, mono-bugs+runtime, rtillerywork, secondary, venkatrangang, vince, vp, yugiohjcj
Priority: ---    
Version: 4.4.0 (C7)   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Tags: Is this bug a regression?: ---
Last known good build:

Description Matt Z 2016-06-17 18:32:49 UTC
Mono 4.4 now appears to hardcode the 32-bit standard path "/usr/lib" prefix when trying to resolve Mono.Posix library:

[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: The type initializer for 'Mono.Unix.UnixSignal' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Mono.Unix.Native.Stdlib' threw an exception. ---> System.DllNotFoundException: /usr/lib/libMonoPosixHelper.so

This did not occur with Mono 2.2.3.

I was able to find libMonoPosixHelper.so under /usr/lib64/MonoPosixHelper.so. After modifying the config file under /etc/mono to point to this location, everything ran correctly.

It looks like the Fedora package maintainers have already included a patch in their mono package to address this:
http://pkgs.fedoraproject.org/cgit/rpms/mono.git/commit/?id=cc7b8dcb9f02810b0322b24e8ac63581d9be8146
Comment 1 Matt Z 2016-06-17 18:45:29 UTC
Looks like this is the commit that broke it:

https://github.com/mono/mono/commit/6b5f6dd0434b66062110cf764688975ecfed646f
Comment 2 Alexander Köplinger [MSFT] 2016-06-23 00:29:14 UTC
Assigning to Jo, as he said on Gitter this is a problem with the RPM packages.
Comment 3 Matt Z 2016-06-23 01:53:57 UTC
I disagree this is strictly a packaging issue, as when the code commit I mentioned above is reverted then the lib path is once again configured correctly.
Comment 4 Alexander Köplinger [MSFT] 2016-06-23 09:55:41 UTC
I was just going by Jo's comment on Gitter, there may be more to it of course.

Bernhard: since you made the commit, any ideas/comments?
Comment 5 Bernhard Urban 2016-06-27 17:22:21 UTC
There's a fix around this code, https://github.com/mono/mono/pull/2754

@Matt: With those patches, does it fix your issue?
Comment 6 Jo Shields 2016-06-28 09:10:10 UTC
(In reply to Alexander Köplinger from comment #2)
> Assigning to Jo, as he said on Gitter this is a problem with the RPM
> packages.

RPM distros use /usr/lib64, Debian derivatives don't, hence the comment
Comment 7 Matt Z 2016-07-18 22:33:32 UTC
@Bernhard,

Thanks for the pointer, but it appears that PR is already applied in Mono 4.4.0 (See https://github.com/mono/mono/commits/mono-4.4.0.182/mono/metadata/mono-config.c), and so this doesn't resolve the issue.
Comment 8 Jo Shields 2016-07-28 13:34:09 UTC
*** Bug 42820 has been marked as a duplicate of this bug. ***
Comment 9 Jo Shields 2016-07-28 13:34:31 UTC
*** Bug 42735 has been marked as a duplicate of this bug. ***
Comment 10 secondary 2016-07-31 16:34:36 UTC
This is actually two problems:

1.  A runtime problem: mono/metadata/assembly.c:set_dirs:644

    lib = g_build_filename (base, "lib", NULL);

   No simple solution. This function attempts runtime detection, so replacing the "lib" string with a c macro expanding to a configure-time value of autoconf's ${libdir} defeats the purpose. Furthermore, debian derivatives use a multiarch layout (ie, /usr/lib/x86_64-linux-gnu) complicating runtime detection as well as support for pre-multiarch debian systems. And iirc early RPM-based x86_64 systems still used /usr/lib rather than /usr/lib64. So this is just a can of worms, and I recommend to revert this (and related) commit.


2.  A compiletime problem: mono/metadata/Makefile.am:23

    assembliesdir = $(exec_prefix)/lib

    Simple to fix, just use $(libdir)


See https://bugzilla.xamarin.com/show_bug.cgi?id=42735 for more information.
Comment 11 Jo Shields 2016-08-30 08:32:38 UTC
*** Bug 37488 has been marked as a duplicate of this bug. ***
Comment 12 Jo Shields 2016-09-19 13:16:58 UTC
(In reply to secondary from comment #10)
> This is actually two problems:
> 
> 1.  A runtime problem: mono/metadata/assembly.c:set_dirs:644
> 
>     lib = g_build_filename (base, "lib", NULL);
> 
>    No simple solution. This function attempts runtime detection, so
> replacing the "lib" string with a c macro expanding to a configure-time
> value of autoconf's ${libdir} defeats the purpose. Furthermore, debian
> derivatives use a multiarch layout (ie, /usr/lib/x86_64-linux-gnu)
> complicating runtime detection as well as support for pre-multiarch debian
> systems. And iirc early RPM-based x86_64 systems still used /usr/lib rather
> than /usr/lib64. So this is just a can of worms, and I recommend to revert
> this (and related) commit.
> 
> 
> 2.  A compiletime problem: mono/metadata/Makefile.am:23
> 
>     assembliesdir = $(exec_prefix)/lib
> 
>     Simple to fix, just use $(libdir)
> 
> 
> See https://bugzilla.xamarin.com/show_bug.cgi?id=42735 for more information.


The commits in question are around a decade old - and the breakage was introduced in 4.4?

This sounds like a job for bisect, to me.
Comment 13 Jo Shields 2016-09-20 18:43:30 UTC
I have a PR open for a fix for the lib64 and lib/x86_64-linux-gnu cases. https://github.com/mono/mono/pull/3591
Comment 14 Alexander Köplinger [MSFT] 2016-09-22 10:35:59 UTC
*** Bug 24131 has been marked as a duplicate of this bug. ***
Comment 15 Mark Final 2016-09-30 13:20:18 UTC
Just say to, I upgraded my CentOS 7 box from Mono 4.4 to 4.6.1 today. MonoDevelop now opens successfully, and /usr/lib64/libMonoPosixHelper.so now exists.

I see the PR is still open though?
Comment 16 Jo Shields 2016-09-30 13:43:44 UTC
(In reply to Mark Final from comment #15)
> I see the PR is still open though?

I apply extra fixes to the Linux packages which aren't in mainline Mono, as needed. This was essential IMHO.
Comment 17 Nikolai Doronin 2016-09-30 19:10:31 UTC
Just updated mono to 4.6.0 on my openSUSE machine - everything seems to be okay.
Comment 18 Jo Shields 2016-10-14 11:20:38 UTC
The fix for this has been merged as 41a1c19ec88a59eb46fdea5e14e9edf4cb181dcb

A workaround (not the above fix) is part of mono-project.com RPMs