Rockbox Technical Forums

Rockbox Development => Starting Development and Compiling => Topic started by: sunami88 on June 13, 2010, 01:56:06 AM

Title: arm-elf-eabi-gcc not in PATH
Post by: sunami88 on June 13, 2010, 01:56:06 AM
I'm using cygwin to compile Rockbox builds. It was working just the other day, I built the latest rev for my Clip+, and the thing even booted, good times.

Today I started it up, did "rm *" in ~/rockbox/build-clip+ to make sure it was clean, and did "../tools/configure" just like I did last time. However now I get this;

Quote
Normal build selected
Using source code root directory: /home/sunami88/rockbox
../tools/configure: line 2834: arm-elf-eabi-gcc: command not found
../tools/configure: line 2841: arm-elf-eabi-ld: command not found
[WARNING] The compiler you must use (arm-elf-eabi-gcc) is not in your path!
[WARNING] this may cause your build to fail since we cannot do the
[WARNING] checks we want now.
Using arm-elf-eabi-ld
Created Makefile

Of course, now it won't compile. I've been back through the Wiki, tried re-installing the packages, editing my PATH, everything. Nothing has changed in this environment from the last time I used it, but it just won't compile.

I'm sure it's got to be some stupid little error or something I'm missing, but I just can't get it. Like I said, it was working fine and now doesn't work at all.
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: saratoga on June 13, 2010, 01:59:27 AM
We updated our compiler, so you need to update too.  Rerun rockboxdev.sh and install the eabi compiler.
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: sunami88 on June 13, 2010, 02:37:56 AM
We updated our compiler, so you need to update too.  Rerun rockboxdev.sh and install the eabi compiler.

I got a crap load of errors... I think I'm missing some dependencies. Seems the Wiki article needs to be updated?

Quote
libtool: link: cannot find the library `/usr/lib/libiconv.la' or unhandled argum
ent `/usr/lib/libiconv.la'
make[4]: *** [size.exe] Error 1
make[4]: Leaving directory `/tmp/rbdev-build/build-binutils/binutils'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/tmp/rbdev-build/build-binutils/binutils'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/rbdev-build/build-binutils/binutils'
make[1]: *** [all-binutils] Error 2
make[1]: Leaving directory `/tmp/rbdev-build/build-binutils'
make: *** [all] Error 2

I'm installing libtool right now, hopefully that'll fix it up.

As an aside, what is the best way of keeping informed about this kind of update (short of signing up for the mailing list and reading every email).

Addendum: I have my RSS reader set to parse the Twitter feed for all changes made to the players I own, but unless something very specific is posted in the Subersion (e.g. "FuzeV2/Clip+/as3535v2/etc is built with eabi compiler now, run rockboxdev.sh to avoid compiler errors"), I miss it.

