Re: [Mono-dev] Problem with mcs build

2016-09-21 Thread Cyd Haselton 
While waiting for a response I deleted the build tree, downloaded another
tarball from the site, unpacked  and re-ran 'autogen.sh && make'

The build errored out at the same place, with the same prior warnings.

At this point I'm at a loss. Any input would be welcome.

On Sep 21, 2016 7:10 AM, "Cyd Haselton"  wrote:

> Pinging again. Any ideas as to where I should be looking for the problem?
>
> FYI, while waiting I dumped the help for the bootstrap compiler for clues
> and found this:
>
> 
> -reference:ALIAS=A   Imports metadata using specified extern alias (short:
> -r)
> -sdk:VERSION Specifies SDK version of referenced
> assemblies  VERSION can be
> one of: 2, 4, 4.5 (default) or a custom value
> 
>
> The command line right before the two warnings and build failure is this:
>
> MONO_PATH="./../class/lib/monolite:$MONO_PATH"
> /data/data/com.termux/files/pkg/ps/mono-4.6.0/runtime/mono-wrapper
> ./../class/lib/monolite/basic.exe /codepage:65001 -sdk:4.5 -r:System.dll
> -r:System.Core.dll -r:System.Xml.dll 
> -d:STATIC,NO_SYMBOL_WRITER,NO_AUTHENTICODE
> -d:MONO_FEATURE_THREAD_ABORT -d:MONO_FEATURE_PROCESS_START  -d:NET_4_0
> -d:NET_4_5 -d:MONO -d:BOOTSTRAP_BASIC -nowarn:1699
> -lib:./../class/lib/basic   -target:exe -out:../class/lib/basic/basic.exe
> cs-parser.cs  @mcs.exe.sources
>
> Should the "-r" params include paths to those files?
>
> On Sep 20, 2016 1:06 PM, "Cyd Haselton"  wrote:
>
>> Any thoughts?  Or is this another stale build?
>>
>> On Tue, Sep 20, 2016 at 8:47 AM, Cyd Haselton 
>> wrote:
>>
>>> Additionally I Googled the warning that appears before the build error:
>>> warning CS8001: SDK path could not be resolved
>>>
>>> The first two hits mention that the cause is usually due to a missing
>>> System.Drawing.dll, but it is present in the build tree under
>>> ./external/binary-reference-assemblies/vX.x, where 'X.x' is  2.0, 4.0
>>> and 4.5.
>>>
>>> Googling the Unhandled Exception error brings up hits from the Unity
>>> forums and not much else.
>>>
>>> On Sep 20, 2016 7:13 AM, "Cyd Haselton"  wrote:
>>>
 While waiting for a response I ran 'make clean' then 'make V=1 2>&1 |
 tee mono_build_log.'

 I've posted the results here: http://pastebin.com/s3gHQQdg

 On Sep 19, 2016 6:02 PM, "Cyd Haselton"  wrote:

> Should I run make clean and try again? Or is there something wrong
> with  the mcs/mcs Makefile?
>
> On Sep 19, 2016 4:33 PM, "Cyd Haselton"  wrote:
>
>> Downloaded latest tarball, ran autogen.sh. It failed at the start of
>> the mcs build because the mono-wrapper, mono and mcs scripts had 
>> #!/bin/sh
>> instead of the correct path.  Fixed that, re-ran make and got the  error
>> from my first email
>>
>> Pastebin here: http://pastebin.com/gdAcRKN6
>>
>> On Sep 19, 2016 2:23 PM, "Cyd Haselton"  wrote:
>>
>>> Er…I *can't* do that because the instructions say that building
>>> from git assumes mono is installed.
>>>
>>> I'll download the latest tarball…
>>>
>>
>>
___
Mono-devel-list mailing list
Mono-devel-list@lists.dot.net
http://lists.dot.net/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Q: difficulties with build for armv5

2016-09-21 Thread Ran Shalit 
On Wed, Sep 21, 2016 at 5:43 PM, Alex Rønne Petersen  wrote:
> Hi,
>
> Mono should just compile out of the box for ARMv5.
>
> What problem are you seeing?
>
> Regards,
> Alex
>

Hi,

This is what I did:
1.
CC=arm-none-linux-gnueabi-gcc CFLAGS="-march=armv5te -mtune=arm926ej-s
-mfloat-abi=soft"  ./autogen.sh --host=arm-none-linux-gnueabi
--disable-mcs-build

(not sure if it correct to give  -mfloat-abi=soft" )

2.
And then in "make" it fails as following:


 CC libmonoruntimesgen_static_la-sgen-tarjan-bridge.lo
  CC libmonoruntimesgen_static_la-sgen-toggleref.lo
  CC libmonoruntimesgen_static_la-sgen-stw.lo
  CC libmonoruntimesgen_static_la-sgen-mono.lo
  CCLD   libmonoruntimesgen-static.la
  CC pedump.o
  CCLD   pedump
./.libs/libmonoruntime.a(libmonoruntime_la-assembly.o): In function
`InterlockedIncrement':
../../mono/utils/atomic.h:234: undefined reference to `__sync_add_and_fetch_4'
./.libs/libmonoruntime.a(libmonoruntime_la-assembly.o): In function
`InterlockedDecrement':
../../mono/utils/atomic.h:239: undefined reference to `__sync_sub_and_fetch_4'
./.libs/libmonoruntime.a(libmonoruntime_la-cominterop.o): In function
`InterlockedDecrement':
../../mono/utils/atomic.h:239: undefined reference to `__sync_sub_and_fetch_4'

Regards,
Ran

> On Wed, Sep 21, 2016 at 4:18 PM, Ran Shalit  wrote:
>> Hello,
>>
>> We encounter difficulties building mono for armv5.
>> I would like to ask if is it possible, and if yes - which version and
>> configure flags should we use ?
>>
>> Thank you!
>> Ran
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.dot.net
>> http://lists.dot.net/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.dot.net
http://lists.dot.net/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Potential bug in NetworkStream in Raspberry ARM – Mono 4.4.0

2016-09-21 Thread David Curylo 
I created a PR for this:

https://github.com/mono/mono/pull/3603 

I submitted the PR for the 4.6 branch, although I would hope we can also put 
this in the current GA 4.4 branch (and master).  I assume multiple PR’s would 
be necessary.

> On Sep 21, 2016, at 4:08 AM, psant...@codicesoftware.com wrote:
> 
> Thanks Dave,
> 
> I was only able to reproduce it (even on LAN) on slow hw like the raspberry 
> and doing parallel requests. Single thread was unable to reproduce the error, 
> I sent several GBs this way. But with 4 threads, it fails in like 8 seconds.
> 
> pablo
> 
> On 9/20/2016 14:30, David Curylo wrote:
>> Pablo,
>> 
>> I couldn’t find evidence of anyone already working on this issue, so I 
>> started on a PR yesterday.  I was a little blind after 8 hours of reading 
>> through tcpdump .pcap files :) but will submit it today with as good of test 
>> coverage as I can get without a remote system.  I’ll post here when I submit 
>> it.
>> 
>> -Dave
>> 
>>> On Sep 20, 2016, at 3:44 AM,  
>>> psant...@codicesoftware.com 
>>>  wrote:
>>> 
>>> Hi David,
>>> 
>>> Great.
>>> 
>>> So, will you make a pull request? Or is there one already in progress?
>>> 
>>> Thanks,
>>> 
>>> pablo
>>> 
>>> On 9/20/2016 3:47, David Curylo wrote:
 I’m glad it helps.  AFAICT a slow network actually _helps_ trigger the 
 issue, guessing it allows the kernel TCP buffers to fill and leads to this 
 issue.
 
 Here is an older mono NetworkStream.Write, which was making up for the 
 issue by continuing to push data through when the buffers filled:
 https://github.com/mono/mono/blob/mono-3.12.1/mcs/class/System/System.Net.Sockets/NetworkStream.cs#L414
  
 
 
 So I expect that will work around your issue, although it needs to be 
 fixed in Socket.cs like the comments 
  in the bug.
 
