[Mono-dev] The Bleeding Edge of SuSE is not Mono-friendly

[Jonathan Pryor]

On Tue, 2005-08-23 at 08:32 -0400, Steven T. Hatton wrote:
> For example, it's not clear how to 
> determine or control which libraries and assemblies are visible, or being 
> used by the currently running Mono or MCS.  

Two flags control that: -r and -pkg.

By default, only mscorlib.dll and System.dll are referenced by default.
(Microsoft CSC.EXE includes more by default.)

Additional assemblies can be referenced with -r:Assembly.dll, which will
find Assembly.dll in $prefix/lib/mono/1.0 ($prefix/lib/mono/2.0 for
gmcs) and any directories specified by -L.  Thus -r:System.Data.dll will
work, but -r:Foo.dll will fail (unless you also use -L Path/To/Foo.dll).

Using -pkg is a shorthand for -r; -pkg:PACKAGE is equivalent to saying
`pkg-config --libs PACKAGE`, which should return a list of -r flags.
For example, `pkg-config --libs gtk-sharp` returns:

        -r:/usr/lib/mono/gtk-sharp/glib-sharp.dll
        -r:/usr/lib/mono/gtk-sharp/pango-sharp.dll
        -r:/usr/lib/mono/gtk-sharp/atk-sharp.dll
        -r:/usr/lib/mono/gtk-sharp/gdk-sharp.dll
        -r:/usr/lib/mono/gtk-sharp/gtk-sharp.dll

> I found the comments about needed to install development packages if any of 
> the build options were reported as "no" to be a bit nebulous.  A pointer 
> suggesting the user have a look at the configure.in (or configure.in.in) as 
> well as the bootstrap scripts might be helpful as part of the ./autogen.sh 
> or ./bootstrap summary.

It's not entirely nebulous, as C glue code is necessary to allow Gtk# to
access all of the C libraries.  Since you need to build C libraries, you
need the C development packages to build them.

> Another point of confusion is how the pkg-config system actually works.  I 
> understand there are various directories called <path-to>/pkgconfig, and an 
> associated PKG_CONFIG_PATH environment variable.  What is not clear is how 
> the pkg-config system relates to the resolution of resource location during 
> various parts of the build process.  For example, if I happen to have 
> multiple versions of a particular package, how does the build system chose 
> one over the other?  Is the pkg-config system involved?

pkg-config is involved.  The assembly resolution process is described
above.  What happens if the same assembly name is present in multiple
directories (via -L)?  The first one found is used (IIRC).

How do you handle different versions?  By placing them into different
directories and/or giving them different pkg-config files.  For example,
Gtk# 2.0 is gtk-sharp-2.0 while Gtk# 1.0 is gtk-sharp.  This allows
pkg-config to return a different set of -r: flags, depending on which
version you want to use.

For anything that doesn't provide pkg-config files, you specify the
version you want to run against by using the -L flag (and making sure
that the directory you provide is the version you want).

It's important to keep in mind that at no point does mcs lookup
assemblies in the GAC for assembly resolution purposes.  Thus there is
no way to have multiple different versions of the same assembly --
you're limited by the filesystem to having one unique path name per
assembly, thus allowing you to control which version you reference by
setting up your directories intelligently.

 - Jon