[Mono-dev] Building a Mono RPM

2013-08-26 Thread Chris Tacke
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


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

2013-08-26 Thread Bassam Tabbara
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] SGEN support when cross compiling

2013-08-26 Thread Rodrigo Kumpera
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-26 Thread Zoltan Varga
Hi,

  It might be easier to compile on the device itself using distcc+a cross
compiler.

  Zoltan


On Tue, Aug 27, 2013 at 1:36 AM, 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
>
>
___
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-26 Thread Bassam Tabbara
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] SGEN support when cross compiling

2013-08-26 Thread Rodrigo Kumpera
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


[Mono-dev] SGEN support when cross compiling

2013-08-26 Thread Bassam Tabbara
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


Re: [Mono-dev] Random mono apache errors

2013-08-26 Thread Daniel Lo Nigro
>
> 1. Use the open source way, find and fix it myself and hope that we will
> have this change in the official mono one day.


I've fixed a few bugs with Mono (most around the ASP.NET routing
implementation) and I've found that the Mono developers are pretty good
with pull requests. If you do a good fix, it's very likely to make it into
a release of Mono. The 3.x series is having more frequent releases compared
to the 2.10.x series.


On Mon, Aug 26, 2013 at 8:16 PM, Vladimir Dimitrov
wrote:

>  Almost the same thing just happened again. I got this error when calling
> a web service on the apache/mono server:
>
> System.Exception: INTERNAL configuration error: failed to get
> configuration 'system.diagnostics'
>   at System.Diagnostics.DiagnosticsConfiguration.get_Settings () [0x0]
> in :0
>   at System.Diagnostics.TraceImpl.InitOnce () [0x0] in  unknown>:0
>   at System.Diagnostics.TraceImpl.get_Listeners () [0x0] in  unknown>:0
>   at System.Diagnostics.TraceImpl.get_ListenersSyncRoot () [0x0] in
> :0
>   at System.Diagnostics.TraceImpl.WriteLine (System.String message)
> [0x0] in :0
>   at System.Diagnostics.Debug.WriteLine (System.String format,
> System.Object[] args) [0x0] in :0
>   at Warehouse.Data.Str.WriteDebugMessage (System.String message,
> System.Object[] args) [0x0] in :0
>   at Warehouse.Portal.Sync.Api.SyncPoll.GetCommand (System.Byte[] encIV,
> System.Byte[] encKey, System.Byte[] encParams) [0x0] in  unknown>:0
>   at (wrapper managed-to-native)
> System.Reflection.MonoMethod:InternalInvoke
> (System.Reflection.MonoMethod,object,object[],System.Exception&)
>   at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags
> invokeAttr, System.Reflection.Binder binder, System.Object[] parameters,
> System.Globalization.CultureInfo culture) [0x0] in :0
>
> after "sudo service apache2 restart" everything continued to work properly.
> Something causes the configuration to become messed up in (what looks
> like) random or heavy load situations and this makes everything go south.
>
> Unfortunately it looks like this part of mono is not in the primary (or
> maybe in no) focus for the Xamarin team so my best bet here is to:
> 1. Use the open source way, find and fix it myself and hope that we will
> have this change in the official mono one day.
> 2. Move to a Windows server with IIS which I know is not a secondary focus
> for MS.
>
> - Vladimir
>
>
> On 21.8.2013 г. 16:16 ч., Vladimir Dimitrov wrote:
>
> I got to this point in the sources too, but I have no idea what I can do
> or why didn't many other people got the same problem?
>
> On 21.8.2013 г. 15:20 ч., Rafael Teixeira wrote:
>
> From sources (
> https://github.com/mono/mono/blob/master/mcs/class/System.Web.Services/System.Web.Services.Protocols/SoapDocumentationHandler.cs
> ):
>
>
>   if (key == "wsdl" || key == "schema" || key == "code" 
> || key == "disco")
>   return;
>
> #if NET_2_0
>
>   string help = 
> WebServicesSection.Current.WsdlHelpGenerator.Href;
>   string path = Path.GetDirectoryName 
> (ConfigurationManager.OpenMachineConfiguration().FilePath);
> #else
>
>   string help = WSConfig.Instance.WsdlHelpPage;
>   string path = Path.GetDirectoryName 
> (WSConfig.Instance.ConfigFilePath);
> #endif
>   *...*
>   string physPath = Path.Combine (path, help);
>
>
>  So probably WebServicesSection.Current.WsdlHelpGenerator.Href is
> returning null or ConfigurationManager.OpenMachineConfiguration().FilePath
> is returning null.
>
>  For the first case, as this is read from current configuration which can
> be reread from time to time as any part of the configuration chain changes
> it is possible that either some of those MonoTodos in
> https://github.com/mono/mono/blob/master/mcs/class/System.Web.Services/System.Web.Services.Configuration/WsdlHelpGeneratorElement.cs?source=cc
>  are
> making things flaky:
>
>  [MonoTODO ("probably verifies the Href property here, after 
> deserializing?")]
>
>
>   protected override void DeserializeElement (XmlReader reader, 
> bool serializeCollectionKey)
>   {
>   base.DeserializeElement (reader, 
> serializeCollectionKey);
>   }
>   [MonoTODO]
>   protected override void Reset (ConfigurationElement 
> parentElement)
>   {
>   base.Reset (parentElement);
>   }
>
>
>  or some locking is missing to avoid reading an incomplete current
> configuration instance...
>
>  As for the second case after much navigating through sources it comes
> down to calling an internal call 'string get_machine_config_path ()'
> which I don't have time now to try to explore...
>
>  Hope it helps,
>
> Rafael Teixeira
> O..:.)
>
>
> On Wed, Aug 21, 2013 at 8:05 AM, Vladimir 

Re: [Mono-dev] Random mono apache errors

2013-08-26 Thread Vladimir Dimitrov
Almost the same thing just happened again. I got this error when calling 
a web service on the apache/mono server:


System.Exception: INTERNAL configuration error: failed to get 
configuration 'system.diagnostics'
  at System.Diagnostics.DiagnosticsConfiguration.get_Settings () 
[0x0] in :0
  at System.Diagnostics.TraceImpl.InitOnce () [0x0] in unknown>:0
  at System.Diagnostics.TraceImpl.get_Listeners () [0x0] in 
:0
  at System.Diagnostics.TraceImpl.get_ListenersSyncRoot () [0x0] in 
:0
  at System.Diagnostics.TraceImpl.WriteLine (System.String message) 
[0x0] in :0
  at System.Diagnostics.Debug.WriteLine (System.String format, 
System.Object[] args) [0x0] in :0
  at Warehouse.Data.Str.WriteDebugMessage (System.String message, 
System.Object[] args) [0x0] in :0
  at Warehouse.Portal.Sync.Api.SyncPoll.GetCommand (System.Byte[] 
encIV, System.Byte[] encKey, System.Byte[] encParams) [0x0] in 
:0
  at (wrapper managed-to-native) 
System.Reflection.MonoMethod:InternalInvoke 
(System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, 
BindingFlags invokeAttr, System.Reflection.Binder binder, 
System.Object[] parameters, System.Globalization.CultureInfo culture) 
[0x0] in :0


after "sudo service apache2 restart" everything continued to work properly.
Something causes the configuration to become messed up in (what looks 
like) random or heavy load situations and this makes everything go south.


Unfortunately it looks like this part of mono is not in the primary (or 
maybe in no) focus for the Xamarin team so my best bet here is to:
1. Use the open source way, find and fix it myself and hope that we will 
have this change in the official mono one day.
2. Move to a Windows server with IIS which I know is not a secondary 
focus for MS.


- Vladimir

On 21.8.2013 г. 16:16 ч., Vladimir Dimitrov wrote:
I got to this point in the sources too, but I have no idea what I can 
do or why didn't many other people got the same problem?


On 21.8.2013 г. 15:20 ч., Rafael Teixeira wrote:
From sources 
(https://github.com/mono/mono/blob/master/mcs/class/System.Web.Services/System.Web.Services.Protocols/SoapDocumentationHandler.cs):


if (key == "wsdl" || key == "schema" || key == "code" || key ==
"disco")

return;
#if NET_2_0
string help = WebServicesSection.Current.WsdlHelpGenerator.Href;

string path = Path.GetDirectoryName
(ConfigurationManager.OpenMachineConfiguration().FilePath);

#else
string help = WSConfig.Instance.WsdlHelpPage;

string path = Path.GetDirectoryName
(WSConfig.Instance.ConfigFilePath);

#endif
*...*

string physPath = Path.Combine (path, help);


So probably WebServicesSection.Current.WsdlHelpGenerator.Href is 
returning null or 
ConfigurationManager.OpenMachineConfiguration().FilePath is returning 
null.


For the first case, as this is read from current configuration which 
can be reread from time to time as any part of the configuration 
chain changes it is possible that either some of those MonoTodos in 
https://github.com/mono/mono/blob/master/mcs/class/System.Web.Services/System.Web.Services.Configuration/WsdlHelpGeneratorElement.cs?source=cc are 
making things flaky:


[MonoTODO ("probably verifies the Href property here, after 
deserializing?")]
protected override void DeserializeElement (XmlReader reader, bool 
serializeCollectionKey)


{
base.DeserializeElement (reader, serializeCollectionKey);

}
[MonoTODO]

protected override void Reset (ConfigurationElement parentElement)

{
base.Reset (parentElement);

}

or some locking is missing to avoid reading an incomplete current 
configuration instance...


As for the second case after much navigating through sources it comes 
down to calling an internal call 'string get_machine_config_path ()' 
which I don't have time now to try to explore...


Hope it helps,

Rafael Teixeira
O..:.)


On Wed, Aug 21, 2013 at 8:05 AM, Vladimir Dimitrov 
mailto:vlad.dimit...@gmail.com>> wrote:


Hey guys,

I have worked with mono for almost 7 years but I recently got
involved in a project that used mono web services and apache
together on Linux.

The problem is that as the load on the service started to rise we
started getting different errors which appear in random intervals.

One of the errors is described here:
https://bugzilla.novell.com/show_bug.cgi?id=522631 (not by me).
And attempting to fix it I added some configuration that caused
another error to appear once:
http://img577.imageshack.us/img577/4473/44in.png

The only common spot between the errors seem to be the
configuration. Looks like at some point it becomes invalid. This
sometimes happens after the service gets restarted, but sometimes
it happens while the service is running normally. A restart of
apache usually fixes the problem.

Does anybody else encountered something sim