Build failure on 32-bit Mac OS X 10.6

[chenguokai]

Thank you for giving feedback to the stlink project.

In order to allow developers and other contributors to isolate and target your respective issue, please take some time to fill out each of the following items appropriate to your specific problem:

• Programmer/board type: [] (e.g Stlink /v1, /v2, /v2-clone, /v2-1)
• Programmer firmware version: [] (e.g STSW-LINK007 2.27.15)
• Operating system and version: [Mac OS X 10.6 i386] (e.g Linux, Mac OS X, Windows)
• Stlink tools version and/or git commit hash: [v1.6.1] (e.g v1.1.0/git-c722056)
• Stlink commandline tool name: [] (e.g st-info, st-flash, st-util)
• Target chip (and board if applicable): [] (e.g STM32F402VG)

Futher we kindly ask you to describe the detected problem as detailed as possible and to add debug output if available, by using the following template:

Commandline-Output:

Complete log can be found in https://build.macports.org/builders/ports-10.6_i386-builder/builds/13998/steps/install-port/logs/stdio

...
[ 16%] Building C object CMakeFiles/stlink.dir/src/md5.c.o
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_cross_stlink/stlink/work/stlink-1.6.1/src/common.c:1566:18: error: implicit conversion loses integer precision: 'off_t' (aka 'long long') to 'size_t' (aka 'unsigned long') [-Werror,-Wshorten-64-to-32]
    mf->len = st.st_size;
            ~ ~~~^~~~~~~
/opt/local/bin/clang-mp-9.0 -DSTLINK_HAVE_SYS_MMAN_H -DSTLINK_HAVE_UNISTD_H -Dstlink_EXPORTS -I/opt/local/include/libusb-1.0 -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_cross_stlink/stlink/work/stlink-1.6.1/include -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_cross_stlink/stlink/work/build/include/stlink -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_cross_stlink/stlink/work/stlink-1.6.1/include/stlink -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_cross_stlink/stlink/work/stlink-1.6.1/include/stlink/tools -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_cross_stlink/stlink/work/stlink-1.6.1/src -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_cross_stlink/stlink/work/stlink-1.6.1/src/tools  -pipe -Os -DNDEBUG -I/opt/local/include -std=gnu11 -Wall -Wextra -Wshadow -D_FORTIFY_SOURCE=2 -fstrict-aliasing -Wundef -Wformat -Wformat-security -Wmissing-variable-declarations -Wshorten-64-to-32 -Wimplicit-function-declaration -Wredundant-decls -fPIC -O2 -Werror -arch i386 -mmacosx-version-min=10.6 -fPIC   -o CMakeFiles/stlink.dir/src/md5.c.o   -c /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_cross_stlink/stlink/work/stlink-1.6.1/src/md5.c
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_cross_stlink/stlink/work/stlink-1.6.1/src/common.c:1566:18: error: implicit conversion loses integer precision: 'off_t' (aka 'long long') to 'size_t' (aka 'unsigned long') [-Werror,-Wshorten-64-to-32]
    mf->len = st.st_size;
            ~ ~~~^~~~~~~