EDIT:
Now I'm getting
Quote
ROCKBOXDEV: extracting binutils-2.20.1.tar.bz2
ROCKBOXDEV: applying patch binutils-2.20.1-ld-thumb-interwork-long-call.diff
patching file bfd/elf32-arm.c
ROCKBOXDEV: mkdir build-binutils
mkdir: cannot create directory `build-binutils': File exists

...What is the best way to revert the changes after it has failed once?

Stupid question, clearing out /tmp did it. It's late haha.
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: saratoga on June 13, 2010, 02:49:01 AM
I got a crap load of errors... I think I'm missing some dependencies. Seems the Wiki article needs to be updated?

I don't think the wiki ever listed the depencies, so it should be up to date.

As an aside, what is the best way of keeping informed about this kind of update (short of signing up for the mailing list and reading every email).

dev list.  But really, the message telling you that you don't have the compiler it wants to use installed should be a clue that theres a new compiler needed :)
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: sunami88 on June 13, 2010, 03:07:19 AM
I don't think the wiki ever listed the depencies, so it should be up to date.

For using cygwin, it does (http://www.rockbox.org/wiki/CygwinDevelopment). I should've been more specific as to which wiki article, but again with it being late: seems to be when I do most of my Rockboxing... Anyways I'll make the appropriate changes to the article assuming I don't fall asleep before I get it compiling. Far as I figure right now, at least Devel - libtool needs to be added to Section 2.1 - Package Selection (http://www.rockbox.org/wiki/CygwinDevelopment#Step_2_Install_the_base_developm).


dev list.  But really, the message telling you that you don't have the compiler it wants to use installed should be a clue that theres a new compiler needed :)


Haha true, but still, running ~/rockbox/tools/rockboxdev.sh to install the new compiler wasn't exactly the first thing that sprang to my mind :P .

EDIT:
And now I've got

Quote
libtool: link: cannot find the library `/usr/lib/libiconv.la' or unhandled argum
ent `/usr/lib/libiconv.la'
make[4]: *** [size.exe] Error 1
make[4]: Leaving directory `/tmp/rbdev-build/build-binutils/binutils'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/tmp/rbdev-build/build-binutils/binutils'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/rbdev-build/build-binutils/binutils'
make[1]: *** [all-binutils] Error 2
make[1]: Leaving directory `/tmp/rbdev-build/build-binutils'
make: *** [all] Error 2

So I'll try Devel - libiconv now? I'm really just playing whack-a-mole here...

EDIT2:
Stupid thing keeps stalling on random files now. It gets to downloading a certain file, and just stops.

Quote
ROCKBOXDEV: Downloading http://mirrors.kernel.org/gnu/gcc/gcc-4.4.4/gcc-core-4.4
.4.tar.bz2 using wget
--2010-06-13 13:58:18--  http://mirrors.kernel.org/gnu/gcc/gcc-4.4.4/gcc-core-4.
4.4.tar.bz2
Resolving mirrors.kernel.org... 204.152.191.39, 149.20.20.135
Connecting to mirrors.kernel.org|204.152.191.39|:80... connected.
HTTP request sent, awaiting response...

The last 3 times I've tried it's been a different file it's stalled on. This has nothing to do with my internet connection as it's quite good, and I haven't had any problems browsing around. What a migraine, it's gotta be after it's been compiling for ~30 minutes.
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: funman on June 13, 2010, 04:29:27 PM
Download it from firefox or something and put it in /tmp/rbdev-dl (or whatever the download folder is named), then re-run the script
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: sunami88 on June 14, 2010, 02:33:04 AM
Download it from firefox or something and put it in /tmp/rbdev-dl (or whatever the download folder is named), then re-run the script

Would be a good idea, but the script always baulks at me if tmp/whatever isn't empty. Plus it was always erroring out on different files...

Anyways, I did get the eabi compiler... err, compiled. This took many hours in cygwin... But in the end, I needed;

Quote
Devel - libtool
Devel - libiconv
Web - wget


The wiki page won't let me edit it (Access check on Main.CygwinDevelopment failed. Action "CHANGE": access not allowed on web.), so someone's gonna have to do that. Adding a line about running ~/rockbox/tools/rockboxdev.sh and hitting e to install the compiler if you own a Sansa or other affected model might be a good idea too. Could stop someone else from posting. If it were me, I might put an asterisk beside each of the above 3 items just to denote that they might only be required for targets that utilize the eabi compiler.

Oh and at first I was trying to compile with "make -j" to take advantage of my dual core processor, but this seems to cause many errors, to the point of almost crashing the whole OS (seemed to be when it got to the codecs). Might want to add a line that with the eabi compiler, using make -j is not recommended in cygwin.

Update: nls is correct. It builds just fine on my dual core with "make -j2".

But ya, I have successfully built r26840 for the Clip+, and I will try it out on my FuzeV2 just to be sure a little later. Works fine as of right now though.



Some time later:
Yep, builds for the FuzeV2 just fine as well (I'm listening to some tunes on it right now). r26841 this time.
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: nls on June 14, 2010, 03:44:51 AM
"make -j" can create *lots* of parallell jobs, it's genreally beter to use "make -jX" where X is number of jobs you want, usually around the number of cores you have.
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: oldschool83 on June 15, 2010, 09:36:13 AM
I also cannot get it to run, I get the same path error as you about finding eabi-gcc. I even made a lamer's guide on what I am doing:

1.   Get http://www.cygwin.com/
2.   Run again the installer and select packages:
·   curl
·   wget
·   patch
·   svn
·   make
·   Devel → gcc, gdb
·   Devel → libtool, libiconv
4.   run cygwin, go to \cygwin\home\UserName
5.   type “svn co svn://svn.rockbox.org/rockbox/trunk rockbox“
6.   put the patch inside the new rockbox folder (i.e. the root)
7.   type “patch --binary -p0 < patchfilename“, where patchfilename is the name of patch
8.   mkdir build
9.   cd build
10.   run ../tools/rockboxdev.sh script from inside the build folder
11.   select “e” for “arm-elf-eabi-gcc”. Download and install begins.
12.   export PATH= /usr/local/arm-elf-eabi/bin :$PATH
13.   while in build run ../tools/configure
14.   select the appropriate number for the corresponding device and Normal (N) build

And here I get the error. Both paths /usr/local/arm-elf-eabi/bin and /usr/local/arm-elf-eabi are seen when I type $PATH

Title: Re: arm-elf-eabi-gcc not in PATH
Post by: saratoga on June 15, 2010, 10:46:55 AM
If you type 'which arm-elf-eabi-gcc' does it give you the path to the compiler?
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: oldschool83 on June 15, 2010, 11:33:11 AM
Hm, no..
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: sunami88 on June 15, 2010, 12:33:51 PM
I always ran ./rockboxdev.sh from within tools. It should take a really long time (and only have to complete successfully once!). By "a really long time", I mean a good 7 hours or so on my 1.60Ghz CoreDuo laptop (my 2.66Ghz QuadCore monster desktop being indisposed at the moment). I set it going and walked away for the day...

Also, which arm-elf-eabi-gcc returns "/usr/local/bin/arm-elf-eabi-gcc" as it should... are you sure it finished downloading/compiling? Did you happen to copy what it last said before you tried to compile the latest rev?
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: gevaerts on June 15, 2010, 12:37:15 PM
Did you take into account that the default installation paths recently changed?
Is /usr/local/bin in your PATH?
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: oldschool83 on June 15, 2010, 03:04:17 PM
After running rockboxdev.sh it processes for about an hour or more. Then I get this message:
http://img412.imageshack.us/img412/5681/52905234.jpg

I have no path to arm-elf-eabi, which goes in usr/local after running rockboxdev.

I have no directory called arm-elf-eabi-gcc, which is what I get in the error prompt.

When I type echo $PATH I see /usr/local/bin but no arm-elf-eabi/bin

How can I add it there? I am not exactly sure how to work with export and PATH commands.. Or maybe I am completely missing arm-elf-eabi-gcc. When I run rockboxdev I hit "e" for it and the Clip v2, but I get no such directory in usr/local
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: saratoga on June 15, 2010, 03:07:11 PM
I wouldn't worry about setting the path to your compiler until you manage to get the compiler installed.  Try clearing out all the files downloaded by cygwin and starting the build over.  It also wouldn't hurt to scroll up through that log and make sure thats the first error message generated.
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: torne on June 15, 2010, 03:21:30 PM
Once you get it to actually build successfully, note that you don't need to change the path. The arm-whatever directory does not need to be in your path (and shouldn't be). The actual compiler binaries get installed to /usr/local/bin which is already in your path as you said, and that's all that needs to be there.
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: oldschool83 on June 15, 2010, 03:34:07 PM
Okay, maybe then I am not downloading the right/full gcc component?

Installing the compiler takes about an hour and ends with the error message.. Should I have a folder arm-elf-eabi-gcc somewhere after installing the compiler?
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: saratoga on June 15, 2010, 03:48:55 PM
Okay, maybe then I am not downloading the right/full gcc component?

Installing the compiler takes about an hour and ends with the error message.. Should I have a folder arm-elf-eabi-gcc somewhere after installing the compiler?

Yeah, but only if you actually get it to install.

FWIW compiling under a VM is about a million times faster then cgywin, so unless you really can't spare a couple GB of disk space or don't have admin access on your box, you might want to use that instead.
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: torne on June 16, 2010, 05:44:48 AM
If it installs successfully you will end up with numerous files named arm-elf-eabi-gcc, arm-elf-eabi-ld, and so on in /usr/local/bin, and also a directory /usr/local/arm-elf-eabi.
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: oldschool83 on June 16, 2010, 06:44:08 AM
Ok, I am not getting the arm-elf-eabi-gcc file in usr\local\bin. What am I doing wrong? Maybe I am missing some cygwin component from the initial setup of the program?

By the way, I ran rockboxdev.sh today on another PC and it has been processing for almost 5 hours now.. the arm-elf-eabi-ld file and the /usr/local/arm-elf-eabi folder were created all within the first hour. But I still don't have an arm-elf-eabi-gcc file...
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: marc2003 on June 16, 2010, 07:24:46 AM
5 hours? that's just ridiculous.....

it took me around 10 minutes to install ubuntu from scratch inside a virtual machine. it then took another 10 minutes or so to run rockboxdev.sh to setup eabi...

(obviously you need to add whatever time it takes to download the 700mb ISO for ubuntu)

screenshot (http://dtpbeg.blu.livefilestore.com/y1ps33tsBZfRLy6guRB1xVAvc9D58oBhCijMD_xZtuPTi90pqOq94onD6quWZRmDOl49r0XIgE-TBiJBA8Ir44gfQsxilNCuknD/vmware.png?psid=1)





Title: Re: arm-elf-eabi-gcc not in PATH
Post by: oldschool83 on June 16, 2010, 07:27:09 AM
I am not a linux guy and I find cygwin okay to work with.. don't want to go any deep into VM & etc.

If this doesn't work I'll just forget it. Btw it's still compiling.. 6 hours now and still no arm-elf-eabi-gcc file
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: marc2003 on June 16, 2010, 07:37:40 AM
you don't have to be a linux guy. i'm certainly not. the setup wizard is like windows, you enter a few preferences, click next, next, next and let it do it's thing.

when you're on the desktop, you open a terminal and the commands are the same as you run in cygwin.
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: oldschool83 on June 16, 2010, 11:06:00 AM
What do you know.. it worked!

Don't know what I did, maybe selected more gcc components from the install of cygwin. It compiled for hours and finally said DONE!
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: Jack Sparrow on June 22, 2010, 12:50:40 PM
I tried to compile and it says "the compiler you must use <arm-elf-eabi-gcc> is not in your path!"  I tried typing rockboxdev.sh and it brings back "rockboxdev.sh: command not found"

Do I need to do something else?  I am new to compiling, and really have no idea what I am doing.  Any help would be greatly appreciated
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: saratoga on June 22, 2010, 12:54:38 PM
I tried to compile and it says "the compiler you must use <arm-elf-eabi-gcc> is not in your path!"  I tried typing rockboxdev.sh and it brings back "rockboxdev.sh: command not found"

Do I need to do something else?  I am new to compiling, and really have no idea what I am doing.  Any help would be greatly appreciated

rockboxdev.sh is an actual program in the tools directory of your rockbox source checkout, not a generic shell command.  You have to cd to the right folder, or type the full path to it (e.g. tools/rockboxdev.sh if in the root of your source checkout).
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: Jack Sparrow on June 22, 2010, 02:36:19 PM
rockboxdev.sh is an actual program in the tools directory of your rockbox source checkout, not a generic shell command.  You have to cd to the right folder, or type the full path to it (e.g. tools/rockboxdev.sh if in the root of your source checkout).

Once I cd to the right folder, then what do I do?
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: saratoga on June 22, 2010, 07:09:10 PM
Run the command.  On Ubuntu and most linux this will probably involve something like 'sudo ./rockboxdev.sh'. 
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: Jack Sparrow on June 23, 2010, 10:01:01 AM
Thanks.  I've been running it for about 3 and a half hours now, and it still isn't done.  Any idea how long it should take?

...make that four hours
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: funman on June 23, 2010, 11:13:06 AM
Someone reported ten hours on cygwin.

I think it builds in 15 minutes max on linux.
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: [Saint] on June 23, 2010, 11:50:07 AM
For cygwin, the only thing that should need to be in the PATH is "usr/local/bin/" and this is a default PATH of cygwin...so you shouldn't have to edit anything.
This assumes of course that your cygwin install is running/complete and that you ran rockboxdev.sh (quite recently) without changing where the cross-compilers install to.


[St.]
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: Jack Sparrow on June 23, 2010, 12:46:02 PM
Thanks for everyone's help.  It finished after about 5 hours and I am now compiling
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: Kalin on July 02, 2010, 02:52:37 AM
Hi there!

I'm new here in both the dev of rockbox and forums, and I'm feeling a bit lost on some things, but I'm trying to do my best :)

I'm developing under Mac OS X, and I have the same problem as some of you with the arm-elf-eabi-gcc compiler, that seems to not been install, whatever I try. I've already tried to run rockbox.sh with the "e" parameter in order to install de arm-elf-eabi compiler, but it seems not to work. I'm getting the "is not in your path" error, and navigating to "/usr/local" there is no "bin" directory in there (¿?). I've tried to create it manually and execute the rockboxdev.sh again, but still it seems to not create any arm-elf-whatever file or directory...

Any clue on this?? Those who had the same problem, I don't understand how you finally manage to get the compiler to install. How do you achive it??

Thank you very much!
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: Kalin on July 05, 2010, 01:40:16 AM
Anyone? :'(

I don't know what to do. I've followed all the steps of the quick guide for compilling rockbox and I don't know why the arm-elf-eabi compiler is not installing on my system. Maybe is there some kind of incompatibility with Mac OS X? If I type "which arm-elf-eabi-gcc" I'm getting anything, and if I browse to usr/local/bin there aren't any arm-elf... files anywhere. When I run the "rockboxdev.sh" script, it finishes with some errors, but they aren't specified:
Code: [Select]
make[2]: *** [libgcc.a] Abort trap
make[2]: *** Deleting file `libgcc.a'
make[1]: *** [stmp-multilib] Error 2
make: *** [all-gcc] Error 2


