[Mono-bugs] [Bug 349195] Embedding Mono broken on OS X: problematic references

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=349195

User andreas.faerber at web.de added comment
https://bugzilla.novell.com/show_bug.cgi?id=349195#c7





--- Comment #7 from Andreas Färber <andreas.faerber at web.de>  2008-01-23 07:27:08 MST ---
In my opinion, you should be using full (absolute) paths (the default when
compiling):

Mono until 1.2.5 always installed to /Library/Frameworks/Mono.framework and
used absolute paths. That way you were able to link your native executable to
the /Library/Frameworks/Mono.framework, and direct your users to download and
install the official Mono package (as you would on Windows for the .NET
framework or Mono).

What the reporter of bug #323882 said is that using absolute pathnames does not
allow taking the installed Mono.framework as-is and copying it into an
application bundle as My.app/Contents/Frameworks/Mono.framework. That is true.
For this to work correctly, someone - either them on their copy or you on the
original - has to change the path as you describe above in comment #6.

It's an exclusive decision, I see no way to satisfy both demands unless you
were able to supply two alternative downloads.

With you installing the complete framework to the system location I would
welcome if this stays usable by applications as before:
* this keeps application bundles small and saves bandwidth
* it spares developers the need to redistribute GPL source code
* it lets users apply Mono updates themselves
If a developer cares to strip unused parts of the Mono.framework (such as mcs)
to reduce size and these issues, they can just as well run the command to
change the absolute path into a relative path:
install_name_tool -change /Library/... @executable_path/... .../libmono.dylib
Otherwise, when using relative paths as right now, you are forcing people to
ship Mono inside their application bundle or, as a workaround, to emulate this
via symlink to the system-installed framework, with the latter being a little
fragile for distribution.

The golden solution would be to have the standard downloadable Mono.framework
use full absolute paths and to supply a separate stripped-down Mono.framework
with relative path specifically for embedding.
(But then again, we're not doing this for any other platform, and neither is
Mono a real framework nor do its headers follow the conventions for a
framework*, so a better long-term solution would be to integrate a real Mach-O
framework (possibly derived from Dumbarton) into Mono.framework, providing the
semantics expected by Mac developers.)

* For a framework named Mono.framework, the include path <Mono/foo.h> would
refer to Mono.framework/Headers/foo.h while Mono uses <mono/bar.h> to refer to
Mono.framework/Headers/mono-1.0/mono/bar.h, requiring include/mono-1.0,
include/glib-2.0 and lib/glib-2.0/include to be added to the search path in
addition to adding the framework dependency, and in place of #include
<Mono/Mono.h> one needs to use <mono/jit/jit.h> or others. On the Mac, Mono is
currently simply a dynamic library, not a framework and can't be fully used as
such.


-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.