Concurrency Bugs and SPARC Help (was: Cygwin->linux crosscompiler make problem)

Jake Goulding
Fri Jan 27 22:53:00 GMT 2006

Brian Dessent wrote:
>> Sorry, I didn't read all the messages but I think this is he same
>> problem I had with the long paths in tcb-offsets.h.d in cygwin.
>> See my solution here:
>> All I did was making the build path shorter. It looks strange but the
>> toolchain built an work fine !
>> The problems I wrote afterwards in this thread had nothing to do with
>> this, so its really worth a try ;)
> I've used crosstool successfully under Cygwin without having to shorten
> the path or use a managed mount.  But I do have /bin and /usr/bin
> mounted "cygexec" which bypasses any of Windows' command line length
> restrictions when exec'ing processes under those paths.  But this trick
> can only work when a Cygwin process execs another Cygwin process -- so
> whatever paths you mount cygexec have to contain only Cygwin binaries,
> and not native win32 apps.
> The Windows path length restriction of 260 still applies at all times,
> but I did not run into this with a build directory of
> "/e/build/crosstool-0.38".
Thanks for the various bits of information. I actually ended up taking 
the/an easy way out: I simply created a VMWare guest OS with Red Hat 9, 
which has matching versions of everything else on the other RH server. 
According to some reports, I may get up to 80% native speed, so this 
seems a far cry better than Cygwin, with no messy path restrictions to boot.

I guess the next step will be to fix concurrency bugs in my Makefile, 
then see about doing the SPARC version. Any tips for either?

Want more information?  See the CrossGCC FAQ,
Want to unsubscribe? Send a note to

More information about the crossgcc mailing list