Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++

porting newlib

Altera_Forum
Honored Contributor II
1,773 Views

I downloaded newlib 1.14 and got it to compile but now I'm wondering how the NIOS build system decides where to get the libraries during linking. For now I'm just copying my rebuilt libc.a over the old one but I'd like to know how I can tell the linker to use my new newlib. 

 

Does anyone know how to setup include paths and library search paths for the GNU stuff? 

 

For those of you interested in rebuilding newlib, there were a few catches. My tree is totally messed up now but next week I'll try a clean rebuild starting with a freshly untarred source tree and post the results here 

 

- I couldn't get the NIOS SDK shell to work with the new configure and make files from newlib so I installed the latest Cygwin and used that for rebuilding. My new Cygwin didn't have any cc or gcc so there was no danger of picking up the wrong compiler. 

 

- I had to set up the path and alias to nios2-elf-gcc but otherwise the build process worked with ../configure --target=nios2-elf after supplying a libc/machine directory and making the necessary changes to libc/include/machine/ieeefp.h 

 

- I copied the modifications Altera made to the host.configure but one of the# defines seems to have changed. We now need -DMALLOC_PROVIDED instead of -DMALLOC_LOCK_PROVIDED (or maybe both) 

 

- I had some difficulty with the libc/machine/nios2 directory. I copied over some other subdirectory and replaced setjmp.s. That seemed to do the trick 

 

Andrew
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
589 Views

Is there anything in the newest version that you need, or is it just for fun?

0 Kudos
Altera_Forum
Honored Contributor II
589 Views

It started out with a stack problem under uC/OS. I was trying to find out why printf consumes such an obscene amount of stack but when I stepped through it in the debugger I kept having problems with the source and assembly lining up so I decided to rebuild the lib from the existing source. After doing that I could debug ok and found that, yes, printf is a real stack hog. 

 

At that point I thought it might be worthwhile to get the latest newlib working to see if a) the printf stuff was modified and http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/cool.gif be able to get support from the newlib folks. 

 

I also really want to understand how the whole NIOS toolchain works so I can upgrade/replace bits and pieces of it. One of my other quests is to upgrade Eclipse to the latest-greatest so I can use the VSS plugin (then again, I&#39;d really like to dump VSS and go to CVS but that&#39;s another story). 

 

Andrew
0 Kudos
Altera_Forum
Honored Contributor II
589 Views

The only way I got round printf trouble was to write my own (reduced feature set) version. 

 

Only then you know what&#39;s happening.
0 Kudos
Altera_Forum
Honored Contributor II
589 Views

Agreed. Especially since I use printf solely for diagnostics - in the final version of my firmware the printf will do nothing.

0 Kudos
Altera_Forum
Honored Contributor II
589 Views

Did you notice a problem with extremely high CPU Usage (i.e. 100% CPU usage) ???

0 Kudos
Reply