Floating Point Hardware 2 - newlib link problem

[Altera_Forum]

Altera said that "Floating Point Hardware 2 - newlib link problem" was solved in version 13.1. 

 I am using version 14.1 and I can't make it work:  configure: creating ./config.status config.status: creating Makefile gawk: ./confTgDCOE/subs.awk:1: BEGIN {\r gawk: ./confTgDCOE/subs.awk:1: ^ backslash not last character on line gawk: ./confTgDCOE/subs.awk:1: BEGIN {\r gawk: ./confTgDCOE/subs.awk:1: ^ syntax error config.status: error: could not create Makefile Makefile:9527: recipe for target 'configure-target-newlib' failed make[1]: *** [configure-target-newlib] Error 1 make[1]: Leaving directory '/cygdrive/c/Users/Gus/Project/software/Project_bsp/newlib-build-tmp/smallc' nios2-newlib-gen: Unable to Compile smallc newlib    Does anybody know how to make it work?  Thanks.

[Altera_Forum]

--- Quote Start ---  Altera said that "Floating Point Hardware 2 - newlib link problem" was solved in version 13.1.  I am using version 14.1 and I can't make it work:  configure: creating ./config.status config.status: creating Makefile gawk: ./confTgDCOE/subs.awk:1: BEGIN {\r gawk: ./confTgDCOE/subs.awk:1: ^ backslash not last character on line gawk: ./confTgDCOE/subs.awk:1: BEGIN {\r gawk: ./confTgDCOE/subs.awk:1: ^ syntax error config.status: error: could not create Makefile Makefile:9527: recipe for target 'configure-target-newlib' failed make[1]: *** [configure-target-newlib] Error 1 make[1]: Leaving directory '/cygdrive/c/Users/Gus/Project/software/Project_bsp/newlib-build-tmp/smallc' nios2-newlib-gen: Unable to Compile smallc newlib    Does anybody know how to make it work?  Thanks.  --- Quote End ---    I haven't personally encountered this, but googling the error message turns up http://sourceforge.net/p/mingw-w64/mailman/message/31554323/ which has a suggestion maybe worth trying:  This is a bug in autoconf. It's fixed in newer autoconf versions, butremains in configure scripts that were generated by the old ones.Patch configure script by finding the line: ac_cs_awk_cr='\\r'and replacing it with ac_cs_awk_cr='\r'

[Altera_Forum]

--- Quote Start ---  I haven't personally encountered this, but googling the error message turns up http://sourceforge.net/p/mingw-w64/mailman/message/31554323/ which has a suggestion maybe worth trying:  This is a bug in autoconf. It's fixed in newer autoconf versions, butremains in configure scripts that were generated by the old ones.Patch configure script by finding the line: ac_cs_awk_cr='\\r'and replacing it with ac_cs_awk_cr='\r'  --- Quote End ---    I replaced ac_cs_awk_cr='\\r' by ac_cs_awk_cr='\r', in all files as they presented error during compilation.  I went further, but I still can't make it work .Now, it shows a different error:  C:\altera\14.1\nios2eds\bin\gnu\H-x86_64-mingw32\bin\nios2-elf-ar.exe: unable to rename 'lib.a'; reason: Permission denied Makefile:328: recipe for target 'lib.a' failed  Thanks.

[Altera_Forum]

--- Quote Start ---  I replaced ac_cs_awk_cr='\\r' by ac_cs_awk_cr='\r', in all files as they presented error during compilation.  I went further, but I still can't make it work .Now, it shows a different error:  C:\altera\14.1\nios2eds\bin\gnu\H-x86_64-mingw32\bin\nios2-elf-ar.exe: unable to rename 'lib.a'; reason: Permission denied Makefile:328: recipe for target 'lib.a' failed  Thanks.  --- Quote End ---    Sounds like you are dying in the middle line of lib.a: $(lib_a_OBJECTS) $(lib_a_DEPENDENCIES) $(EXTRA_lib_a_DEPENDENCIES) -rm -f lib.a $(lib_a_AR) lib.a $(lib_a_OBJECTS) $(lib_a_LIBADD) $(RANLIB) lib.a You might try executing it by hand, or experimenting to see if you can in fact rename that lib.a by hand without permission problems?

[Altera_Forum]

I could finally compile it. But I had to enable small C library prior to compile it. Otherwise it doesn't work.  

 After compile it, it works for both small C and normal C library.   The problem is when i run my code with normal C library. The output of performance_counter_report shows some undesired characters and wrong number of occurrences:  --Performance Counter Report-- Total Time: 19.1185 seconds (955926640 clock-cycles) (null)+---------------+-----+-----------+---------------+-----------+ | Section | % | Time (sec)| Time (clocks)|Occurrences| |S1 | 42.3| 8.07839| 403919509| 0| |S2 | 2.74| 0.52319| 26159687| 0| :ˆ‡ÿ¿à:È…ô|S3 | 17.7| 3.37469| 168734374| 0| :ˆ‡ÿ¿à:È…ô|S4 | 14.5| 2.77605| 138802309| 0| |S5 | 14.5| 2.77310| 138655221| 0| |S6 | 7.2| 1.37636| 68817767| 0| |S7 | 0| 0.00000| 0| 0| (null)  with small C, I have this:  --Performance Counter Report-- Total Time : 18942096 usec (947104845 clock-cycles) +---------------+-----+------------+---------------+------------+ | Section | % | Time (usec)| Time (clocks)|Occurrences | +---------------+-----+------------+---------------+------------+ | S1 | 42 | 8072909 | 403645491 | 1 | +---------------+-----+------------+---------------+------------+ | S2 | 2 | 547631 | 27381575 | 2048 | +---------------+-----+------------+---------------+------------+ | S3 | 17 | 3265533 | 163276653 | 2048 | +---------------+-----+------------+---------------+------------+ | S4 | 14 | 2730469 | 136523489 | 1 | +---------------+-----+------------+---------------+------------+ | S5 | 14 | 2730668 | 136533424 | 1 | +---------------+-----+------------+---------------+------------+ | S6 | 7 | 1376920 | 68846005 | 1 | +---------------+-----+------------+---------------+------------+ | S7 | 0 | 0 | 0 | 0 | +---------------+-----+------------+---------------+------------+

[Altera_Forum]

Interesting. In general I would expect normalc to be much better tested than smallc, since smallc is Nios2-specific and normalc is cross-platform and heavily used. You might try boiling down your program to the simplest possible one which displays the problem and then posting it. (Often you'll locate the problem during the boiling-down process.)

[Altera_Forum]

--- Quote Start ---  I could finally compile it. But I had to enable small C library prior to compile it. Otherwise it doesn't work.   After compile it, it works for both small C and normal C library.   The problem is when i run my code with normal C library. The output of performance_counter_report shows some undesired characters and wrong number of occurrences:  --Performance Counter Report-- Total Time: 19.1185 seconds (955926640 clock-cycles) (null)+---------------+-----+-----------+---------------+-----------+ | Section | % | Time (sec)| Time (clocks)|Occurrences| |S1 | 42.3| 8.07839| 403919509| 0| |S2 | 2.74| 0.52319| 26159687| 0| :ˆ‡ÿ¿à:È…ô|S3 | 17.7| 3.37469| 168734374| 0| :ˆ‡ÿ¿à:È…ô|S4 | 14.5| 2.77605| 138802309| 0| |S5 | 14.5| 2.77310| 138655221| 0| |S6 | 7.2| 1.37636| 68817767| 0| |S7 | 0| 0.00000| 0| 0| (null)  with small C, I have this:  --Performance Counter Report-- Total Time : 18942096 usec (947104845 clock-cycles) +---------------+-----+------------+---------------+------------+ | Section | % | Time (usec)| Time (clocks)|Occurrences | +---------------+-----+------------+---------------+------------+ | S1 | 42 | 8072909 | 403645491 | 1 | +---------------+-----+------------+---------------+------------+ | S2 | 2 | 547631 | 27381575 | 2048 | +---------------+-----+------------+---------------+------------+ | S3 | 17 | 3265533 | 163276653 | 2048 | +---------------+-----+------------+---------------+------------+ | S4 | 14 | 2730469 | 136523489 | 1 | +---------------+-----+------------+---------------+------------+ | S5 | 14 | 2730668 | 136533424 | 1 | +---------------+-----+------------+---------------+------------+ | S6 | 7 | 1376920 | 68846005 | 1 | +---------------+-----+------------+---------------+------------+ | S7 | 0 | 0 | 0 | 0 | +---------------+-----+------------+---------------+------------+  --- Quote End ---    gfarhat - can I check with you that your suggested workaround (i.e. to build first for the small C library and then the normal C library) actually gives correctly functioning code at the end of the day? I have not yet been able to run my code but I am suspicious of the BSP when it is built for the Normal C library since it compiles far too quickly (normally, when the BSP successfully builds using the FPH 2 the build time is very long (> 1hour), whereas it is only a minute or two using your workaround. I suspect that a 'clean' is required between BSP builds in order to get the correctly compiled library, however unfortunately this just gives rise to the original problem. Perhaps you have found an alternative fix for this?

[Altera_Forum]

I think you should post the code that generates the normal C summary. It looks like you have a %s corresponding to an uninitialized pointer or something along those lines. But it might be something deeper...

[Altera_Forum]

--- Quote Start ---  I think you should post the code that generates the normal C summary. It looks like you have a %s corresponding to an uninitialized pointer or something along those lines. But it might be something deeper...  --- Quote End ---    Are you referring to the issue of this thread or the fact that my BSP takes >1 hour to build? To set the scene, I have a successfully built application that was developed under Quartus 13.1 (including the FPH 2). On 13.1 the BSP takes > 1 hour to build on a reasonably fast machine with 16 GB RAM. I am now migrating the same design (hardware and software) to Quartus 14.1 and have encountered the issue that is the subject of this thread. I would be keen to improve the BSP build speed when using the FPH 2, however my first concern is to get a successful build, which means fixing the newlib link issue.

[Altera_Forum]

I'm referring to the normalc performance report formatting issue.