Bug 41953 - Wrong directory name used for libraries on Red Hat & SUSE (lib64 -> lib)
Summary: Wrong directory name used for libraries on Red Hat & SUSE (lib64 -> lib)
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: packaging ()
Version: 4.4.0 (C7)
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Jo Shields
URL:
: 24131 37488 42735 42820 ()
Depends on:
Blocks:
 
Reported: 2016-06-17 18:32 UTC by Matt Z
Modified: 2016-10-14 11:20 UTC (History)
13 users (show)

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

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

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 Mikalai Daronin 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