[Mono-osx] How to add mono/dumbarton as a bundled framework

Eoin Norris e.norris at mac.com
Mon Oct 30 11:36:39 EST 2006

TO continue: ( This is more of a general Mono question now)

Here is the backtrace on exit() -- clearly the "/Library/Frameworks/ 
Mono.framework/Versions/" is picked  
up from somewhere.....

#0  0x90010564 in exit ()
#1  0x00298da7 in mono_init_internal (filename=0x9e588 "dumbarton",  
exe_filename=0x117be50 "/Library/Frameworks/Mono.framework/Versions/", runtime_version=0xbffff66c  
"\001") at domain.c:586
#2  0x0020bf5e in mini_init (filename=0x9e588 "dumbarton") at mini.c: 
#3  0x0008d881 in -[DBMonoEnvironment initWithDomainName:]  
(self=0x116fe30, _cmd=0x9e3c8, domainName=0x9e588 "dumbarton") at ../ 
#4  0x0008d78e in +[DBMonoEnvironment defaultEnvironment]  
(self=0xa0320, _cmd=0x15354) at ../src/DBMonoEnvironment.m:54
#5  0x00008893 in +[icMixController initialize] (self=0x1a820,  
_cmd=0x90a62af8) at../icMixController.m:206
#6  0x90a558f7 in class_initialize ()
#7  0x90a5558e in _class_lookupMethodAndLoadCache ()
#8  0x90a55506 in objc_msgSend ()
#9  0x932a2e10 in -[NSIBObjectData instantiateObject:] ()
#10 0x932a2359 in -[NSIBObjectData  
nibInstantiateWithOwner:topLevelObjects:] ()
#11 0x9329998d in loadNib ()
#12 0x932993b9 in +[NSBundle(NSNibLoading)  
_loadNibFile:nameTable:withZone:ownerBundle:] ()
#13 0x9329901a in +[NSBundle(NSNibLoading)  
loadNibFile:externalNameTable:withZone:] ()
#14 0x93298f5c in +[NSBundle(NSNibLoading) loadNibNamed:owner:] ()
#15 0x93298ca3 in NSApplicationMain ()
#16 0x00002bb4 in main (argc=1, argv=0xbffffb4c) at /Users/eoin/ 

