arm-elf-eabi-gcc not in PATH

[chileboy]

This is a bug in rockboxdev.sh on Cygwin machines; your build is being stopped once binutils has compiled, before gcc compilation starts, because it failed to remove the temporary directory for the binutils build.

I worked this one out the other day but predictably I forgot about it; I'm going to fix it now. I'll report back when I've sorted the issue

Edit: It should be fine now; update to at least svn r28314 and try again.

torne, really appreciate your attention - I updated to the latest svn and ran rockboxdev.sh again. but it seemed to be running an inordinately long time - it only took about 15 minutes to run yesterday, today after about an hour I started getting suspicious, but I was doing other things (I hate it when work interferes) - just now  (after it was running about 5 hours) I started paying attention, and it seems to be looping between these two points:

Code: [Select]

# Recursively invoke make in the GCC directory to build any
# startfiles (for now).  We must do this just once, passing
# it all the GCC_EXTRA_PARTS as simultaneous goal targets,
# so that rules which cannot execute simultaneously are properly
# serialized.  We indirect through T_TARGET in case any multilib
# directories contain an equals sign, to prevent make from
# interpreting any of the goals as variable assignments.
# We must use cd && make rather than make -C, or else the stage
# number will be embedded in debug information.
and

Code: [Select]

# Now that we have built all the objects, we need to copy
# them back to the GCC directory.  Too many things (other
# in-tree libraries, and DejaGNU) know about the layout
# of the build tree, for now.
Does that make sense?

[torne]

It was only taking 15 minutes before because it was giving up after building binutils, which is a very small portion of the total build. Building gcc takes much, much longer, and I believe there are issues with Cygwin which make it take even longer still; more than five hours is not unheard of. Lots of parts of the gcc build process look identical, so it may just be doing the same thing in lots of different directories.

Other people have been able to build the toolchain fine on Cygwin by just commenting out the line that was the problem; my fix made this unneeded and I don't see any way it could've caused a problem actually compiling anything. (but I haven't actually tried it on Cygwin).

Give it a while longer, I suggest..

[AlexP]

Cygwin is monumentally slow - as Torne says expect multiple hours.

[chileboy]

OK, I understand...unfortunately I had to terminate it because I had to leave the office (and take my laptop with me!).  I'm going to start over on my home desktop PC when I get the time in the next day or two - then I can just let it run indefinitely.

I'll post back with the results.

Thanks again.

ADDITIONAL QUESTION:  If I do an identical Cygwin install on another PC, and run the rockboxdev.sh on that, can I then just copy the entire directory structure back to the original PC when it's done, and be good to go?  Or is it writing into the registry or something as well?

[chileboy]

OK, now I am having another issue...I started over today from scratch on my home desktop...everything seemed like it was OK.  Installed cygwin, downloaded all the packages, grabbed the latest svn. When I started rockboxdev.sh, I turned off the monitor, came back an hour or so later to check on it and saw this:

Code: [Select]

.
.
<lots of seemingly-normal messages>
.
.
echo ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.
o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn-string.o ./fdmatch.o ./fibheap.
o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./g
etopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath
.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partit
ion.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ct
ype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./unlink-if-
ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror
.o ./xstrndup.o > required-list
make[3]: Entering directory `/tmp/rbdev-build/build-gcc/libiberty/testsuite'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/tmp/rbdev-build/build-gcc/libiberty/testsuite'
make[2]: Leaving directory `/tmp/rbdev-build/build-gcc/libiberty'
/bin/sh: line 5:  3756 Aborted                 ( cd ./libiberty && make "DESTDIR
=" "RPATH_ENVVAR=PATH" "TARGET_SUBDIR=arm-elf-eabi" "bindir=/usr/local/bin" "dat
adir=/usr/local/share" "exec_prefix=/usr/local" "includedir=/usr/local/include"
.
.
<more seemingly-normal messages>
.
.

 "CONFIG_SHELL=/bin/sh" "MAKEINFO=makeinfo --split-size=5000000 --split-size=500
0000" 'AR=ar' 'AS=as' 'CC=gcc' 'CXX=g++' 'DLLTOOL=dlltool' 'LD=/usr/lib/gcc/i686
-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld.exe' 'LIPO=lipo' 'NM=nm' 'OBJ
DUMP=objdump' 'RANLIB=ranlib' 'STRIP=strip' 'WINDRES=windres' 'WINDMC=windmc' al
l )
make[1]: *** [all-libiberty] Error 134
make[1]: Leaving directory `/tmp/rbdev-build/build-gcc'
make: *** [all] Error 2


and back at the cygwin prompt.

I went back and double-checked that I had all the correct packages installed, plenty of disk space, etc.  Not sure what's going on now.

--------

Update Monday 25-Oct - Anyone?   tried deleting cygwin and all directories and starting over, with the same result, except that instead of [all-libiberty] Error 134, it happened on [all-libcpp]...

I Googled the error, saw some things that seemed to indicate it is an error returned for an external reason, e.g., security issue (this is being run with admin rights), too many files, etc. - nothing that seems to make sense in this context.
 

[[Saint]]

ADDITIONAL QUESTION:  If I do an identical Cygwin install on another PC, and run the rockboxdev.sh on that, can I then just copy the entire directory structure back to the original PC when it's done, and be good to go?  Or is it writing into the registry or something as well?

Yeah, sure you can.

You can easily set up CygWin on one machine, and then move it to another. Once you have CygWin set up it the way you like it (though I realise you're a long way away from that) it pays to make a backup of it so installation isn't as painful if something goes monumentally wrong with the installation you're using and it can't be recovered.
Uninstalling CygWin is as simple as just deleting the directory in which the installation exists.



[St.]