> On Sep 19, 2016, at 6:12 PM,  
> psant...@codicesoftware.com 
>  wrote:
> 
> Hi David,
> 
> Thanks for the info!!
> 
> So, does this fix the issue?
> 
> while (sent < count)
> {
> sent += mSocket.Send(buffer, offset + sent, count - sent, 
> SocketFlags.None);
> }
> 
> Or am I simply having good luck??
> 
> I'm testing through VPN myself, so maybe the slow network helps. But, we 
> are able to see the same issue on LAN... always using the raspberry as 
> server.
> 
> Thanks,
> 
> pablo
> 
> On 9/19/2016 23:38, David Curylo wrote:
>> Pablo,
>> 
>> I believe I’m experiencing a similar issue, also reported by others 
>> here:  
>> https://bugzilla.xamarin.com/show_bug.cgi?id=43902
>>  
>> 
>> Mono’s Socket.Send doesn’t block until all data is sent.  The old 
>> NetworkStream in mono used to account for this with a while loop to 
>> continue sending, but the NetworkStream from MS Reference Source expects 
>> the Socket to block until all data is sent.  When the reference source 
>> was pulled in, the Socket.Send could sometimes fail to send all the 
>> data.  I can’t ever make this failure occur on localhost, but it will 
>> occur for me communicating with remote hosts.
>> 
>> I’m working on a PR now to have Socket.Send_internal loop until all data 
>> is sent so Socket.Send will block as the reference source expects it to, 
>> unless anyone else has any suggestions.
>> 
>> -Dave
>> 
>>> On Sep 19, 2016, at 9:33 AM,  
>>> psant...@codicesoftware.com 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> I have found a potential issue with NetworkStream on ARM (Raspberry).
>>> 
>>> It might be a stupid bug on my code too, but I don't see it.
>>> 
>>> 
>>> In short: a simple multi-threaded server running on Raspberry (same 
>>> behavior on Mono 4.4.0 as Mono 4.6.0), client on W10:
>>> 
>>> 1. Fails to correctly send data using NetworkStream (server seems to 
>>> send the data, but it never arrives to client).  
>>> https://github.com/psantosl/mono-raspberry-socket-issue/blob/master/Program.cs
>>>  
>>> 
>>> 1.1. Fails *only* using NetworkStream (no BufferedStream or 
>>> BinaryReader/Writer around, and it still fails):  
>>>

Re: [Mono-dev] Q: difficulties with build for armv5

2016-09-21 Thread Alex Rønne Petersen 
Hi,

Mono should just compile out of the box for ARMv5.

What problem are you seeing?

Regards,
Alex

On Wed, Sep 21, 2016 at 4:18 PM, Ran Shalit  wrote:
> Hello,
>
> We encounter difficulties building mono for armv5.
> I would like to ask if is it possible, and if yes - which version and
> configure flags should we use ?
>
> Thank you!
> Ran
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.dot.net
> http://lists.dot.net/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.dot.net
http://lists.dot.net/mailman/listinfo/mono-devel-list

[Mono-dev] Q: difficulties with build for armv5

2016-09-21 Thread Ran Shalit 
Hello,

We encounter difficulties building mono for armv5.
I would like to ask if is it possible, and if yes - which version and
configure flags should we use ?

Thank you!
Ran
___
Mono-devel-list mailing list
Mono-devel-list@lists.dot.net
http://lists.dot.net/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Problem with mcs build

2016-09-21 Thread Cyd Haselton 
Pinging again. Any ideas as to where I should be looking for the problem?

FYI, while waiting I dumped the help for the bootstrap compiler for clues
and found this:


-reference:ALIAS=A   Imports metadata using specified extern alias (short:
-r)
-sdk:VERSION Specifies SDK version of referenced
assemblies  VERSION can be one
of: 2, 4, 4.5 (default) or a custom value


The command line right before the two warnings and build failure is this:

MONO_PATH="./../class/lib/monolite:$MONO_PATH"
/data/data/com.termux/files/pkg/ps/mono-4.6.0/runtime/mono-wrapper
./../class/lib/monolite/basic.exe /codepage:65001 -sdk:4.5 -r:System.dll
-r:System.Core.dll -r:System.Xml.dll
-d:STATIC,NO_SYMBOL_WRITER,NO_AUTHENTICODE -d:MONO_FEATURE_THREAD_ABORT
-d:MONO_FEATURE_PROCESS_START  -d:NET_4_0 -d:NET_4_5 -d:MONO
-d:BOOTSTRAP_BASIC -nowarn:1699 -lib:./../class/lib/basic   -target:exe
-out:../class/lib/basic/basic.exe cs-parser.cs  @mcs.exe.sources

Should the "-r" params include paths to those files?

On Sep 20, 2016 1:06 PM, "Cyd Haselton"  wrote:

