Re: [Mono-dev] Building a Mono RPM

2013-08-27 Thread Rafael Teixeira 
It just sounds strange that you are trying to build an RPM package on a
system based on DEB packaging, in Ubuntu it would be easier to package a
.deb package to target Debian-based distros like Debian/Ubuntu/Mint/etc...
or switch to Fedora as your distro for building and packaging if you are
targeting the Fedora/Red Hat/Centos/etc... family of distros that use RPM
files.

You can look at projects of apps that depend on Mono like MonoDevelop(
http://monodevelop.com/), Banshee (http://banshee.fm/), F-Spot (
http://f-spot.org/) are packaged for Debian/Ubuntu (not sure they are
packaged for Fedora/Red Hat nowadays).

Hope it helps,

Rafael Teixeira
O..:.)


On Mon, Aug 26, 2013 at 8:33 PM, Chris Tacke  wrote:

> Let me preface this with the fact that I’m pretty new to Linux.
>
> ** **
>
> I have pulled the Mono source and successfully built it on 32-bit Ubuntu.
> I was able to successfully take the binaries generated from a “make
> install” and copy them to a different Linux distribution and actually run a
> Mono app on that target.  That seems like the wrong way to approach it
> though.  I suspect I should be distributing an RPM file.
>
> ** **
>
> So I decided to try to build the RPM file today, and I’m having very
> little success.  The first issue I had was that rpmbuild would give an
> “Unknown command: recommends” error.  So I went into the spec fiel and
> commented that line out, just to see where it went from there.  Now it
> complains that it can’t find mono-3.3.0-tar.bz2.  I can only assume that I
> need to generate this file, but I’m not sure exactly how.  Is there a
> script that will do it, or do I just tar up the installation?
>
> ** **
>
> Is there any documentation on how to build an RPM starting with just a
> clean OS build, or at least from a system where Mono has been compiled and
> installed?
>
> ** **
>
> -Chris
>
> ** **
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Request for status of Entity framework on Mono

2013-08-27 Thread Mitchell Jonathan 
Hi

I have done some experimenting with the latest MS Entity 6 beta and the Devart 
SQLite data provider.
I was able to query quite a substantial pre-existing data set when running on 
Mono.
So it is doable.

Jonathan

On 19 Aug 2013, at 00:17, Martin Thwaites  wrote:

> Thanks Daniel.
> 
> I'll have a look at those, but Ideally I wanted to look at Entity due to some 
> work projects that are currently using it (pure windows .NET and VS).  The 
> plan was to get the basics down in some hobby apps.
> 
> I'm currently using NHibernate, and it works well, entity does look like fun 
> to play with... I'm a very "ooo shiny" kinda guy.
> 
> I did see a big merge happen in the last few days by Marek, so I was hoping 
> that might be the start of something...
> 
> Thanks,
> Martin
> 
> On 18 August 2013 23:45, Daniel Lo Nigro  wrote:
> There's no official release of Entity Framework 6 yet, the latest release is 
> the first beta release. Additionally, I don't think all the supporting 
> architecture is fully working in Mono yet. You could try it and see, although 
> I'd use Entity Framework from NuGet as the one bundled with Mono is out of 
> date.
> 
> If you only need basic features, I'd suggest looking at a micro ORM like 
> ServiceStack ORMLite, Dapper, or Massive. These are all very basic facades 
> over raw ADO.NET, usually providing only basic ORM. I use ORMLite with Mono 
> and it works quite well.
> 
> 
> On Mon, Aug 19, 2013 at 7:16 AM, Martin Thwaites  
> wrote:
> I'm starting a new project from scratch soon, and I'm selecting some 
> components.  I do everything in mono.. you'll be pleased to hear ;)
> 
> For ORM, I'm looking to utilise EntityFramework, so I'm wondering where the 
> development is at, is anyone working on it, etc.
> 
> I don't think I'll be using any advanced features, just the basics.  So, are 
> the basics in enough of a usable state to put into a production application?
> 
> I'm not seeing any stabilisation branches/tags in the repository, so can I 
> assume that it's still in flux and should be avoided for the timebeing?
> 
> I'll obviously give it a go and see, but just wondering if anyone has any 
> experiences?
> 
> Thanks in advance.
> Martin
> 
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> 
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Small issues with the Windows msvc builds, and how I got around them

2013-08-27 Thread Alex Forster 
Referring to commit 29c42bf0dc— just a few tips on how I got the -sgen 
configurations to compile in 32bit release mode with Visual Studio 2012.

First issue—

msvcrt apparently doesn’t implement _strtoull(). According to this Connect 
article[1], the functionality exists as _strtoui64().

So, as a comment in the Connect article suggested, in eglib\src\glib.h I added 
this at around line 275 inside of the _MSC_VER ifdef…

