https://bugzilla.novell.com/show_bug.cgi?id=349195
User [EMAIL PROTECTED] added comment https://bugzilla.novell.com/show_bug.cgi?id=349195#c7 --- Comment #7 from Andreas Färber <[EMAIL PROTECTED]> 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. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
