Floating Point Hardware 2 - newlib link problem

--- 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'

--- 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.

--- 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?

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 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?

--- 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.