> Any thoughts?  Or is this another stale build?
>
> On Tue, Sep 20, 2016 at 8:47 AM, Cyd Haselton  wrote:
>
>> Additionally I Googled the warning that appears before the build error:
>> warning CS8001: SDK path could not be resolved
>>
>> The first two hits mention that the cause is usually due to a missing
>> System.Drawing.dll, but it is present in the build tree under
>> ./external/binary-reference-assemblies/vX.x, where 'X.x' is  2.0, 4.0
>> and 4.5.
>>
>> Googling the Unhandled Exception error brings up hits from the Unity
>> forums and not much else.
>>
>> On Sep 20, 2016 7:13 AM, "Cyd Haselton"  wrote:
>>
>>> While waiting for a response I ran 'make clean' then 'make V=1 2>&1 |
>>> tee mono_build_log.'
>>>
>>> I've posted the results here: http://pastebin.com/s3gHQQdg
>>>
>>> On Sep 19, 2016 6:02 PM, "Cyd Haselton"  wrote:
>>>
 Should I run make clean and try again? Or is there something wrong
 with  the mcs/mcs Makefile?

 On Sep 19, 2016 4:33 PM, "Cyd Haselton"  wrote:

> Downloaded latest tarball, ran autogen.sh. It failed at the start of
> the mcs build because the mono-wrapper, mono and mcs scripts had #!/bin/sh
> instead of the correct path.  Fixed that, re-ran make and got the  error
> from my first email
>
> Pastebin here: http://pastebin.com/gdAcRKN6
>
> On Sep 19, 2016 2:23 PM, "Cyd Haselton"  wrote:
>
>> Er…I *can't* do that because the instructions say that building from
>> git assumes mono is installed.
>>
>> I'll download the latest tarball…
>>
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.dot.net
http://lists.dot.net/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Potential bug in NetworkStream in Raspberry ARM – Mono 4.4.0

2016-09-21 Thread psant...@codicesoftware.com 

  
  
Thanks Dave,
  
  I was only able to reproduce it (even on LAN) on slow hw like the
  raspberry and doing parallel requests. Single thread was unable to
  reproduce the error, I sent several GBs this way. But with 4
  threads, it fails in like 8 seconds.
  
  pablo

On 9/20/2016 14:30, David Curylo wrote:


  
  Pablo,
  
  
  I couldn’t find evidence of anyone already working
on this issue, so I started on a PR yesterday.  I was a little
blind after 8 hours of reading through tcpdump .pcap files :)
but will submit it today with as good of test coverage as I can
get without a remote system.  I’ll post here when I submit it.
  
  
  -Dave
  

  
On Sep 20, 2016, at 3:44 AM, psant...@codicesoftware.com
  wrote:


   Hi David,
  
  Great.
  
  So, will you make a pull request? Or is there one
  already in progress?
  
  Thanks,
  
  pablo

On 9/20/2016 3:47, David
  Curylo wrote:

 I’m glad it helps.  AFAICT a
  slow network actually _helps_ trigger the issue,
  guessing it allows the kernel TCP buffers to fill and
  leads to this issue.
  


Here is an older mono
  NetworkStream.Write, which was making up for the
  issue by continuing to push data through when the
  buffers filled:
https://github.com/mono/mono/blob/mono-3.12.1/mcs/class/System/System.Net.Sockets/NetworkStream.cs#L414


So I expect that will work around your
  issue, although it needs to be fixed in Socket.cs
  like the comments in the bug.

  

  
On Sep 19, 2016, at 6:12 PM, psant...@codicesoftware.com
  wrote:


   Hi
  David,
  
  Thanks for the info!!
  
  So, does this fix the issue?
  
      while (sent < count)
      {
      sent +=
  mSocket.Send(buffer, offset + sent,
  count - sent, SocketFlags.None);
      }
  
  Or am I simply having good luck??
  
  I'm testing through VPN myself, so
  maybe the slow network helps. But, we
  are able to see the same issue on
  LAN... always using the raspberry as
  server.
  
  Thanks,
  
  pablo

On
  9/19/2016 23:38, David Curylo wrote:

 Pablo,
  
  
  I believe I’m
experiencing a similar issue, also
reported by others here: https://bugzilla.xamarin.com/show_bug.cgi?id=43902
  
  
  Mono’s Socket.Send
doesn’t block until all data is
sent.  The old NetworkStream in mono
used to account for this with a
while loop to continue sending, but
the NetworkStream from MS Reference
Source expects the Socket to block
until all data is sent.  When the
reference source was pulled in, the
Socket.Send could sometimes fail to