This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.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".
------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.org
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |