A little bug in GNU ARM Compiler sniffing

[minou]

For some reasons, even if I change the default directory for the binaries codeblock doesn't find my arm-elf-gcc compiler.

After looking at the source code I found a serious bug. Even though it appears to be possible to change the directory where the compiler is, it is actually impossible to do so because the directory is hard coded to /usr. This creates a problem because all my cross compilers on Mandriva and Fedora are on /opt/cross/bin and I have no intention on changing this. I am patching codeblock to work correctly. The clean way would be to make it a variable or allow m_MasterPath to change as the gui seems to imply that it does.

In compilerGNUARM.c

 m_MasterPath = _T("/usr");

If I create a link to the binary on /usr/bin it is found

[martind]

Hi minou,

What version of code::blocks are you using?
I don't have the problem on the windows platform?

Martin.

[minou]

I have the very last code as of the weekend. You would not see that on the windows version. What I see is that it has a hard coded base directory of "/usr".
There is an option to override that but it doesn't work and the compiler cannot be found unless I create a link to it on /usr/bin

To get a quick fix I changed the code to point to /opt/cross for now. I will look into why it is not working correctly in the next few days.
I want to get familiar with the operation of codeblock. What interest me in codeblock is the debugging part. gdb is working almost perfectly with setedit.
If there are issues in codeblocks I will see to help out, borrowing code from the gdb library used with setedit if necessary.

I have several compilers on /opt/cross/bin and am not willing to change them. This issue is a bit annoying, I have the feeling that it will have similar issues with arm-elf-gdb.

How many people are working on the development for embedded support? Do you need added help?

I have noticed that codeblock is only in English, did I miss something when compiling or is multilanguage not supported? If you need some translation I can help with the French portion.
My work computer is windows in english (I work in Indiana) so when I get home in Michigan I rather have a system on Linux and in French.

[killerbot]

thanks for taking a look at it ;-)

Little question : where can I get hold of the linux version of Gnu Arm compiler ?? (free version)

[Joerg]

www.gnuarm.com

[minou]

You can get it on my web site http://home.comcast.net/~mcatudal

GNUARM is mostly for windows and doesn't have RPM packages for major Linux distributions.
GNUARM distribute codesourcery code which is good but proprietary. If you want completely free distribution that is not the way to go.

My compilers are work in  progress but are are fully functional. They support mix of thumb and arm code as well as ARM 32 bit.
They are based on the free portion of codesourcery code of last year with some fix for interwork support in libraries. I don't like the newlib at all and am working on better library support for ARM7 code to completely replace newlib. I will provide a way to create the libraries from manufacturers code without necessarily including them unless I get approval from them. Their library are always available from their web site. ST is very good for that.

I have 32 bits and 64 bits binaries for Mandriva and Fedora 8. I have tested both binaries on Mandriva and Fedora, they are interchangeable. For those who prefer natives binaries for SuSE don't despair,
I will have them within the next two months. Meanwhile just use the fedora or Mandriva binaries. If you find any issues feel free to let me know.

I will upgrade them soon to have optimizations for Cortex-R4F and Cortex-A9
I do not include any proprietary stuff from codesourcery or anyone else. Contrary to codesourcery my code has full support for NLS so if you prefer your messages to be in French, Spanish or and other language it is possible. Binutils has some issues on that but there is no problem with the compiler and debugger. I am also helping on getting setedit to fully support debugging with arm. So far I got it to work well except that I have to run openocd first and send the correct commands to download the code in RAM or reflash the device. We are working on getting this working perfectly.
I wasn't even aware of the existence of codeblocks until a few weeks ago. I have tried to work with eclipse and found some serious issues with fedora, SuSE and Madriva. Debugging with gdb is not functional with the latest distributions. The immediate solution was to use insight which sucks. Codeblock seems very promising.

I am also working on some documentation and should have them done sometimes this summer. I will provide the information in English first and then in French, with examples for some NXP, Atmel and ST popular development board by IAR and keil.

[killerbot]

I have downloaded the linux versions. Any idea why it stopped at 4.O and no 4.1 nor 4.2 :-(

The zip/package has a top dir 'gnuarm-4.0.2'.
Now what would be the best place to extract it. Based upon the currentCB code to find it, I would suggest : "/usr/gnuarm".
I could modify the CB code accordingly.

Though : I haven't managed to run it yet. It seems the symbolic link files require the directory to be called gnuarm-4.0.2 :-(
to be continued ....



@minou : if in the compiler settings you specify your path does it still fail ??

[minou]

killerbot,

Try mine at http://home.comcast.net/~mcatudal/
I have version 4.2.1 on the net. I will have version 4.2.3 next weekend if I don't have any problem compiling it.

The reason most people are stuck at version 4.0.2 or lower has to do with the fact that a few things have changed and the source has been broken with newer distributions. I had to patch the source to get it to compile. I think that codesourcery uses an older redhat enterprise distribution for theirs. The source code that
they release doesn't compile as is. As for the binary that codesourcery releases for free I think it may be an older version.

If you use their code, you get a warning about the library not linked to support interwork. The commercial version may not have that problem. I prefer to use my own version so I would not know. I haven't had any problem so far with my version of the compiler.

If your Linux is debian or ubuntu you will have to convert the RPM files with alien. They should work with any recent system based on RPM packages.
I don't have SuSE specific binaries but the mandriva or fedora packages should work.

To answer your question, I did try to change the directory as to where the compiler is but it doesn't find it.
The binary is not gnumarm but arm-elf-gcc. There are places where you put the actual name of the binaries, codeblocks should look at that and not at some arbitrary name which may not exist. If does find it if I change the "/usr" string to "/opt/cross" and recompile. The problem must be with the section that looks for an alternative location.

I was planning to do some work on this today but I went to watch a few movies at the cinema instead. I am still mourning the recent death of my younger sister who died of an error in surgery at an hospital in southern France. I was in no mood to do work on the computer today.  I will keep you posted when I get to it and find the problem.

[jalvarez]

A build of the GNU toolchain for ARM is provided by devkitPro. Release 23b includes gcc 4.3.0, gdb 6.8 and newlib 1.16.0. Binaries are available for Windows, x86 Linux, 64-bit x86 Linux and Mac OS X. devkitARM is reliable, free and is updated several times a year.

http://tinyurl.com/devkitARM

http://www.devkitpro.org/category/devkitarm/

[killerbot]

I used to use the one from www.gnuarm.org. But very little updates there lately. I only use it for compiling. Anyone NUArm expert who can tell me what the difference is between the gnuarm.org and the devkitpro ?

[jalvarez]

the difference is between the gnuarm.org and the devkitpro ?

devkitPro is based on a newer GNU toolchain than GNUARM. The gcc and newlib changes are listed on:

http://gcc.gnu.org/gcc-4.3/changes.html

http://sourceware.org/ml/newlib/2007/msg01167.html

Two advantages for ARM developers of the newer GNU toolchain:

1. The newer toolchain can build code for newer ARM processors, such as the ARM Cortex-M3 with thumb2.

2. The object format is EABI instead of ELF. EABI allows you to share object libraries among ARM EABI-compliant compilers (e.g. IAR 5.x, Keil uVision 3). You need to change the prefix on your Makefiles to use arm-eabi-gcc instead of arm-elf-gcc, etc.. There are other EABI advantages for floating point code.

The devkitPro developers appear to be committed to providing a toolchain build that is reliable, updated and can be redistributed freely, along the lines of what GNUARM offered before CodeSourcery became the official maintainer of the GNU toolchain for ARM. The CodeSourcery toolchain works well but even their Lite version has restrictions on redistribution.