Rockbox.org home
Downloads
Release release
Dev builds dev builds
Extras extras
themes themes
Documentation
Manual manual
Wiki wiki
Device Status device status
Support
Forums forums
Mailing lists mailing lists
IRC IRC
Development
Bugs bugs
Patches patches
Dev Guide dev guide
Search



Donate

Rockbox Technical Forums


Login with username, password and session length
Home Help Search Staff List Login Register
News:

Welcome to the Rockbox Technical Forums!

+  Rockbox Technical Forums
|-+  Rockbox Development
| |-+  Starting Development and Compiling
| | |-+  arm-elf-eabi-gcc not in PATH
« previous next »
  • Print
Pages: 1 2 3 [4]

Author Topic: arm-elf-eabi-gcc not in PATH  (Read 30244 times)

Offline chileboy

  • Member
  • *
  • Posts: 40
Re: arm-elf-eabi-gcc not in PATH
« Reply #45 on: October 20, 2010, 02:43:55 PM »
Quote from: torne on October 19, 2010, 05:21:50 PM
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?
Logged

Offline torne

  • Developer
  • Member
  • *
  • Posts: 994
  • arf arf
Re: arm-elf-eabi-gcc not in PATH
« Reply #46 on: October 20, 2010, 03:50:04 PM »
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..
Logged
some kind of ARM guy. ipodvideo/gigabeat-s/h120/clipv2. to save time let's assume i know everything.

Offline AlexP

  • Global Moderator
  • Member
  • *
  • Posts: 3688
  • ex-BigBambi
Re: arm-elf-eabi-gcc not in PATH
« Reply #47 on: October 20, 2010, 05:48:56 PM »
Cygwin is monumentally slow - as Torne says expect multiple hours.
Logged
H140, F60, S120, e260, c240, Clip, Fuze v2, Connect, MP170, Meizu M3, Nano 1G, Android

Offline chileboy

  • Member
  • *
  • Posts: 40
Re: arm-elf-eabi-gcc not in PATH
« Reply #48 on: October 20, 2010, 08:13:35 PM »
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?
« Last Edit: October 25, 2010, 03:12:52 PM by chileboy »
Logged

Offline chileboy

  • Member
  • *
  • Posts: 40
Re: arm-elf-eabi-gcc not in PATH
« Reply #49 on: October 25, 2010, 03:13:27 PM »
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.
 
Logged

Offline [Saint]

  • Rockbox Expert
  • Member
  • *
  • Posts: 1662
  • Hayden Pearce
    • Google+
Re: arm-elf-eabi-gcc not in PATH
« Reply #50 on: October 25, 2010, 03:37:33 PM »
Quote from: chileboy on October 20, 2010, 08:13:35 PM
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.]
Logged
Using PMs to annoy devs about bugs/patches is not a good way to have the issue looked at.

  • Print
Pages: 1 2 3 [4]
« previous next »
+  Rockbox Technical Forums
|-+  Rockbox Development
| |-+  Starting Development and Compiling
| | |-+  arm-elf-eabi-gcc not in PATH
 

  • SMF 2.0.17 | SMF © 2019, Simple Machines
  • Rockbox Privacy Policy
  • XHTML
  • RSS
  • WAP2

Page created in 0.135 seconds with 20 queries.