Tried to look at  mini.c on the SVN sources online the problem is here

			char *corlib_file = g_build_filename (mono_assembly_getrootdir (),  
"mono", current_runtime->framework_version, "mscorlib.dll", NULL);
			g_print ("The assembly mscorlib.dll was not found or could not be  
			g_print ("It should have been installed in the `%s' directory.\n",  
			g_free (corlib_file);

		exit (1);

How do I set the value of what mono_assembly_getrootdir() looks for?

-- Eoin

On 30 Oct 2006, at 14:23, Eoin Norris wrote:

> Hmm, I have some of this working but I am stumped by this problem in
> my app ( it did not happen in the DBCocoaExampel I was prototyping)
> The executable, Dumbarton dylib, and various mono libs  have been
> changed via install_name_tool to pick up bundled dylib versions.
> However on run I get this:
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries ........... done
> Reading symbols for shared libraries ... done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> The assembly mscorlib.dll was not found or could n
> "The assembly mscorlib.dll was not found or could not be loaded.
> It should have been installed in the `/Library/Frameworks/
> Mono.framework/Versions/'  
> directory."
> i think this is happening in the actual mono layer after the dylibs
> have been linked against.  I mean, mscorlib is not an object file,
> but possibly a compiled assemby. Any idea how to redirect the mono
> layers to point to this in a build script without installing anything
> in /Library/Frameworks/Mono.framework/ - I mean, if I have to do that
> I should just use a full installer.
> -- Eoin
> On 25 Oct 2006, at 11:30, Allan Hsu wrote:
>> Sorry I didn't get back to you when you sent me this question
>> yesterday, but, ironically, I was at the Mono developer's meeting
>> in Boston and there was no internet access:)
>> Here is how we do it at imeem:
>> We build our own universal version of Mono because there are a
>> couple problems right now with the current release builds of Mono
>> for OS X. Hopefully, after talking to Wade and Miguel this week
>> (and some followup work), we'll fix the current problems with
>> linking against the official builds as well as seeing what can be
>> done about getting official universal install packages. For now, if
>> you're just testing, you could probably just use one of the older
>> platform-specific release builds that links properly.
>> We include the Dumbarton framework project file in our main Xcode
>> project file, done by "add->existing files..." in the context menu
>> for the main project in "Groups & Files". It's important that you
>> either set your default build products folder in Xcode or manually
>> set the the build products folder in your project, the Dumbarton
>> project, and the Judy project inside Dumbarton all to the same  
>> folder.
>> In our release builds, we copy the Dumbarton framework and portions
>> of Mono into the application bundle. In order to fix the sorts of
>> linking problems you're experiencing, we use install_name_tool to
>> change the install names referenced by the application executable
>> and all of the dynamic librariesto @executable_path relative
>> install names. So instead of what you're trying to do, we link to
>> the Mono libraries in /Library/Frameworks/Mono/ and the included
>> Dumbarton framework project at build time, copy them into the
>> application bundle, and then rewrite the install names of the
>> copied libraries. The install_name_tool manpage explains how to use
>> the tool in detail.
>> At runtime, you'll have to tell Dumbarton where to look for your
>> embedded version of Mono, otherwise the runtime will not look in
>> your application bundle for the GAC. This is the code that we use:
>> NSString *libraryPath = [[[NSBundle mainBundle] bundlePath]
>> stringByAppendingPathComponent:@"Contents/Libraries"];
>> NSString *monoRootPath = [libraryPath
>> stringByAppendingPathComponent:@"Mono"];
>> [DBMonoEnvironment setAssemblyRoot:[monoRootPath
>> stringByAppendingPathComponent:@"lib"]];
>> [DBMonoEnvironment setConfigDir:[monoRootPath
>> stringByAppendingPathComponent:@"etc"]];
>> We don't do anything with weak linking.
>> I hope this helps. I just returned from Boston a few hours ago and
>> I'm very tired, so I may have missed something. I've been meaning
>> to write some tools to make this process easier and include samples
>> with the Dumbarton example code, but I haven't gotten around to it
>> yet.
>> 	-Allan
>> On Oct 25, 2006, at 2:04 AM, Eoin Norris wrote:
>>> This query is more for people who have used ObjectiveC# or  
>>> Dumbarton.
>>> I have created an application that runs on my Intel box, talking via
>>> dumbarton to the mono layer , and back. Mono does the business code
>>> and all UI is in Cocoa.
>>> I need to get to beta test sometime next week - with external  
>>> testers
>>> - and I need to either bite the bullet and bundle the frameworks
>>> within the bundle ( preferably a universal version) or just do it  
>>> via
>>> an installer, installing the frameworks in /Library/Frameworks -
>>> which is ugly for the Mac.
>>> I thought I had a fair idea how to do this, however I ran into
>>> dumbarton problems.
>>> The developer documentation from apple suggests that you should  
>>> build
>>> the frameworks within the project. This not what I want to do with
>>> the mono framework, specially as I am unsure how to build it.
>>> So for now I link against the mono  version ( which is  
>>> intel
>>> only on my machine) without building it.
>>> So the final build phase is:
>>> 1) copy dumbarton.framework and mono.framework to the application
>>> bundle/contents/frameworks/ directory via a script
>>> 2) add -weak-link dumbarton and -weak-link mono to the linker flags
>>> 3) Change the mono specific  linker flags ( which i dont really
>>> understand) to point to the bundled frameworks
>>> i.e. -L"$TARGET_BUILD_DIR/$FULL_PRODUCT_NAME/Contents/Frameworks/
>>> Mono.framework/Versions/Current/lib/pkgconfig/../../lib" and
>>> -L""$TARGET_BUILD_DIR/$FULL_PRODUCT_NAME/Contents/Frameworks/
>>> Mono.framework/Versions/Current/lib" -lmono -lm -lgmodule-2.0 -
>>> lgthread-2.0 -lglib-2.0 -lintl -liconv
>>> So that is the main target sorted I think, but I am not exactly  
>>> sure.
>>> However I add Dumbarton as a bundled framework too, but do not build
>>> it either.
>>> On launching the result is :
>>> dyld: Library not loaded: /Library/Frameworks/Mono.framework/
>>> Versions/
>>>    Referenced from: /Library/Frameworks/Dumbarton.framework/ 
>>> Versions/
>>> A/Dumbarton
>>>    Reason: image not found
>>> clearly a reference to the mono.framework from dumbarton. This gives
>>> rise to a circular problem, how do I build the dumbarton  
>>> framework to
>>> point to a mono.framework ( weak-linked?) within a bundle which  
>>> would
>>> not have been built yet, until after it the dumbarton framework is
>>> linked ( I think it is clear tha I have probably have to build
>>> dumbarton as part of my project.)
>>> Thanks in advance
>>> _______________________________________________
>>> Mono-osx mailing list
>>> Mono-osx at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-osx
>> --
>> Allan Hsu <allan at counterpop dot net>
>> 1E64 E20F 34D9 CBA7 1300  1457 AC37 CBBB 0E92 C779
> _______________________________________________
> Mono-osx mailing list
> Mono-osx at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-osx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-osx/attachments/20061030/10c35f1c/attachment-0001.html 

More information about the Mono-osx mailing list