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

[Eoin Norris]

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
>
>
>