Ubuntu 16.04 ARM version is missing the step for compiling st-flash and then errors in st-info

[gplsquared]

NOTICE: The issue may be closed without notice when not enough information is provided!

Thank you for giving feedback to the stlink project. Take some time to fill out
check boxes with a X in the following items so developers and other people can try to
to find out what is going on. And add/remove what is appropriate to your problem.

When submitting a feature request, try to reuse the list and add/remove what is appropriate.
Place a X between the brackets [X] to mark the list item.

• Programmer/board type: e.g Stlink/v1, Stlink/v2, Stlink/v2-onboard
• Programmer firmware version: e.g STSW-LINK007 2.27.15
• Ubuntu 16.04 ARM version running on Banana Pi M2 Ultra
• Stlink tools version and/or git commit hash: e.g v1.1.0/git-c722056
• st-info, st-flash
• Target chip (and optional board): e.g STM32F402VG (STM32Fxxx Discovery)

A as-detailed description possible of the problem with debug output when available.

Output:
make release
With Ubuntu 14.04 PC compiled output:

[ 20%] Building C object CMakeFiles/stlink-shared.dir/src/logging.c.o
[ 25%] Building C object CMakeFiles/stlink-shared.dir/src/flash_loader.c.o
Linking C shared library libstlink-shared.so
[ 25%] Built target stlink-shared
Scanning dependencies of target st-flash
[ 29%] Building C object CMakeFiles/st-flash.dir/src/tools/flash.c.o
[ 33%] Building C object CMakeFiles/st-flash.dir/src/tools/flash_opts.c.o
Linking C executable st-flash
[ 33%] Built target st-flash
Scanning dependencies of target st-info
[ 37%] Building C object CMakeFiles/st-info.dir/src/tools/info.c.o
Linking C executable st-info
[ 37%] Built target st-info
Scanning dependencies of target stlink-static

OUTPUT/ERROR of the commandline tool(s)

make release
With banana pi m2-ultra running Ubuntu 16.04:

[ 17%] Building C object CMakeFiles/stlink-shared.dir/src/flash_loader.c.o
[ 20%] Linking C shared library libstlink-shared.so
[ 20%] Built target stlink-shared
Scanning dependencies of target st-info
[ 23%] Building C object CMakeFiles/st-info.dir/src/tools/info.c.o
[ 26%] Linking C executable st-info
/usr/lib/gcc/arm-linux-gnueabihf/5/../../../arm-linux-gnueabihf/crt1.o: In function _start': (.text+0x1c): undefined reference to __libc_start_main'
/usr/lib/gcc/arm-linux-gnueabihf/5/../../../arm-linux-gnueabihf/crt1.o: In function _start': (.text+0x20): undefined reference to abort'

Expected/description:
short description of the expected value
It seems the make release for Ubuntu 16.04 ARM version is missing the step for compiling st-flash and then errors in st-info while the PC version running on Ubuntu 14.04 compiles OK.
The source was downloaded as a zip file.

Any ideas what needs fixing?

Thank you,
The stlink project maintainers

[xor-gate]

Thats odd and there is something wrong with your linux install. The C library is not good for some odd reason.

Could you try as below (https://stackoverflow.com/a/8084376/1836746)

This is how I fixed it on ubuntu 11.10:

apt-get remove libc-dev

Say yes to remove all the packages but copy the list to reinstall after.

apt-get install libc-dev

[gplsquared]

Thanks xor-gate - I got the same result after removing and re-installing libc-dev and running make clean and then make release.
I also removed and re-installed libc6-dev - same result.

I can add some more info - the build/Release/CMakeFiles/st-flash.dir/src/tools has two files in the Ubuntu 14.04 PC, but in the banana pi running Ubuntu 16.04, that directory is empty :(

[Nightwalker-87]

the build/Release/CMakeFiles/st-flash.dir/src/tools has two files in the Ubuntu 14.04 PC, but in the banana pi running Ubuntu 16.04, that directory is empty :(
The reason for that likely is that each compilation aborts as soon as the first error appears. All files built until then begin to appear in that build-folder. As both mentioned compilations fail at different steps of progress this is nothing to be surprised about.

However, as mentioned by @xor-gate before, the observed problems appear to have their origin in a broken toolchain. Hence this issue is not related to the stlink toolset itself, which requires a working toolchain to be present on the local system. Against this background I am closing this ticket as resolved.