I have backported the following fixes from master into 4.2.3:
https://github.com/mono/mono/commit/b97ac0023256bf7d915552f5f24a7742b28c32b7
https://github.com/mono/mono/commit/8c52b398c5eb962bba5985e8bc01445ac5f027a5
https://github.com/mono/mono/pull/2781
https://github.com/mono/mono/pull/2783
http
> From: Chris Swiedler [mailto:cswied...@trionworlds.com]
>
> Why not just include references to Mono.Posix.dll in the Windows build? You
> don't have to install the full framework.
Then when you run it on mono, you're using the Mono.Posix.dll that you packaged
with your application, instead of
The SR class is autogenerated in the corefx build from
Resources/Strings.resx in each project with an msbuild task:
https://github.com/dotnet/buildtools/blob/master/src/Microsoft.DotNet.Build.Tasks/PackageFiles/resources.targets
The referencesources uses a similar pattern although most strings are
Heya,
If you package Mono.Posix.dll your app *will crash* on different systems.
This binary is platform specific and is not safe to copy between OS's. It
is also matched with a platform specific native binary,
libmonoposixhelper.[dll|dylib|so], which cannot be copied/pasted across
platforms either
On 30/03/2016 12:32, Edward Ned Harvey (mono) wrote:
>> From: Chris Swiedler [mailto:cswied...@trionworlds.com]
>>
>> Why not just include references to Mono.Posix.dll in the Windows build? You
>> don't have to install the full framework.
> Then when you run it on mono, you're using the Mono.Posi
Hi all,
for a little experiment, I am trying to build the library libmonosgen
as a .so, and to get mono to get linked to it instead of libmonosgen.a.
The reason is that I want to intercept some of the calls to get some
PAPI counters, measurements, etc., and to switch on/off this
instrument
You should be able to do that by passing --with-static_mono=no to
autogen.sh/configure:
http://www.mono-project.com/docs/compiling-mono/unsupported-advanced-compile-options/#static-vs-dynamic-mono
-- Alex
2016-03-30 14:31 GMT+02:00 Felix Rubio :
> Hi all,
>
>for a little experiment, I am try
Felix,
Unless they have fixed https://bugzilla.xamarin.com/show_bug.cgi?id=33081 since
4.2, you will need to comment out
https://github.com/mono/mono/blob/master/mono/mini/main.c#L51 in order to build.
From:
mailto:mono-devel-list-boun...@lists.ximian.com>>
on behalf of Alexander Köplinger
m
Hi Alexander, Martin
I had seen the flag in the configure, but I thought it would switch
all the libraries to shared... and I was looking towards libmonosgen
only. Anyway, after applying the flag and correcting that file
(mini/main.c), I am getting this error now:
Creating the per profile
On Mar 30, 2016, at 8:33 AM, Alan wrote:
> If you package Mono.Posix.dll your app *will crash* on different systems.
Not necessarily.
> This binary is platform specific and is not safe to copy between OS’s.
Mono.Posix.dll *itself* contains no platform-specific code and is perfectly
safe to cop
To Alan's point, we did see crashes when we (unintentionally) deployed
Mono.Posix.dll along with our app. Our solution was, like he said, to Not Do
That, and use our Mono.Posix as a compile-time library only.
I do think it's much easier to do it this way than to have different compile
targets,
I'm currently determining whether or not a third party who is running Mono
runtime 3.8.0, is supported in RHEL 7 / CentOS 7. We're considering moving
to either distros but want to make sure everything isn't going to complain
(all that much).
I understand that there is a kernel issue between Mono a
I had vague recollections that there were some ifdefs in the managed code
which made it platform specific, but I could be wrong or they could just be
gone nowadays. Jonp probably knows best ;)
Either way, if you deploy it without the matching native lib you can hit
crashes, so the simplest option
13 matches
Mail list logo