mono-shlib-cop(1)

💖 mono-shlib-cop — shared library usage checker 💖

okay bestie, gather round, because today we're talking about mono-shlib-cop, a lil detective for your managed assemblies. it's from the General Commands Manual and it is genuinely so useful, no cap. ✨

---

🌸 NAME 🌸

mono-shlib-cop — Shared Library Usage Checker 👑

---

🎀 SYNOPSIS 🎀

mono-shlib-cop [OPTIONS]* [ASSEMBLY-FILE-NAME]*

so like. options first, then as many assembly filenames as your heart desires. simple. iconic. 💅

---

✨ OPTIONS ✨

• -p, --prefixes=PREFIX — the Mono installation prefixes, bestie. this is how it finds $prefix/etc/mono/config. the default is based upon where mscorlib.dll lives, and honestly? it's normally correct. 🫶

---

🦋 DESCRIPTION 🦋

mono-shlib-cop is that girl. she inspects a managed assembly and looks for erroneous or suspecious usage of shared libraries. yes, "suspecious", the manpage said it, i'm keeping it, periodt.

she takes one or more assembly filenames and inspects each assembly you specified. every single one. she's thorough like that. 💅

😭 the errors she checks for

• does the shared library even exist?
• does the requested symbol exist within the shared library?

🙈 the warnings she checks for

• is the target shared library a versioned library? (this one's only relevant on Unix systems, not Mac OS X or Windows, iykyk)

---

okay so here's the tea. generally, only versioned libraries like libc.so.6 are actually present on the user's machine, and any attempt to load libc.so is gonna give you a System.DllNotFoundException. rude. 💀

there are three solutions to this, and i'm listing all three because that's the vibe:

1. require that the user install any -devel packages which provide the unversioned library. this usually means the user has to install a large number of additional packages, which complicates the installation process. it's giving "why is this so extra".
2. use a fully versioned name in your DllImport statements. this requires editing your source code and recompiling whenever you need to target a different version of the shared library. exhausting, honestly.
3. provide an assembly.config file which contains <dllmap/> elements to remap the shared library name used by your assembly to the actual versioned shared library present on the users system. Mono provides a number of pre-existing <dllmap/> entries, including ones for libc.so and libX11.so. this one's the main character move. 👑

---

⭐ EXAMPLE ⭐

the following code contains examples of the above errors and warnings:

using System.Runtime.InteropServices; // for DllImport
class Demo {
     [DllImport ("bad-library-name")]
     private static extern void BadLibraryName ();

     [DllImport ("libc.so")]
     private static extern void BadSymbolName ();

     [DllImport ("libcap.so")]
     private static extern int cap_clear (IntPtr cap_p);
}

💀 Bad library name

assuming that the library bad-library-name doesn't exist on your machine, Demo.BadLibraryName will generate an error, because it requires a shared library which cannot be loaded. this may be ignorable; see BUGS. ngl that "may be ignorable" is doing a lot of heavy lifting.

💀 Bad symbol name

Demo.BadSymbolName will generate an error, because libc.so (remapped to libc.so.6 by mono's $prefix/etc/mono/config file) doesn't contain the function BadSymbolName. like, she looked. it's not there. 😭

⚠️ Unversioned library dependency

assuming you have the file libcap.so, Demo.cap_clear will generate a warning because, while libcap.so could be loaded, libcap.so might not exist on the users machine (on FC2, /lib/libcap.so is provided by libcap-devel, and you can't assume that end users will have any -devel packages installed). yeah. can't assume that. 🫠

---

🧚 FIXING CODE 🧚

the fix depends on the warning or error, bestie:

Bad library names

use a valid library name in the DllImport attribute, or provide a <dllmap/> entry to map your existing library name to a valid library name.

Bad symbol names

reference a symbol that actually exists in the target library. that's it. that's the fix. 💅

Unversioned library dependency

provide a <dllmap/> entry to reference a properly versioned library, or ignore the warning (see BUGS).

---

🌈 DLLMAP ENTRIES 🌈

Mono looks for an ASSEMBLY-NAME mapping information. for example, with mcs.exe, Mono would read mcs.exe.config, and for Mono.Posix.dll, Mono would read Mono.Posix.dll.config. so like, the pattern is right there. 👀

the .config file is an XML document containing a top-level <configuration/> section with nested <dllmap/> entries, which contains dll and target attributes. the dll attribute should contain the same string used in your DllImport attribute value, and the target attribute specifies which shared library mono should actually load at runtime. slay.

a sample .config file is:

<configuration>
     <dllmap dll="gtkembedmoz" target="libgtkembedmoz.so" />
</configuration>

---

💀 BUGS 💀

okay this section is the "read it or regret it" section. buckle up.

• only DllImport entries are checked; the surrounding IL is ignored. consequently, if a runtime check is performed to choose which shared library to invoke, an error will be reported even though the specified library is never used. consider this code:

using System.Runtime.InteropServices; // for DllImport
class Beep {
     [DllImport ("kernel32.dll")]
     private static extern int Beep (int dwFreq, int dwDuration);

     [DllImport ("libcurses.so")]
     private static extern int beep ();

     public static void Beep ()
     {
          if (System.IO.Path.DirectorySeparatorChar == '\\') {
               Beep (750, 300);
          }
          else {
               beep ();
          }
     }
}

if mono-shlib-cop is run on this assembly, an error will be reported for using kernel32.dll, even though kernel32.dll will never be used on Unix platforms. the disrespect. 😭

• mono-shlib-cop currently only examines the shared library file extension to determine if a warning should be generated. a .so extension will always generate a warning, even if the .so is not a symlink, isn't provided in a -devel package, and there is no versioned shared library (possible examples including /usr/lib/libtcl8.4.so, /usr/lib/libubsec.so, etc.).

consequently, warnings for any such libraries are useless, and incorrect.

Windows and Mac OS X will never generate warnings, as these platforms use different shared library extensions.

---

💜 MAILING LISTS 💜

visit http://lists.ximian.com/mailman/listinfo/mono-devel-list for details. go, be social, join the list, it's giving community. 🫶

---

🌐 WEB SITE 🌐

visit http://www.mono-project.com for details. ✨

---

and that's the whole page, bestie!! this one's from the General Commands Manual, mono-shlib-cop(1), and yeah — same title, same page, just with way more ✨vibe✨. go check your shared libraries. they might be lying to you. 💅🎀🦋

mono-shlib-cop(1) — byeeee 🫶