[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/1.1.17.1/lib/mono/1.0/mscorlib.dll" 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/
1.1.17.1/lib/mono/1.0/mscorlib.dll", runtime_version=0xbffff66c
"\001") at domain.c:586
#2 0x0020bf5e in mini_init (filename=0x9e588 "dumbarton") at mini.c:
11042
#3 0x0008d881 in -[DBMonoEnvironment initWithDomainName:]
(self=0x116fe30, _cmd=0x9e3c8, domainName=0x9e588 "dumbarton") at ../
src/DBMonoEnvironment.m:77
#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/
Copied/iCueMix/main.m:12
Tried to look at mini.c on the SVN sources online the problem is here
case MONO_IMAGE_ERROR_ERRNO: {
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
loaded.\n");
g_print ("It should have been installed in the `%s' directory.\n",
corlib_file);
g_free (corlib_file);
break;
}
..
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/1.1.17.1/lib/mono/1.0/mscorlib.dll'
> 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 1.1.17.1 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/
>>> 1.1.17.1/lib/libmono.0.0.0.dylib
>>> 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