1 error generated.
make[2]: *** [CMakeFiles/stlink-static.dir/src/common.c.o] Error 1
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_cross_stlink/stlink/work/build'
make[1]: *** [CMakeFiles/stlink-static.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
1 error generated.
make[2]: *** [CMakeFiles/stlink.dir/src/common.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
...

Expected/description:

Should compile without any issues, maybe should take a look at the CI

I really wonder how this can happen with a 32 bit clang CI🤔

Related with #629

NOTICE: This bug report may be closed without further notice, if not enough information is provided!

Thank you for your support.

The stlink project maintainers

[Nightwalker-87]

😞 I thought we had fixed all of this by now...
BTW: Does it happen with previous versions as well (1.6.0, 1.5.1) ?

[chenguokai]

Does it happen with previous versions as well (1.6.0, 1.5.1) ?

Not sure about 1.5.1. A similar build failure in 1.6.0 release was fixed in develop branch by #908

[Nightwalker-87]

Well let's have a look then... Maybe nobody noticed as 10.6 is really old...

[Nightwalker-87]

#908 is just the same codeblock to where this issue is allocated. As you were the previous editor here it would probably make sense if you try to investigate. I don't have access to 10.6, not even on a VM.

[Nightwalker-87]

Related to #909.

[Nightwalker-87]

@chenguokai: Can you test v1.5.1 also? Was this issue fixed with #908?

[chenguokai]

Can you test v1.5.1 also?

v1.5.1 build failed just before compilation with an Error in CMakeLists

CMake Error at CMakeLists.txt:121 (set_target_properties):
  set_target_properties called with incorrect number of arguments.


-- Manpage generation disabled
-- Configuring incomplete, errors occurred!
See also "/Users/xim/Documents/stlink/build/Release/CMakeFiles/CMakeOutput.log".
See also "/Users/xim/Documents/stlink/build/Release/CMakeFiles/CMakeError.log".
make: *** [build/Release] Error 1

[Nightwalker-87]

Oh, sorry. I forgot to mention to test with the v1.5.1-patch test-branch, which fixed a version number readout error at the beginning of the compile process. The v1.5.1 will not work for sure.

[chenguokai]

v1.5.1-patch failed with yet another warning related to 64-bit value shortened to 32-bit.

Scanning dependencies of target stlink-static
[  3%] Building C object CMakeFiles/stlink-static.dir/src/chipid.c.o
[  6%] Building C object CMakeFiles/stlink-static.dir/src/common.c.o
cc1: warnings being treated as errors
/Users/xim/Documents/stlink/src/common.c: In function ‘set_flash_cr_pg’:
/Users/xim/Documents/stlink/src/common.c:296: warning: implicit conversion shortens 64-bit value into a 32-bit value
/Users/xim/Documents/stlink/src/common.c: In function ‘write_flash_cr_bker_pnb’:
/Users/xim/Documents/stlink/src/common.c:522: warning: implicit conversion shortens 64-bit value into a 32-bit value
/Users/xim/Documents/stlink/src/common.c:523: warning: implicit conversion shortens 64-bit value into a 32-bit value
/Users/xim/Documents/stlink/src/common.c:527: warning: implicit conversion shortens 64-bit value into a 32-bit value
/Users/xim/Documents/stlink/src/common.c:527: warning: implicit conversion shortens 64-bit value into a 32-bit value
/Users/xim/Documents/stlink/src/common.c: In function ‘calculate_L4_page’:
/Users/xim/Documents/stlink/src/common.c:1439: warning: implicit conversion shortens 64-bit value into a 32-bit value
/Users/xim/Documents/stlink/src/common.c:1448: warning: implicit conversion shortens 64-bit value into a 32-bit value
/Users/xim/Documents/stlink/src/common.c: In function ‘stlink_erase_flash_mass’:
/Users/xim/Documents/stlink/src/common.c:1653: warning: implicit conversion shortens 64-bit value into a 32-bit value
make[3]: *** [CMakeFiles/stlink-static.dir/src/common.c.o] Error 1
make[2]: *** [CMakeFiles/stlink-static.dir/all] Error 2
make[1]: *** [all] Error 2
make: *** [release] Error 2

[Nightwalker-87]

Ah ok, but that one was fixed in #919, right? So this issue was not visible before v1.6.1.

[chenguokai]

So this issue was not visible before v1.6.1.

yes

[Nightwalker-87]

What about the current state of our develop branch? Does it have any effect on the output?

[chenguokai]

Unfortunately develop failed.

Scanning dependencies of target stlink-static
[  2%] Building C object CMakeFiles/stlink-static.dir/src/common.c.o
cc1: warnings being treated as errors
/Users/xim/Documents/stlink/src/common.c: In function ‘calculate_H7_sectornum’:
/Users/xim/Documents/stlink/src/common.c:2331: warning: implicit conversion shortens 64-bit value into a 32-bit value
/Users/xim/Documents/stlink/src/common.c: In function ‘stlink_read_option_bytes_f7’:
/Users/xim/Documents/stlink/src/common.c:3764: warning: implicit conversion shortens 64-bit value into a 32-bit value
/Users/xim/Documents/stlink/src/common.c:3772: warning: implicit conversion shortens 64-bit value into a 32-bit value
make[3]: *** [CMakeFiles/stlink-static.dir/src/common.c.o] Error 1
make[2]: *** [CMakeFiles/stlink-static.dir/all] Error 2
make[1]: *** [all] Error 2
make: *** [release] Error 2

[Ant-ON]

@chenguokai The second warning should be corrected by the replacement sizeof(uint32_t) to 4. It is also I not clear why uint8_t is used in a loop for (uint8_t counter = 0;.... May be better to use uint32_t.

[Nightwalker-87]

We will not able to test anything on 10.6 with our travis CI build environment for macOS.
Currently it only seems to run correctly with 10.15 due to internal xcode build issues.
I'll try to get 10.14 running again, soon as there is a solution around.
The latter would be the only way to preserve a 32-bit build case for macOS.

[Nightwalker-87]

I have found out that the macOS 10.14 build fails because of:

[ 77%] Linking C executable ../../bin/stlink-gui
ld: framework not found -lCocoa
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [bin/stlink-gui] Error 1
make[1]: *** [src/stlink-gui/CMakeFiles/stlink-gui.dir/all] Error 2
make: *** [all] Error 2

I tried the following addition to CMakeLists.txt but it did not solve the problem:

find_library(COCOA_LIBRARY Cocoa)
target_link_libraries(${STLINK_LIB_SHARED} ${LIBUSB_LIBRARY} ${SSP_LIB} ${ObjC} ${CoreFoundation} ${IOKit} ${COCOA_LIBRARY})

One would need to resolve that first, before we can continue to test 32-bit builds with CI.

Our macOS 10.14 builds on Travis CI builds fail due to the suspicious linker error above.
GitHub Actions currently does not offer any support for earlier versions than macOS 10.15 which retain support for 32-bit.
I have issued a request for a macOS 10.14 environment to the GitHub team.
Without any possibility and/or help from the community on this topic, we would lose the possibility for 32-bit builds on macOS.

[Nightwalker-87]

I can now confirm that the travis CI build test with 10.14.4 and Xcode 10.3 is working - including the 32-bit builds.
So if anyone fancies retesting with earlier macOS or Mac OS X builds - now is the point to do so (e.g. @chenguokai)
I'll leave this open for another week and try to allocate the related fix before closing this ticket as resolved.

[Nightwalker-87]

@clausecker I wonder if the fix for #1175 does address this as well.
The actual cause is not really visible, but the observed errors may go back to st.st_size as well.
I'm not so sure any more if my observations above can serve a verification.
Unfortunately we are missing an older system to test.

[clausecker]

Yes, this sounds like the same issue. The error messages even indicate the same line as the patch I proposed.