#define strtoll _strtoi64
#define strtoull_strtoui64

Second issue—

The profiler-cov project links to mono-2.0.lib, but for the -sgen builds, it 
should be linking to monosgen-2.0.lib. I know the .csproj’s are generated from 
the makefiles so this isn’t a “real” fix, but all it took for me to get the 
project to build was to make the project link to the correct library.

The x64 build fails miserably because the __asm keyword isn’t supported by 
Microsoft’s x64 compiler.

Alex Forster


[1] 
http://connect.microsoft.com/VisualStudio/feedback/details/758053/missing-strtof-strtold-strtoll-strtoull-functions-from-stdlib-h

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building a Mono RPM

2013-08-27 Thread Chris Tacke 
So as a bit of background, this is what I’m doing.  I am building an embedded 
Linux platform running Wind River, which I believe is Fedora based.  The tools 
for building the OS came on a Ubuntu VM.  I am trying to build Mono (succeeded 
there), and then an installer for Mono so that I can install Mono on the 
embedded device.  I’ll follow that with an installer for our application.  I 
was told that RPM was the mechanism for installing packages on Wind River, so I 
went down that road.

What it sounds like you’re telling me is that for building an RPM package for 
Wind River, I should be using Fedora and no Ubuntu, because Ubuntu has outdated 
RPM infrastructure since it doesn’t use RPM for package management.

Is this all correct?

I guess I can build up a Fedora machine to do the work for the installer, it 
just means that now I need two dev OSes to build this target (three if you 
count Windows where we actually do the app development).

Is there any guide or documentation for building a Mono RPM for Fedora?

-Chris


From: Rafael Teixeira [mailto:mono...@gmail.com]
Sent: Tuesday, August 27, 2013 6:28 AM
To: Chris Tacke
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Building a Mono RPM

It just sounds strange that you are trying to build an RPM package on a system 
based on DEB packaging, in Ubuntu it would be easier to package a .deb package 
to target Debian-based distros like Debian/Ubuntu/Mint/etc... or switch to 
Fedora as your distro for building and packaging if you are targeting the 
Fedora/Red Hat/Centos/etc... family of distros that use RPM files.

You can look at projects of apps that depend on Mono like 
MonoDevelop(http://monodevelop.com/), Banshee (http://banshee.fm/), F-Spot 
(http://f-spot.org/) are packaged for Debian/Ubuntu (not sure they are packaged 
for Fedora/Red Hat nowadays).

Hope it helps,

Rafael Teixeira
O..:.)

On Mon, Aug 26, 2013 at 8:33 PM, Chris Tacke 
mailto:cta...@opennetcf.com>> wrote:
Let me preface this with the fact that I’m pretty new to Linux.

I have pulled the Mono source and successfully built it on 32-bit Ubuntu.  I 
was able to successfully take the binaries generated from a “make install” and 
copy them to a different Linux distribution and actually run a Mono app on that 
target.  That seems like the wrong way to approach it though.  I suspect I 
should be distributing an RPM file.

So I decided to try to build the RPM file today, and I’m having very little 
success.  The first issue I had was that rpmbuild would give an “Unknown 
command: recommends” error.  So I went into the spec fiel and commented that 
line out, just to see where it went from there.  Now it complains that it can’t 
find mono-3.3.0-tar.bz2.  I can only assume that I need to generate this file, 
but I’m not sure exactly how.  Is there a script that will do it, or do I just 
tar up the installation?

Is there any documentation on how to build an RPM starting with just a clean OS 
build, or at least from a system where Mono has been compiled and installed?

-Chris


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Entity Framework crash in System.Reflection.AssemblyName.ReferenceMatchesDefinition

2013-08-27 Thread mlgo 
Has anyone figured this out yet?. Either this is going to have to be
implemented or the Entity Framwork needs to avoid calling it. There is a
stacktrace at the bottom of this message. 

System.Reflection.AssemblyName.ReferenceMatchesDefinition is not
implemented. I guess developers have been working around this by comparing
the assembly fullnames. Since it is called directly by EntityFramework it
has to be implemented now. Unless EF should be changed to avoid this call.
This is something I have not researched either. If anyone would think that
EntityFramework should be changed to avoid making this call please add some
feedback. 

Has anyone done this implementation or are they working on it currently?. I
don't see any posts or bugs relating to it but I did find one reference to
the problem in the context of another product using mono. 
Does the mono team plan to or want to implement it? 


I have done some research on this method in dotnet. The implementation for
windows as documented by MSDN in this simple way "The comparison depends
only on the simple assembly name. It ignores version, culture, and public
key token. ". 

