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

[Jake Goulding]

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:
>>
>> http://sources.redhat.com/ml/crossgcc/2005-12/msg00084.html
>>
>> 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, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.org