Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=77324 --- shadow/77324 2006-03-28 11:45:59.000000000 -0500 +++ shadow/77324.tmp.5208 2006-04-01 11:16:13.000000000 -0500 @@ -1,15 +1,15 @@ Bug#: 77324 Product: Mono: Runtime Version: 1.1 OS: Mac OS X 10.3 OS Details: -Status: RESOLVED -Resolution: NOTABUG +Status: REOPENED +Resolution: Severity: Unknown -Priority: Normal +Priority: Wishlist Component: packaging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] TargetMilestone: --- URL: @@ -255,6 +255,16 @@ It's clear that i could recompile mono using my own definitions but it's not a good option. My goal is to ship an application in binary form which works for normal users with their normal Mono installation under OSX (and other platforms where this is already working). The only workaround would be to provide a tweaked private mono framework inside the application bundle. Doesn't sound very elegant to me. + +------- Additional Comments From [EMAIL PROTECTED] 2006-04-01 11:16 ------- +Part of the issue is that on osx X we don't use a linker script to not +export the API pollution from the io-layer. And yes, the namespace +pollution is a mono bug (mostly insignificant, though). +The real solution is to rename the io-layer exported symbols to use a +Mono prefix. On windows we'd have the header file with the defines: +#define MonoCreateProcess CreateProcess +etc... so everything compiles against the right symbols and there is +no namespace pollution. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