At a more fundamentally level the purpose of this method is to determine if
the 2 names resolve to the same assembly. I believe that the documentation
in dotnet used to read that way and referred to the loader. I suspect that
dotnet is still doing that as part of the implementation of this function.
If that approach were taken I'm not yet sure if it requires making windows
OS calls to do it or if it could be done with managed code. The point is if
it does need to be done and it needs to call os api's then the
implementation would need to be different for Linux. If it is called often.
If it involves loading an assembly using both of the names and then
determining whether it is the same assembly that seems slow and inefficient.
I have not done any performance profiling on this call to find out often it
gets called.   
I think I would want to cache the assemblies. Also memoize the assembly
names and their results. This would speed things up considerably. 


I'm concerned this will need to be implemented differently on Linux?? Hence
it will have multiple implementations. 

Now that EF6 is in and people are using this becomes an immediate problem as
it binds directly to the unimplemented function
AssemblyName.ReferenceMatchesDefinition. Here is the stack: 

  

System.NotImplementedException: The requested feature is not implemented. 

  at System.Reflection.AssemblyName.ReferenceMatchesDefinition
(System.Reflection.AssemblyName reference, System.Reflection.AssemblyName
definition) [0x0003a] in
C:\cygwin\sources\mono\mcs\class\corlib\System.Reflection\AssemblyName.cs:328 

  at
System.Data.Entity.Core.Metadata.Edm.DefaultAssemblyResolver.ResolveAssembly
(System.Reflection.AssemblyName referenceName) [0x00019] in
C:\cygwin\sources\mono\external\entityframework\src\EntityFramework\Core\Metadata\Edm\DefaultAssemblyResolver.cs:30
 

  at
System.Data.Entity.Core.Metadata.Edm.DefaultAssemblyResolver.TryResolveAssemblyReference
(System.Reflection.AssemblyName refernceName, System.Reflection.Assembly&
assembly) [0x0] in
C:\cygwin\sources\mono\external\entityframework\src\EntityFramework\Core\Metadata\Edm\DefaultAssemblyResolver.cs:14
 

  at
System.Data.Entity.Core.Metadata.Edm.MetadataArtifactLoaderCompositeResource.ResolveAssemblyName
(System.String assemblyName,
System.Data.Entity.Core.Metadata.Edm.MetadataArtifactAssemblyResolver
resolver) [0x7] in
C:\cygwin\sources\mono\external\entityframework\src\EntityFramework\Core\Metadata\Edm\MetadataArtifactLoaderCompositeResource.cs:272
 

  at
System.Data.Entity.Core.Metadata.Edm.MetadataArtifactLoaderCompositeResource.CreateResourceLoader
(System.String path, ExtensionCheck extensionCheck, System.String
validExtension, ICollection`1 uriRegistry,
System.Data.Entity.Core.Metadata.Edm.MetadataArtifactAssemblyResolver
resolver) [0x0004d] in
C:\cygwin\sources\mono\external\entityframework\src\EntityFramework\Core\Metadata\Edm\MetadataArtifactLoaderCompositeResource.cs:306
 

  at System.Data.Entity.Core.Metadata.Edm.MetadataArtifactLoader.Create
(System.String path, ExtensionCheck extensionCheck, System.String
validExtension, ICollection`1 uriRegistry,
System.Data.Entity.Core.Metadata.Edm.MetadataArtifactAssemblyResolver
resolver) [0xb] in
C:\cygwin\sources\mono\external\entityframework\src\EntityFramework\Core\Metadata\Edm\MetadataArtifactLoader.cs:91
 

  at System.Data.Entity.Core.Metadata.Edm.MetadataArtifactLoader.Create
