Honored Contributor
Honored Contributorhttp://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif Hi Paolo and everybody,
The problem is solved. The error happened because of the link flags that I passed when the program was linking. At first, I didn't strictly follow Microtronix's linking flags, and just used $(CC) -o <program> $(MYLIBS) $(LDLIBS) And when I changed to $(CC) $(LDFLAGS) -o <program> -lpthread $(MYLIBS) $(LDLIBS) Voila, the program links with no problem. So I guess the lesson learned is if it aint broke, dont mess with it. But thanks Paolo so much for your detailed response. I sure learned new things, and I will try it next time I encountered problems like this again. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif --- Quote Start --- originally posted by paolo.gai+jan 14 2006, 03:21 am--><div class='quotetop'>quote (paolo.gai @ jan 14 2006, 03:21 am)</div>--- quote start ---
<!--quotebegin-shachris23@Jan 14 2006, 03:37 AM it does work when i link to a dummy application. however, is there a way to increase the size though for global pointer though? because we tried compiling and linking the same project under fedora core 4 with the gcc version 3.4.1, and it linked in just fine.
thus, we suspect this is a nios-ii-specific problem?
what does everybody think?
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=12190)
--- quote end ---
--- Quote End --- Yes, because the Nios compiler uses a register to speedup data access. In general you cannot increase the amount of GP-relative memory, but there are two ways: You can either - compile using the -G0 option or, - put your small data (global ints, global chars, ...) inside a struct, or allocate them in another section... you can try something like
int foo __attribute__ ((section (".data"))) = 57;
int bar __attribute__ ((section (".bss"))); // initialized to 0