And this is the error I get trying to compile:
Code: [Select]
../tools/configure: line 2837: arm-elf-eabi-gcc: command not found
[WARNING] The compiler you must use (arm-elf-eabi-gcc) is not in your path!
[WARNING] this may cause your build to fail since we cannot do the
[WARNING] checks we want now.
Using arm-elf-eabi-ld ..2842---
Created Makefile

I've also tryed to manually modify the PATH string by adding this:
Code: [Select]
/usr/local/arm-elf/bin:/usr/local/m68mk-elf/bin:/usr/local/sh-elf/bin:/usr/local/arm-elf-eabi:/usr/local/arm-elf-eabi/binBut doesn't change anything
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: torne on July 05, 2010, 05:33:39 AM
Anyone? :'(

I don't know what to do. I've followed all the steps of the quick guide for compilling rockbox and I don't know why the arm-elf-eabi compiler is not installing on my system. Maybe is there some kind of incompatibility with Mac OS X? If I type "which arm-elf-eabi-gcc" I'm getting anything, and if I browse to usr/local/bin there aren't any arm-elf... files anywhere. When I run the "rockboxdev.sh" script, it finishes with some errors, but they aren't specified:
Code: [Select]
make[2]: *** [libgcc.a] Abort trap
make[2]: *** Deleting file `libgcc.a'
make[1]: *** [stmp-multilib] Error 2
make: *** [all-gcc] Error 2

You need to paste more than that; that doesn't include the command it was running at the time, or anything else useful ;)
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: Kalin on July 05, 2010, 06:39:15 AM
Forget de previous lines of error. There were from installing the arm-elf compiller. These are from the arm-eabi-elf installation (via rockboxdev.sh, of course):
Code: [Select]
libtool: compile:  gcc -no-cpp-precomp -DHAVE_CONFIG_H -I. -I../../binutils-2.20.1/bfd -I. -I../../binutils-
.20.1/bfd -I../../binutils-2.20.1/bfd/../include -I./../intl -DBINDIR=\"/usr/local/bin\" -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Werror -U_FORTIFY_SOURCE -MT elf32-arm.lo -MD -MP -MF .deps/elf32-arm.Tpo -c ../../binutils-
.20.1/bfd/elf32-arm.c -o elf32-arm.o
cc1: warnings being treated as errors
../../binutils-2.20.1/bfd/elf32-arm.c: In function ‘elf32_arm_print_private_bfd_data’:
../../binutils-2.20.1/bfd/elf32-arm.c:10502: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10510: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10512: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10514: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10517: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10520: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10523: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10526: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10529: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10538: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10541: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10543: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10549: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10552: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10554: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10557: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10560: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10567: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10571: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10575: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10578: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10581: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10587: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10594: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10597: warning: format not a string literal and no format arguments
../../binutils-2.20.1/bfd/elf32-arm.c:10602: warning: format not a string literal and no format arguments
make[4]: *** [elf32-arm.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-bfd] Error 2
make: *** [all] Error 2
Hope this piece of code will be enough. If doesn't, just ask for more lines.

Thanks for trying to help, torne :)
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: funman on July 05, 2010, 08:46:51 AM
I could build all the compilers on 10.5.8 but apparently it's not possible on 10.6; at least without a patch that nobody wrote.

You're a bit on your own because most developers here use linux, and OSX tools frequently have incompatibilities with the original GNU tools
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: torne on July 05, 2010, 09:00:42 AM
Add --disable-werror to the arguments for configure, and it might work.
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: Kalin on July 05, 2010, 09:28:32 AM
Add --disable-werror to the arguments for configure, and it might work.
To which instruction may I add this argument? I've tried with rockboxdev.sh, and when introducing the parameters it asks, but nothing changed...

Well, it seems I'd have to try in an Ubuntu OS that I have in another PC...

Thank you both for the tips! ;)
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: torne on July 05, 2010, 09:36:40 AM
Edit rockboxdev.sh and add it to the end of the line that says:
Code: [Select]
CFLAGS=-U_FORTIFY_SOURCE ../$toolname-$version/configure --target=$target --prefix=$prefix --enable-languages=c --disable-libssp --disable-docs $configure_params
binutils treats all warnings as errors by default, but it's being built by your host compiler and your host compiler is not guaranteed to be entirely happy with it. --disable-werror tells it to let warnings slide :)
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: Kalin on July 05, 2010, 10:56:34 AM
Edit rockboxdev.sh and add it to the end of the line that says:
Code: [Select]
CFLAGS=-U_FORTIFY_SOURCE ../$toolname-$version/configure --target=$target --prefix=$prefix --enable-languages=c --disable-libssp --disable-docs $configure_params
binutils treats all warnings as errors by default, but it's being built by your host compiler and your host compiler is not guaranteed to be entirely happy with it. --disable-werror tells it to let warnings slide :)
Thank you! I'll try in the future. No problems compiling in Ubuntu 10.04! :D

By the meantime I'd develope in Ubuntu, since it seems to be full compatible and I don't have to be playing with any work-arround for compiling. Thank you very much for the help, and sorry for my english...

Cheers! ;)
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: chileboy on October 19, 2010, 02:09:11 PM
I need to resurrect this thread...

I have followed the wiki carefully (I think).  After getting Cygwin installed, when I first ran rockboxdev.sh, I got some complaint about not finding libiconv, so I re-ran Setup and installed that (although not referenced in the wiki).  After that, rockboxdev.sh seemed to run ok except for the following warnings (I piped the output to a text file just to be sure I wasn't missing anything) - not sure if these are significant or not:

Code: [Select]
../../binutils-2.20.1/libiberty/choose-temp.c: In function `choose_temp_base':
../../binutils-2.20.1/libiberty/choose-temp.c:68: warning: call to `mktemp' decl
ared with attribute warning: the use of `mktemp' is dangerous; use `mkstemp' ins
tead
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared l
ibraries
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared l
ibraries
syslex.c:1272: warning: `yyunput' defined but not used
syslex.c:1315: warning: `input' defined but not used
arlex.c:1397: warning: `yyunput' defined but not used
arlex.c:1440: warning: `input' defined but not used
/Users/gingold/Repositories/fsf/binutils-2_20/ld/ldlex.c:3362: warning: `yyunput
' defined but not used
rm: cannot remove `/tmp/rbdev-build/build-binutils': Device or resource busy

