[Mono-osx] How to add mono/dumbarton as a bundled framework
Allan Hsu
allan at counterpop.net
Mon Oct 30 17:14:57 EST 2006
It looks like you aren't using the DBMonoEnvironment methods
(setAssemblyRoot and setConfigDir) to change the Mono assembly root
and config paths. You need to make these calls at runtime before
calling into managed code if you want the runtime to look in a bundle-
relative spot for the GAC and Mono config files.
-Allan
On Oct 30, 2006, at 6:23 AM, 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
>>
>>
>>
--
Allan Hsu <allan at counterpop dot net>
1E64 E20F 34D9 CBA7 1300 1457 AC37 CBBB 0E92 C779
More information about the Mono-osx
mailing list