(System.String path, ExtensionCheck extensionCheck, System.String
validExtension, ICollection`1 uriRegistry) [0x0] in
C:\cygwin\sources\mono\external\entityframework\src\EntityFramework\Core\Metadata\Edm\MetadataArtifactLoader.cs:61
 

  at System.Data.Entity.Core.Metadata.Edm.MetadataCache.SplitPaths
(System.String paths) [0x0011b] in
C:\cygwin\sources\mono\external\entityframework\src\EntityFramework\Core\Metadata\Edm

[Mono-dev] A possible implementation for AssemblyName.ReferenceMatchesDefinition

2013-08-27 Thread mlgo 
According to
http://msdn.microsoft.com/en-us/library/system.reflection.assemblyname.referencematchesdefinition.aspx

The following is what is expected to be returned from
ReferenceMatchesDefinition.
 
Returns a value indicating whether two assembly names are the same. The
comparison is based on the simple assembly names. 

This seems naïve but below is a tentative implementation of that. Any ideas?

public static bool ReferenceMatchesDefinition (AssemblyName reference,
AssemblyName definition)
{
if (reference == null)
throw new ArgumentNullException ("reference");
if (definition == null)
throw new ArgumentNullException ("definition");
if (reference.Name != definition.Name)
return false;

return reference.Name.Equals(definition.Name);
}




--
View this message in context: 
http://mono.1490590.n4.nabble.com/A-possible-implementation-for-AssemblyName-ReferenceMatchesDefinition-tp4660683.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] SGEN support when cross compiling

2013-08-27 Thread Rodrigo Kumpera 
All this means is that the managed allocators won't be used.


On Mon, Aug 26, 2013 at 8:07 PM, Bassam Tabbara  wrote:

>  I tried that and I run into the following error when I run mono:
>
>  sgen is not supported when using --with-tls=pthread
>
>  Looking at the code here:
>
>  https://github.com/mono/mono/blob/master/mono/metadata/sgen-gc.h#L990
>
>  Seems like pthread is only supported on darwin and windows. I'm cross
> compiling to linux with with-tls=pthread.
>
>   From: Rodrigo Kumpera 
> Date: Monday, August 26, 2013 5:01 PM
>
> To: Bassam Tabbara 
> Cc: "mono-devel-list@lists.ximian.com" 
> Subject: Re: [Mono-dev] SGEN support when cross compiling
>
>   Configure with --thread=pthread
>
>
> On Mon, Aug 26, 2013 at 7:36 PM, Bassam Tabbara wrote:
>
>>  Thanks Rodrigo. Is there a trick then to bypass the __thread check
>> during configuration?
>>
>>  ./configure --host=armv5te-unknown-linux-gnueabi
>>
>>  Fails with:
>>
>>  configure: error: cannot run test program while cross compiling
>>
>>  I worked around it with the following:
>>
>>
>> https://github.com/symform/mono/commit/fe5c582a1a2d241f368c86081b3cb7ea53994f51
>>
>>  Do others not see this?
>>
>>   From: Rodrigo Kumpera 
>> Date: Monday, August 26, 2013 4:30 PM
>> To: Bassam Tabbara 
>> Cc: "mono-devel-list@lists.ximian.com" 
>> Subject: Re: [Mono-dev] SGEN support when cross compiling
>>
>>   sgen works fine on ARM and so does cross compiling to it.
>>
>>
>> On Mon, Aug 26, 2013 at 6:19 PM, Bassam Tabbara wrote:
>>
>>>  Hello,
>>>
>>>  I'm working in mono master, and it looks like sgen is not support when
>>> cross compiling. Sgen requiren with-tls=__thread and during configuration a
>>> check is made if __thread is functioning and that fails with the following
>>> error when cross compiling:
>>>
>>>  configure: error: cannot run test program while cross compiling
>>> [
>>>
>>>  I can work around this but disable the check during configuration, but
>>> I'm now wondering whether anyone is using sgen on ARM platforms? Are you
>>> cross compiling for those platforms? I must be missing something simple
>>> here.
>>>
>>>  Thanks!
>>>  Bassam
>>>
>>> ___
>>> Mono-devel-list mailing list
>>> Mono-devel-list@lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>>
>>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] SGEN support when cross compiling

2013-08-27 Thread Bassam Tabbara 
Should it be a warning then? The runtime aborts after this error. The only 
workaround I've found so far is:

https://github.com/symform/mono/commit/fe5c582a1a2d241f368c86081b3cb7ea53994f51

And sgen is running well now with a cross compiled mono.

From: Rodrigo Kumpera mailto:kump...@gmail.com>>
Date: Tuesday, August 27, 2013 8:58 AM
To: Bassam Tabbara mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com" 
mailto:mono-devel-list@lists.ximian.com>>
Subject: Re: [Mono-dev] SGEN support when cross compiling

All this means is that the managed allocators won't be used.


On Mon, Aug 26, 2013 at 8:07 PM, Bassam Tabbara 
mailto:bas...@symform.com>> wrote:
I tried that and I run into the following error when I run mono:

sgen is not supported when using --with-tls=pthread

Looking at the code here:

https://github.com/mono/mono/blob/master/mono/metadata/sgen-gc.h#L990

Seems like pthread is only supported on darwin and windows. I'm cross compiling 
to linux with with-tls=pthread.

From: Rodrigo Kumpera mailto:kump...@gmail.com>>
Date: Monday, August 26, 2013 5:01 PM

To: Bassam Tabbara mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com" 
mailto:mono-devel-list@lists.ximian.com>>
Subject: Re: [Mono-dev] SGEN support when cross compiling

Configure with --thread=pthread


On Mon, Aug 26, 2013 at 7:36 PM, Bassam Tabbara 
mailto:bas...@symform.com>> wrote:
Thanks Rodrigo. Is there a trick then to bypass the __thread check during 
configuration?

./configure --host=armv5te-unknown-linux-gnueabi

Fails with:

configure: error: cannot run test program while cross compiling

I worked around it with the following:

https://github.com/symform/mono/commit/fe5c582a1a2d241f368c86081b3cb7ea53994f51

Do others not see this?

From: Rodrigo Kumpera mailto:kump...@gmail.com>>
Date: Monday, August 26, 2013 4:30 PM
To: Bassam Tabbara mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com" 
mailto:mono-devel-list@lists.ximian.com>>
Subject: Re: [Mono-dev] SGEN support when cross compiling

sgen works fine on ARM and so does cross compiling to it.


On Mon, Aug 26, 2013 at 6:19 PM, Bassam Tabbara 
mailto:bas...@symform.com>> wrote:
Hello,

I'm working in mono master, and it looks like sgen is not support when cross 
compiling. Sgen requiren with-tls=__thread and during configuration a check is 
made if __thread is functioning and that fails with the following error when 
cross compiling:

configure: error: cannot run test program while cross compiling
[

I can work around this but disable the check during configuration, but I'm now 
wondering whether anyone is using sgen on ARM platforms? Are you cross 
compiling for those platforms? I must be missing something simple here.

Thanks!
Bassam

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list




___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] A possible implementation for AssemblyName.ReferenceMatchesDefinition

2013-08-27 Thread Stifu 
If I'm not mistaken, the last 2 tests are redundant. You're basically doing
the same test twice.
So I guess this could be simplified to something like:

public static bool ReferenceMatchesDefinition (AssemblyName 
reference,
AssemblyName definition)
{
if (reference == null)
throw new ArgumentNullException ("reference");
if (definition == null)
throw new ArgumentNullException ("definition");
return reference.Name == definition.Name;
}


mlgo wrote
> According to
> http://msdn.microsoft.com/en-us/library/system.reflection.assemblyname.referencematchesdefinition.aspx
> 
> The following is what is expected to be returned from
> ReferenceMatchesDefinition.
>  
> Returns a value indicating whether two assembly names are the same. The
> comparison is based on the simple assembly names. 
> 
> This seems naïve but below is a tentative implementation of that. Any
> ideas?
> 
> public static bool ReferenceMatchesDefinition (AssemblyName reference,
> AssemblyName definition)
>   {
>   if (reference == null)
>   throw new ArgumentNullException ("reference");
>   if (definition == null)
>   throw new ArgumentNullException ("definition");
>   if (reference.Name != definition.Name)
>   return false;
>   
>   return reference.Name.Equals(definition.Name);
>   }





--
View this message in context: 
http://mono.1490590.n4.nabble.com/A-possible-implementation-for-AssemblyName-ReferenceMatchesDefinition-tp4660683p4660686.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building a Mono RPM

2013-08-27 Thread Chris Tacke 
Well that seems to have been a huge waste of time.  I built up a Fedora 18 
machine, installed all of the packages necessary for building, pulled the 
source for mono, did a configure, make and a make install.  All went fine.

I then tried to use rpmbuild and again, I get the following error (just like I 
did on Ubuntu):

Error: line 51: Unknown tag: Recommends: libgdiplus0 >= 2.6

At this point, should I assume that deploying Mono is best done with a tarball 
instead?

-Chris


From: mono-devel-list-boun...@lists.ximian.com 
[mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Chris Tacke
Sent: Tuesday, August 27, 2013 9:44 AM
To: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Building a Mono RPM

So as a bit of background, this is what I’m doing.  I am building an embedded 
Linux platform running Wind River, which I believe is Fedora based.  The tools 
for building the OS came on a Ubuntu VM.  I am trying to build Mono (succeeded 
there), and then an installer for Mono so that I can install Mono on the 
embedded device.  I’ll follow that with an installer for our application.  I 
was told that RPM was the mechanism for installing packages on Wind River, so I 
went down that road.

What it sounds like you’re telling me is that for building an RPM package for 
Wind River, I should be using Fedora and no Ubuntu, because Ubuntu has outdated 
RPM infrastructure since it doesn’t use RPM for package management.

Is this all correct?

I guess I can build up a Fedora machine to do the work for the installer, it 
just means that now I need two dev OSes to build this target (three if you 
count Windows where we actually do the app development).

Is there any guide or documentation for building a Mono RPM for Fedora?

-Chris


From: Rafael Teixeira [mailto:mono...@gmail.com]
Sent: Tuesday, August 27, 2013 6:28 AM
To: Chris Tacke
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Building a Mono RPM

It just sounds strange that you are trying to build an RPM package on a system 
based on DEB packaging, in Ubuntu it would be easier to package a .deb package 
to target Debian-based distros like Debian/Ubuntu/Mint/etc... or switch to 
Fedora as your distro for building and packaging if you are targeting the 
Fedora/Red Hat/Centos/etc... family of distros that use RPM files.

You can look at projects of apps that depend on Mono like 
MonoDevelop(http://monodevelop.com/), Banshee (http://banshee.fm/), F-Spot 
(http://f-spot.org/) are packaged for Debian/Ubuntu (not sure they are packaged 
for Fedora/Red Hat nowadays).

Hope it helps,

Rafael Teixeira
O..:.)

On Mon, Aug 26, 2013 at 8:33 PM, Chris Tacke 
mailto:cta...@opennetcf.com>> wrote:
Let me preface this with the fact that I’m pretty new to Linux.

I have pulled the Mono source and successfully built it on 32-bit Ubuntu.  I 
was able to successfully take the binaries generated from a “make install” and 
copy them to a different Linux distribution and actually run a Mono app on that 
target.  That seems like the wrong way to approach it though.  I suspect I 
should be distributing an RPM file.

So I decided to try to build the RPM file today, and I’m having very little 
success.  The first issue I had was that rpmbuild would give an “Unknown 
command: recommends” error.  So I went into the spec fiel and commented that 
line out, just to see where it went from there.  Now it complains that it can’t 
find mono-3.3.0-tar.bz2.  I can only assume that I need to generate this file, 
but I’m not sure exactly how.  Is there a script that will do it, or do I just 
tar up the installation?

Is there any documentation on how to build an RPM starting with just a clean OS 
build, or at least from a system where Mono has been compiled and installed?

-Chris


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Small issues with the Windows msvc builds, and how I got around them

2013-08-27 Thread Jean-Michel.Perraud 
Hi Alex,

Thanks for the information; I sometimes need to dive into the C code to get it 
to compile under MSVC and your heads up is a time saver. You may want to 
fork+branch and do a pull request if you think these fixes are not temporary 
hacks.

profiler-cov is a .vcxproj file, and AFAIK not generated from makefile as the 
.csproj files are, as you seem to believe. This nevertheless sounds like a good 
idea.

I’ll work part time on the port of a large C# application to run on Mono+Linux 
over the coming months; while the target is Linux I think I’ll have the need to 
build/test on Mono+Windows too and improve the project file generation with 
MSVS2012. I take due note of your post

Regards,
J-M

From: mono-devel-list-boun...@lists.ximian.com 
[mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Alex Forster
Sent: Monday, 26 August 2013 3:11 AM
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] Small issues with the Windows msvc builds, and how I got 
around them

Referring to commit 29c42bf0dc— just a few tips on how I got the -sgen 
configurations to compile in 32bit release mode with Visual Studio 2012.
 
First issue—
 
msvcrt apparently doesn’t implement _strtoull(). According to this Connect 
article[1], the functionality exists as _strtoui64().
 
So, as a comment in the Connect article suggested, in eglib\src\glib.h I added 
this at around line 275 inside of the _MSC_VER ifdef…
 
#define strtoll _strtoi64
#define strtoull    _strtoui64
 
Second issue—
 
The profiler-cov project links to mono-2.0.lib, but for the -sgen builds, it 
should be linking to monosgen-2.0.lib. I know the .csproj’s are generated from 
the makefiles so this isn’t a “real” fix, but all it took for me to get the 
project to build was to make the project link to the correct library.
 
The x64 build fails miserably because the __asm keyword isn’t supported by 
Microsoft’s x64 compiler.
 
Alex Forster
 
 
[1] 
http://connect.microsoft.com/VisualStudio/feedback/details/758053/missing-strtof-strtold-strtoll-strtoull-functions-from-stdlib-h
 
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] A possible implementation for AssemblyName.ReferenceMatchesDefinition

2013-08-27 Thread Daniel Lo Nigro 
You may want to ignore culture and case in your comparison:

return reference.Name.Equals(definition.Name,
StringComparison.InvariantCultureIgnoreCase)



On Wed, Aug 28, 2013 at 1:29 AM, mlgo  wrote:

> According to
>
> http://msdn.microsoft.com/en-us/library/system.reflection.assemblyname.referencematchesdefinition.aspx
>
> The following is what is expected to be returned from
> ReferenceMatchesDefinition.
>
> Returns a value indicating whether two assembly names are the same. The
> comparison is based on the simple assembly names.
>
> This seems naïve but below is a tentative implementation of that. Any
> ideas?
>
> public static bool ReferenceMatchesDefinition (AssemblyName reference,
> AssemblyName definition)
> {
> if (reference == null)
> throw new ArgumentNullException
> ("reference");
> if (definition == null)
> throw new ArgumentNullException
> ("definition");
> if (reference.Name != definition.Name)
> return false;
>
> return reference.Name.Equals(definition.Name);
> }
>
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/A-possible-implementation-for-AssemblyName-ReferenceMatchesDefinition-tp4660683.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] A possible implementation for AssemblyName.ReferenceMatchesDefinition

2013-08-27 Thread mlgo 
Right. Thanks. I hadn't thought about that. I keep suspecting that the 
documentation is not right though. That in fact what needs to be done is 
determine if the names actually refer to the same dll. Hopefully someone can 
reply to this who knows more about the internals of this. Otherwise I need to 
find some more real world uses of it in dotnet source code so I can better 
understand if this is the right way to go.



From: Daniel Lo Nigro [via Mono] [ml-node+s1490590n466069...@n4.nabble.com]
Sent: Tuesday, August 27, 2013 7:20 PM
To: Mark Lintner
Subject: Re: A possible implementation for 
AssemblyName.ReferenceMatchesDefinition

You may want to ignore culture and case in your comparison:

return reference.Name.Equals(definition.Name, 
StringComparison.InvariantCultureIgnoreCase)



On Wed, Aug 28, 2013 at 1:29 AM, mlgo <[hidden 
email]> wrote:
According to
http://msdn.microsoft.com/en-us/library/system.reflection.assemblyname.referencematchesdefinition.aspx

The following is what is expected to be returned from
ReferenceMatchesDefinition.

Returns a value indicating whether two assembly names are the same. The
comparison is based on the simple assembly names.

This seems naïve but below is a tentative implementation of that. Any ideas?

public static bool ReferenceMatchesDefinition (AssemblyName reference,
AssemblyName definition)
{
if (reference == null)
throw new ArgumentNullException ("reference");
if (definition == null)
throw new ArgumentNullException ("definition");
if (reference.Name != definition.Name)
return false;

return reference.Name.Equals(definition.Name);
}




--
View this message in context: 
http://mono.1490590.n4.nabble.com/A-possible-implementation-for-AssemblyName-ReferenceMatchesDefinition-tp4660683.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list


___
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list



If you reply to this email, your message will be added to the discussion below:
http://mono.1490590.n4.nabble.com/A-possible-implementation-for-AssemblyName-ReferenceMatchesDefinition-tp4660683p4660691.html
To unsubscribe from A possible implementation for 
AssemblyName.ReferenceMatchesDefinition, click 
here.
NAML




--
View this message in context: 
http://mono.1490590.n4.nabble.com/A-possible-implementation-for-AssemblyName-ReferenceMatchesDefinition-tp4660683p4660692.html
Sent from the Mono - Dev mailing list archive at Nabble.com.___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] A possible implementation for AssemblyName.ReferenceMatchesDefinition

2013-08-27 Thread Daniel Lo Nigro 
It looks like the behaviour may have changed between .NET versions... The
MSDN page for .NET Framework 3.5 onwards (including 4.5) states:

Returns a value indicating whether two assembly names are the same. The
> comparison is based on the simple assembly names.
> return value - true if the simple assembly names are the same; otherwise,
> false.
> The comparison depends only on the simple assembly name. It ignores
> version, culture, and public key token.


But the .NET Framework 2.0
pagestates:

Returns a value indicating whether the loader resolves two assembly names
> to the same assembly.
> Return Value - true if the loader resolves definition to the same assembly
> as reference; otherwise, false.
> Both reference and definition are resolved by the loader, including policy
> evaluation, and then definition is tested for equality to reference.


It sounds like it did a lot more work in the .NET 2.0 implementation. Not
sure why it changed and I can't seem to find much information on it.



On Wed, Aug 28, 2013 at 10:46 AM, mlgo  wrote:

>  Right. Thanks. I hadn't thought about that. I keep suspecting that the
> documentation is not right though. That in fact what needs to be done is
> determine if the names actually refer to the same dll. Hopefully someone
> can reply to this who knows more about the internals of this. Otherwise
> I need to find some more real world uses of it in dotnet source code so I
> can better understand if this is the right way to go.
> --
>
>  *From:* Daniel Lo Nigro [via Mono] [ml-node+[hidden 
> email]
> ]
> *Sent:* Tuesday, August 27, 2013 7:20 PM
> *To:* Mark Lintner
> *Subject:* Re: A possible implementation for
> AssemblyName.ReferenceMatchesDefinition
>
>   You may want to ignore culture and case in your comparison:
>
>  return reference.Name.Equals(definition.Name,
> StringComparison.InvariantCultureIgnoreCase)
>
>
>
> On Wed, Aug 28, 2013 at 1:29 AM, mlgo <[hidden 
> email]
> > wrote:
>
>> According to
>>
>> http://msdn.microsoft.com/en-us/library/system.reflection.assemblyname.referencematchesdefinition.aspx
>>
>> The following is what is expected to be returned from
>> ReferenceMatchesDefinition.
>>
>> Returns a value indicating whether two assembly names are the same. The
>> comparison is based on the simple assembly names.
>>
>> This seems naïve but below is a tentative implementation of that. Any
>> ideas?
>>
>> public static bool ReferenceMatchesDefinition (AssemblyName reference,
>> AssemblyName definition)
>> {
>> if (reference == null)
>> throw new ArgumentNullException
>> ("reference");
>> if (definition == null)
>> throw new ArgumentNullException
>> ("definition");
>> if (reference.Name != definition.Name)
>> return false;
>>
>> return reference.Name.Equals(definition.Name);
>> }
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://mono.1490590.n4.nabble.com/A-possible-implementation-for-AssemblyName-ReferenceMatchesDefinition-tp4660683.html
>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>> ___
>> Mono-devel-list mailing list
>> [hidden email] 
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
>
> ___
> Mono-devel-list mailing list
> [hidden email] 
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://mono.1490590.n4.nabble.com/A-possible-implementation-for-AssemblyName-ReferenceMatchesDefinition-tp4660683p4660691.html
>  To unsubscribe from A possible implementation for
> AssemblyName.ReferenceMatchesDefinition, click here.
> NAML
>
> --
> View this message in context: RE: A possible implementation for
> AssemblyName.ReferenceMatchesDefinition
>
> Sent from the Mono - Dev mailing list 
> archive

Re: [Mono-dev] A possible implementation for AssemblyName.ReferenceMatchesDefinition

2013-08-27 Thread mlgo 
That's quite a difference. It must be there for compatibility now if that is 
the case because it is nothing but a string compare and does not really justify 
a function with that name. Also it would be a breaking problem if you were 
expecting the behavior described in the 2.0 docs..




From: Daniel Lo Nigro [via Mono] [ml-node+s1490590n4660693...@n4.nabble.com]
Sent: Tuesday, August 27, 2013 8:00 PM
To: Mark Lintner
Subject: Re: A possible implementation for 
AssemblyName.ReferenceMatchesDefinition

It looks like the behaviour may have changed between .NET versions... The MSDN 
page for .NET Framework 3.5 onwards (including 4.5) states:

Returns a value indicating whether two assembly names are the same. The 
comparison is based on the simple assembly names.
return value - true if the simple assembly names are the same; otherwise, false.
The comparison depends only on the simple assembly name. It ignores version, 
culture, and public key token.

But the .NET Framework 2.0 
page
 states:

Returns a value indicating whether the loader resolves two assembly names to 
the same assembly.
Return Value - true if the loader resolves definition to the same assembly as 
reference; otherwise, false.
Both reference and definition are resolved by the loader, including policy 
evaluation, and then definition is tested for equality to reference.

It sounds like it did a lot more work in the .NET 2.0 implementation. Not sure 
why it changed and I can't seem to find much information on it.



On Wed, Aug 28, 2013 at 10:46 AM, mlgo <[hidden 
email]> wrote:

Right. Thanks. I hadn't thought about that. I keep suspecting that the 
documentation is not right though. That in fact what needs to be done is 
determine if the names actually refer to the same dll. Hopefully someone can 
reply to this who knows more about the internals of this. Otherwise I need to 
find some more real world uses of it in dotnet source code so I can better 
understand if this is the right way to go.



From: Daniel Lo Nigro [via Mono] [ml-node+[hidden 
email]]
Sent: Tuesday, August 27, 2013 7:20 PM
To: Mark Lintner
Subject: Re: A possible implementation for 
AssemblyName.ReferenceMatchesDefinition

You may want to ignore culture and case in your comparison:

return reference.Name.Equals(definition.Name, 
StringComparison.InvariantCultureIgnoreCase)



On Wed, Aug 28, 2013 at 1:29 AM, mlgo <[hidden 
email]> wrote:
According to
http://msdn.microsoft.com/en-us/library/system.reflection.assemblyname.referencematchesdefinition.aspx

The following is what is expected to be returned from
ReferenceMatchesDefinition.

Returns a value indicating whether two assembly names are the same. The
comparison is based on the simple assembly names.

This seems naïve but below is a tentative implementation of that. Any ideas?

public static bool ReferenceMatchesDefinition (AssemblyName reference,
AssemblyName definition)
{
if (reference == null)
throw new ArgumentNullException ("reference");
if (definition == null)
throw new ArgumentNullException ("definition");
if (reference.Name != definition.Name)
return false;

return reference.Name.Equals(definition.Name);
}




--
View this message in context: 
http://mono.1490590.n4.nabble.com/A-possible-implementation-for-AssemblyName-ReferenceMatchesDefinition-tp4660683.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list


___
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list



If you reply to this email, your message will be added to the discussion below:
http://mono.1490590.n4.nabble.com/A-possible-implementation-for-AssemblyName-ReferenceMatchesDefinition-tp4660683p4660691.html
To unsubscribe from A possible implementation for 
AssemblyName.ReferenceMatchesDefinition, click here.
NAML