Hello Peter,
On Thu, 7 Oct 2010 11:54:28 +0200, "Peter Stuge" peter@stuge.se wrote:
Does e.g. the CodeSourcery toolchain really need Cygwin? That would suck.
I don't know CodeSourcery, I use GNU ARM directly from www.gnuarm.com. According to the CodeSourcery FAQ, they do not require Cygwin.
Are there any benefit using CodeSourcery ? I had issues in the past with the firmware using a different GNU ARM version, so I switched back to 4.0.2 which seems to be the same other use on Linux and so far it works OK.
You don't seem to like Cygwin, my experience with it is not that bad, OpenBSC (not with GPRS yet due to the need for the TUN device), OsmocomBB, GNUradio and Airprobe run with minor adjustments (just to name GSM related stuff I use under Cygwin).
Best regards, Dieter
Hi,
Dieter Spaar wrote:
Does e.g. the CodeSourcery toolchain really need Cygwin? That would suck.
I don't know CodeSourcery, I use GNU ARM directly from www.gnuarm.com. According to the CodeSourcery FAQ, they do not require Cygwin.
Ok, I think that's good.
Are there any benefit using CodeSourcery ? I had issues in the past with the firmware using a different GNU ARM version, so I switched back to 4.0.2 which seems to be the same other use on Linux and so far it works OK.
They are both just binary distributions of GCC for ARM. I doubt there are major differences. Maybe CS do more complete testing before they package up their versions, but there's no guarantee.
GNUARM is clearly more focused on GNU environments, so I think it just makes sense that it is Cygwin affine.
You don't seem to like Cygwin, my experience with it is not that bad,
Ah, no, I don't have anything against Cygwin, and I think it's really great in many ways, but it *is* something different than Windows.
CS G++ Lite has the advantage of being plain native Windows programs.
Cygwin people are always very careful to mention that Cygwin is not Windows, and I think their point is sound. Cygwin is an extra layer.
In practise it can be negligeable, just another DLL, but it isn't Windowsy, and for someone who wants Windowsy, Cygwin isn't a really good answer. (But it can save plenty of time instead!)
OpenBSC (not with GPRS yet due to the need for the TUN device),
OpenVPN has one, it's signed too.
OsmocomBB, GNUradio and Airprobe run with minor adjustments (just to name GSM related stuff I use under Cygwin).
Cool, that's proof that Cygwin is pretty good stuff. It doesn't say almost anything about how these projects run on Windows though.
That isn't neccessarily a bad thing at all, evolving the project internally or the featureset or whatever can be much more important than adapting the project to work "on" more operating systems.
//Peter
Here's another one. Regarding the select mechanism (the one in select.c). Other then the serial port and sockets is anything else registered there? Cause I would like to keep sockets for communication after all (but the select function will not work on windows for serial ports handles). So I would use a different mechanism only for serial port scheduling. Cheers, Mihai.
--- On Thu, 10/7/10, Dieter Spaar spaar@mirider.augusta.de wrote:
From: Dieter Spaar spaar@mirider.augusta.de Subject: Re: osmocom on windows To: baseband-devel@lists.osmocom.org Date: Thursday, October 7, 2010, 3:18 PM
Hello Peter,
On Thu, 7 Oct 2010 11:54:28 +0200, "Peter Stuge" peter@stuge.se wrote:
Does e.g. the CodeSourcery toolchain really need Cygwin? That would suck.
I don't know CodeSourcery, I use GNU ARM directly from www.gnuarm.com. According to the CodeSourcery FAQ, they do not require Cygwin.
Are there any benefit using CodeSourcery ? I had issues in the past with the firmware using a different GNU ARM version, so I switched back to 4.0.2 which seems to be the same other use on Linux and so far it works OK.
You don't seem to like Cygwin, my experience with it is not that bad, OpenBSC (not with GPRS yet due to the need for the TUN device), OsmocomBB, GNUradio and Airprobe run with minor adjustments (just to name GSM related stuff I use under Cygwin).
Best regards, Dieter
On 10/21/2010 07:00 PM, eisencah eisenach wrote:
Here's another one. Regarding the select mechanism (the one in select.c). Other then the serial port and sockets is anything else registered there? Cause I would like to keep sockets for communication after all (but the select function will not work on windows for serial ports handles). So I would use a different mechanism only for serial port scheduling. Cheers, Mihai.
well.. we handle the timers with it too.
eisencah eisenach wrote:
I would like to keep sockets for communication after all (but the select function will not work on windows for serial ports handles). So I would use a different mechanism only for serial port scheduling.
I'd suggest abstracting the io and using overlapped on Windows.
//Peter
baseband-devel@lists.osmocom.org