Yet no matter what I have tried, I cannot get arm-elf-eabi-gcc to show up in my usr/local/bin, and of course running configure triggers the "not in PATH" error.

I ran Cygwin setup multiple times, checked my package selection each time to be sure, deleted the tmp directory between installs, etc.

I was getting a bit frustrated, so I thought maybe someone could give me a clue as to what I'm missing.

Thanks.
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: saratoga on October 19, 2010, 02:17:11 PM


I was getting a bit frustrated, so I thought maybe someone could give me a clue as to what I'm missing.



No idea, but IMO cygwin is way more trouble then its worth.  Using a VM is much easier. 
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: torne on October 19, 2010, 04: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.
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: [Saint] on October 19, 2010, 06:37:49 PM
Just a quick note,

If anyone reads this thread...just so they know, it is *not* necessary (as of the eabi changeover) to edit the $PATH variable to include the toolchain in CygWin any more.

By default, the toolchain is built and placed in a $PATH that is one of CygWins defaults...so, there should be no need to edit the path to include the toolchain in a default installation.

I hope this clears up some confusion.



[St.]
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: chileboy on October 20, 2010, 01:43:55 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?
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: torne on October 20, 2010, 02: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..
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: AlexP on October 20, 2010, 04:48:56 PM
Cygwin is monumentally slow - as Torne says expect multiple hours.
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: chileboy on October 20, 2010, 07: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?
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: chileboy on October 25, 2010, 02: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.
 
Title: Re: arm-elf-eabi-gcc not in PATH
Post by: [Saint] on October 25, 2010, 02:37:33 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.]