search

pine64 / bl_iot_sdk

BL602 SDK (Pine64 fork)
https://pine64.github.io/bl602-docs/
Apache License 2.0
134 stars 58 forks source link

Builds in customer_app fail on MacOS #59

Closed suculent closed 3 years ago

suculent commented 3 years ago

Any idea why this happens? I have no clue, where to find the error... 

/Users/sychram/Repositories/bl_iot_sdk-ubuntu/bl_iot_sdk/toolchain/riscv/Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld: /Users/sychram/Repositories/bl_iot_sdk-ubuntu/bl_iot_sdk/toolchain/riscv/Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/lib/rv64imafdc/lp64d/crt0.o: in function `.L0 ':
(.text+0x2e): undefined reference to `main'

Then at the crt.o file:

bl_iot_sdk/toolchain/riscv/Darwin/riscv64-unknown-elf/lib/rv64imafdc/lp64d$ nm -C ./crt0.o 
0000000000000008 t .L0 
0000000000000010 t .L0 
0000000000000024 t .L0 
0000000000000000 t .L11
                 U __global_pointer$
                 U __libc_fini_array
                 U __libc_init_array
                 U _edata
                 U _end
0000000000000000 T _start
                 U atexit
                 U exit
                 U main
                 U memset

Also in objdump those symbols seem to be undefined indeed.

$ objdump -t ./crt0.o 

./crt0.o:   file format ELF64-riscv

SYMBOL TABLE:
0000000000000000 l    d  .text  00000000 .text
0000000000000000 l    d  .data  00000000 .data
0000000000000000 l    d  .bss   00000000 .bss
0000000000000000         .text  00000000 .L11
0000000000000008         .text  00000000 .L0 
0000000000000010         .text  00000000 .L0 
0000000000000024         .text  00000000 .L0 
0000000000000000 l    d  .riscv.attributes  00000000 .riscv.attributes
0000000000000000 g     F .text  00000052 _start
0000000000000000         *UND*  00000000 __global_pointer$
0000000000000000         *UND*  00000000 _edata
0000000000000000         *UND*  00000000 _end
0000000000000000         *UND*  00000000 memset
0000000000000000         *UND*  00000000 __libc_fini_array
0000000000000000         *UND*  00000000 atexit
0000000000000000         *UND*  00000000 __libc_init_array
0000000000000000         *UND*  00000000 main
0000000000000000         *UND*  00000000 exit

When trying to run the same command in ubuntu-20 docker container, this does not fail.

gamelaster commented 3 years ago

Ahoj, it's strange, but looks like this is toolchain specific. Can't be this related to #25 ? @robertlipe did you encountered this problem on Mac?

robertlipe commented 3 years ago

Yes, and it says so in that report. There is a Linux binary that's checked in that won't, of course, run on MacOS (or Windows) that makes the build fall in the final stages.

Since I didn't have hardware to test flashing, I left it to someone that did.

It DOES seem odd that the default make target is trying to flash the board at all.

On Sat, Oct 31, 2020, 2:55 PM Marek Kraus notifications@github.com wrote:

Ahoj, it's strange, but looks like this is toolchain specific. Can't be this related to #25 https://github.com/pine64/bl_iot_sdk/issues/25 ? @robertlipe https://github.com/robertlipe did you encountered this problem on Mac?

ā€” You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pine64/bl_iot_sdk/issues/59#issuecomment-719980296, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD3ZR5D25QHG3WQLLSE3SNRTRNANCNFSM4TGCDFBA .

gamelaster commented 3 years ago

@robertlipe Thanks for fast reaction! Well, even I don't have the EVB yet, so can't check out. The one evb is on the road to you šŸ˜Š

suculent commented 3 years ago

OK, but which file is it in my case, apart from the flash_build?

I'm failing in the gcc linker stage.

Trying to build the toolchain from scratch... but it will expectedly take whole night.

M.

On 31 Oct 2020, at 21:02, Robert Lipe notifications@github.com wrote:

Yes, and it says so in that report. There is a Linux binary that's checked in that won't, of course, run on MacOS (or Windows) that makes the build fall in the final stages.

Since I didn't have hardware to test flashing, I left it to someone that did.

It DOES seem odd that the default make target is trying to flash the board at all.

On Sat, Oct 31, 2020, 2:55 PM Marek Kraus notifications@github.com wrote:

Ahoj, it's strange, but looks like this is toolchain specific. Can't be this related to #25 https://github.com/pine64/bl_iot_sdk/issues/25 ? @robertlipe https://github.com/robertlipe did you encountered this problem on Mac?

ā€” You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pine64/bl_iot_sdk/issues/59#issuecomment-719980296, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD3ZR5D25QHG3WQLLSE3SNRTRNANCNFSM4TGCDFBA .

ā€” You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/pine64/bl_iot_sdk/issues/59#issuecomment-719981151, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABWFR3DJBUOSTJOB5V4SJLSNRUNNANCNFSM4TGCDFBA.

GPSBabelDeveloper commented 3 years ago

The provided MacOS toolchain doesn't do what you're seeing in the OP. That combination of Ubuntu and Darwin is mind bending. I. Suspect you're being punished for mixing them in a weird way.

I also wouldn't build a chain from scratch. The. (Newer) GNU chain provided by Homebrew should work but you may have to sprinkle -mabi=rv32imac style flags around. But on a normal MacOS (and I built the tree on two different ones) box, the provided chain does successfully link executables.

GPSBabelDeveloper commented 3 years ago

This ( ..../riscv64-unknown-elf/lib/rv64imafdc/lp64d$) hints at multilibbing issue. These are 32 bit cores, right? (I'm AFK) the gnu chain can generate either RV32 or RV64, but I understood this core to be RV 32.

Are you sure you're using the provided chain?

robertlipe commented 3 years ago

P. S. robertlipe and GPSBabel are the same human. 99% of my GitHub life is working on my own creation.

On Sat, Oct 31, 2020, 3:19 PM GPSBabel notifications@github.com wrote:

This ( ..../riscv64-unknown-elf/lib/rv64imafdc/lp64d$) hints at multilibbing issue. These are 32 bit cores, right? (I'm AFK) the gnu chain can generate either RV32 or RV64, but I understood this core to be RV 32.

Are you sure you're using the provided chain?

ā€” You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pine64/bl_iot_sdk/issues/59#issuecomment-719983369, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD34XI56OQSMDHUCVQ7LSNRWONANCNFSM4TGCDFBA .

suculent commented 3 years ago

I would love to have an EVB as well. But even without that, I can provide build support in THiNX.

I'm mantaining IoT library with backend/UI (https.//github.com/suculent/thinx-device-api), originally for ESP8266/ESP32 (but also for micropython, nodemcu and mongoose). It's used in production. It would be nice to support RISC-V (we have online builders with git integration, support OTA firmware updates where available, builds parametrized per-device, etc.).

Cheers, Matej

On 31 Oct 2020, at 21:06, Marek Kraus notifications@github.com wrote:

@robertlipe https://github.com/robertlipe Thanks for fast reaction! Well, even I don't have the EVB yet, so can't check out. The one evb is on the road to you šŸ˜Š

ā€” You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/pine64/bl_iot_sdk/issues/59#issuecomment-719981679, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABWFR7OLXJYEEU5UROP423SNRU6HANCNFSM4TGCDFBA.

suculent commented 3 years ago

OK, so I've rebuilt the toolchain from scratch and as @robertlipe mentioned, it didn't help. I'll try the homebrew way tomorrow.

robertlipe commented 3 years ago

Go back to square zero. Are you seeing the failure in the first message with a fresh checkout? Are you doing something more funky than git clone ...; cd ...; (Set the env bar to BL602) ; make?

You seem off the beaten path somewhere. Building you own tools gets you even further off that path.

On Sat, Oct 31, 2020, 5:25 PM Matej Sychra notifications@github.com wrote:

OK, so I've rebuilt the toolchain from scratch and as @robertlipe https://github.com/robertlipe mentioned, it didn't help. I'll try the homebrew way tomorrow.

ā€” You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pine64/bl_iot_sdk/issues/59#issuecomment-719995990, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD3764GI3ABOOJYK3NZLSNSFGTANCNFSM4TGCDFBA .

suculent commented 3 years ago

I'm using clean checkout while having both ENV vars set (while having the same thing everything perfectly working and under CI tests on linux).

$ export
declare -x BL60X_SDK_PATH="/Users/*******/Repositories/bl_iot_sdk-ubuntu/bl_iot_sdk"
declare -x CONFIG_CHIP_NAME="BL602"
...
suculent commented 3 years ago

OK so I've tried this from scratch on another box and ended up with the ./flash_build issue. So I'm back to issue #25 .

robertlipe commented 3 years ago

Ok, you're out of the weeds that affected you uniquely.

The question on #25 is where flash build is supposed to come from.

On Sat, Oct 31, 2020, 6:03 PM Matej Sychra notifications@github.com wrote:

OK so I've tried this from scratch on another box and ended up with the ./flash_build issue. So I'm back to issue #25 https://github.com/pine64/bl_iot_sdk/issues/25 .

ā€” You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pine64/bl_iot_sdk/issues/59#issuecomment-719999404, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD32SCPVSHDEHP6LBA2LSNSJSLANCNFSM4TGCDFBA .

suculent commented 3 years ago

Well, not really. I can't still make it run on my main computer (even after fresh pull).

Meanwhile in make_scripts_riscv/project.mk lines 190/191 show there is a python version of flash_build that can be used instead of the binary. I've just tried to comment the binary and used flash_build.py instead.

I just went to image_conf folder and did pip install -r requirements.txt to make the python script not fail the build.

M.

On 1 Nov 2020, at 00:06, Robert Lipe notifications@github.com wrote:

Ok, you're out of the weeds that affected you uniquely.

The question on #25 is where flash build is supposed to come from.

On Sat, Oct 31, 2020, 6:03 PM Matej Sychra notifications@github.com wrote:

OK so I've tried this from scratch on another box and ended up with the ./flash_build issue. So I'm back to issue #25 https://github.com/pine64/bl_iot_sdk/issues/25 .

ā€” You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pine64/bl_iot_sdk/issues/59#issuecomment-719999404, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD32SCPVSHDEHP6LBA2LSNSJSLANCNFSM4TGCDFBA .

ā€” You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/pine64/bl_iot_sdk/issues/59#issuecomment-719999645, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABWFR2SN5I22ZIA36VDCA3SNSJ5RANCNFSM4TGCDFBA.

robertlipe commented 3 years ago

It's up to you to find the difference in your computers, but just so we're all on the same page. $ pwd [ ... ] l_iot_sdk/customer_app/sdk_app_dac sdk_app_dac % make -j4 V=1 Here we see the relevant invocation of the linker (I've edited this by hand into a script that works to confirm) $HOME/src/bl_iot_sdk/toolchain/riscv/Darwin/bin/riscv64-unknown-elf-gcc -march=rv32imfc \ -mabi=ilp32f \ -Wl,--cref -nostartfiles \ -Wl,--gc-sections \ -Wl,-static \ -Wl,--start-group \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/bl602 \ -L$HOME/src/bl_iot_sdk/components/bl602/bl602/evb/ld \ -T flash.ld \ -lbl602 \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/bl602_std \ -lbl602_std \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/blfdt -lblfdt \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/blmtd -lblmtd \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/blog -lblog \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/blog_testc -lblog_testc \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/bloop -lbloop \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/bltime -lbltime \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/cli -lcli \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/easyflash4 -leasyflash4 \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/freertos_riscv_ram -lfreertos_riscv_ram \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/hal_drv -lhal_drv \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/looprt -llooprt \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/loopset -lloopset \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/romfs -lromfs \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/sdk_app_dac -lsdk_app_dac \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/utils -lutils \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/vfs -lvfs \ -L$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/yloop -lyloop \ -Wl,--end-group \ -Wl,-EL \ -lm \ -o $HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/sdk_app_dac.elf \ -Wl,-Map=$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/sdk_app_dac.map

We've confirmed a couple of things I suspected above: 1) The compiler is a multi-libbed compiler (which is NOT the default built of GCC) 2) The compiler and chain is both 32 and 64-bit capable 3) It's building for 32-bit mode.

We can further prove #2 by running $HOME/src/bl_iot_sdk/toolchain/riscv/Darwin/bin/riscv64-unknown-elf-gcc -dumpspecs

If you do this, you should see a mind-numbing combinations of every RV32 and RV64 ABI you can imagine - and probably more.

My link definitely completed: % file /elf build_out/sdk_app_dac.elf: ELF 32-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically linked, with debug_info, not stripped

The puzzling part of your build is this: rv64imafdc/lp64d/

Why is it trying to build a 64-bit executable? Your shown command is trying 64-bit C runtime (that's the '...rv64...crt0.o') and getting angry because it's not finding a 64-bit object with a main, which it shouldn't because the BL602 code SHOULD be being built for RV32.

Let's change the invocation of the linker (which is invoked by the compiler

$HOME/src/bl_iot_sdk/toolchain/riscv/Darwin/bin/riscv64-unknown-elf-gcc \ -v \ -march=rv32imfc \ -mabi=ilp32f \ (all that other junk)

(heh. we can even see something I said above - you can see the compiler itself was "Configured with ... --enable-multilib") But let's cherry pick a few lines: LIBRARY_PATH=$HOME/src/bl_iot_sdk/toolchain/riscv/Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0 /rv32imf/ilp32f/:/ $HOME/src/bl_iot_sdk/toolchain/riscv/Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/lib/ rv32imf/ilp32f/ :/$HOME/src/bl_iot_sdk/toolchain/riscv/Darwin/bin/../riscv64-unknown-elf/lib/ rv32imf/ilp32f/ :/$HOME/src/bl_iot_sdk/toolchain/riscv/Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/:/$HOME/src/bl_iot_sdk/toolchain/riscv/Darwin/bin/../lib/gcc/:/$HOME/src/bl_iot_sdk/toolchain/riscv/Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/lib/:/$HOME/src/bl_iot_sdk/toolchain/riscv/Darwin/bin/../riscv64-unknown-elf/lib/

Here, order matters. Since our invocation used ilp32f (does this part actually have an FPU?) we see it searches the rv32imfc/ilp32f directories ONLY. I can't recall from my days in GCC guts if this in actual environmental $PATH. Do you perhaps have something weird in your $LIBRARY_PATH?

COLLECT_GCC_OPTIONS='-v' '-march=rv32imfc' '-mabi=ilp32f' '-nostartfiles' [ the recognizable -Lfoo_path/-lfoo pairs ]

That bolded part above is key: If you don't see the -march and -mabi in that path, something has gone very wrong and that would explain why you're getting an rv64 startup with your rv32 code.

Ultimately, you should see collect2 similarly run with very rv32 flags:

.../src/bl_iot_sdk/toolchain/riscv/Darwin/bin/../libexec/gcc/riscv64-unknown-elf/8.3.0/collect2 -plugin [ ... ] -L/$HOME/src/bl_iot_sdk/toolchain/riscv/Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/rv32imf/ilp32f -L$HOME/src/bl_iot_sdk/toolchain/riscv/Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/lib/rv32imf/ilp32f

I think I've shown you about everything I can to help you compare with a "normal" build on MacOS. Something in your build (CFLAGS in your environment?) is sending it down a path for 64-bit stuff when that's just not reality for this tree.

The build ultimately fails as i described with: Target 'component-yloop-build' responsible for '/$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/yloop/libyloop.a'

@cd $HOME/src/bl_iot_sdk/image_conf; python3 flash_build.py

sdk_app_dac BL602 /bin/sh: ./flash_build: cannot execute binary file ...but that's all a bit academic as I don't think that any of us have hardware to flash TO at this point. It's definitely NOT going to execute that Linux binary.

Does this help? There's a lot of data here, but I hope this at least gives you the "teach a man to fish" approach to seeing WHERE your build is leaving the rails.

RJL

keyguru commented 3 years ago

So I've went similar path, called the make clean && make -j4 V=1 in sdk_app_dac, but last failing linker command (which indeed has suspicious LIBRARY_PATH contents) looks completely different to the one on other MacOS box.

My environments have no default CFLAGS set, although they've been used to build for mostly for x86, ARM and Xtensa cores.

$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/riscv64-unknown-elf-gcc  \
-v \
-L/usr/local/opt/zlib/lib \
-o $HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/sdk_app_dac.elf \
-Wl,-Map=$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/sdk_app_dac.map

Resulting in verbose log, where -march=rv64imagds and -mabi=lp64d (unexpectedly?) appears:

$ $HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/riscv64-unknown-elf-gcc \
> -v \
> -L/usr/local/opt/zlib/lib \
> -o $HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/sdk_app_dac.elf \
> -Wl,-Map=$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/sdk_app_dac.map

Using built-in specs.
COLLECT_GCC=$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/riscv64-unknown-elf-gcc
COLLECT_LTO_WRAPPER=$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../libexec/gcc/riscv64-unknown-elf/8.3.0/lto-wrapper

Target: riscv64-unknown-elf

Configured with: /Users/mac/git/freedom-tools-master/obj/x86_64-apple-darwin/build/riscv-gnu-toolchain/riscv-gcc/configure --target=riscv64-unknown-elf --prefix=/Users/mac/git/freedom-tools-master/obj/x86_64-apple-darwin/install/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-apple-darwin --with-pkgversion='SiFive GCC 8.3.0-2019.08.0' --with-bugurl=https://github.com/sifive/freedom-tools/issues --disable-shared --disable-threads --enable-languages=c,c++ --enable-tls --with-newlib --with-sysroot=/Users/mac/git/freedom-tools-master/obj/x86_64-apple-darwin/install/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-apple-darwin/riscv64-unknown-elf --with-native-system-header-dir=/include --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libgomp --disable-nls --disable-tm-clone-registry --src=../riscv-gcc --with-system-zlib --enable-checking=yes --enable-multilib --with-abi=lp64d --with-arch=rv64imafdc CFLAGS=-O2 CXXFLAGS=-O2 'CFLAGS_FOR_TARGET=-Os  -mcmodel=medany' 'CXXFLAGS_FOR_TARGET=-Os  -mcmodel=medany'

Thread model: single
gcc version 8.3.0 (SiFive GCC 8.3.0-2019.08.0) 

COMPILER_PATH=$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../libexec/gcc/riscv64-unknown-elf/8.3.0/:$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../libexec/gcc/:$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/
LIBRARY_PATH=$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/rv64imafdc/lp64d/:$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/lib/rv64imafdc/lp64d/:$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../riscv64-unknown-elf/lib/rv64imafdc/lp64d/:$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/:$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../lib/gcc/:$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/lib/:$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../riscv64-unknown-elf/lib/
COLLECT_GCC_OPTIONS='-v' '-L/usr/local/opt/zlib/lib' '-o' '$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/sdk_app_dac.elf' '-march=rv64imafdc' '-mabi=lp64d'
 $HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../libexec/gcc/riscv64-unknown-elf/8.3.0/collect2 -plugin $HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../libexec/gcc/riscv64-unknown-elf/8.3.0/liblto_plugin.so -plugin-opt=$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../libexec/gcc/riscv64-unknown-elf/8.3.0/lto-wrapper -plugin-opt=-fresolution=/var/folders/z4/xdx0_q792h50_8tv3c4qxjv40000gn/T//ccD1zxlW.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgloss -plugin-opt=-pass-through=-lgcc --sysroot=$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../riscv64-unknown-elf -melf64lriscv -o $HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/sdk_app_dac.elf $HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/lib/rv64imafdc/lp64d/crt0.o $HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/rv64imafdc/lp64d/crtbegin.o -L/usr/local/opt/zlib/lib -L$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/rv64imafdc/lp64d -L$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/lib/rv64imafdc/lp64d -L$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../riscv64-unknown-elf/lib/rv64imafdc/lp64d -L$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0 -L$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../lib/gcc -L$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/lib -L$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../riscv64-unknown-elf/lib -Map=$HOME/src/bl_iot_sdk/customer_app/sdk_app_dac/build_out/sdk_app_dac.map -lgcc --start-group -lc -lgloss --end-group -lgcc $HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/rv64imafdc/lp64d/crtend.o

$HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld: $HOME/src/bl_iot_sdk/toolchain/riscv/_Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/lib/rv64imafdc/lp64d/crt0.o: in function `.L0 ':
(.text+0x2e): undefined reference to `main'
collect2: error: ld returned 1 exit status

Running the same thing on other box, the linker command is completely different, contains march and mabi flags and also correct LIBRARY_PATH:

$ /Users/sychram/Repositories/bl_iot_sdk/toolchain/riscv/Darwin/bin/riscv64-unknown-elf-gcc \
> -v \
> -march=rv32imfc \
> -mabi=ilp32f \
> -Wl,--cref -nostartfiles \
> -Wl,--gc-sections \
> -Wl,-static \
> -Wl,--start-group  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/bl602  \
> -L /Users/sychram/Repositories/bl_iot_sdk/components/bl602/bl602/evb/ld -T flash.ld -lbl602  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/bl602_std  -lbl602_std  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/blfdt  -lblfdt  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/blmtd  -lblmtd  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/blog  -lblog  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/blog_testc  -lblog_testc  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/bloop  -lbloop  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/bltime  -lbltime  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/cli  -lcli  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/easyflash4  -leasyflash4  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/freertos_riscv_ram  -lfreertos_riscv_ram  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/hal_drv  -lhal_drv  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/looprt  -llooprt  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/loopset  -lloopset  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/romfs  -lromfs  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/sdk_app_dac  -lsdk_app_dac  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/utils  -lutils  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/vfs  -lvfs  \
> -L/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/yloop  -lyloop  \
> -Wl,--end-group \
> -Wl,-EL -lm -o /Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/sdk_app_dac.elf \
> -Wl,-Map=/Users/sychram/Repositories/bl_iot_sdk/customer_app/sdk_app_dac/build_out/sdk_app_dac.map
Using built-in specs.
COLLECT_GCC=/Users/sychram/Repositories/bl_iot_sdk/toolchain/riscv/Darwin/bin/riscv64-unknown-elf-gcc
COLLECT_LTO_WRAPPER=/Users/sychram/Repositories/bl_iot_sdk/toolchain/riscv/Darwin/bin/../libexec/gcc/riscv64-unknown-elf/8.3.0/lto-wrapper
Target: riscv64-unknown-elf
Configured with: /Users/mac/git/freedom-tools-master/obj/x86_64-apple-darwin/build/riscv-gnu-toolchain/riscv-gcc/configure --target=riscv64-unknown-elf --prefix=/Users/mac/git/freedom-tools-master/obj/x86_64-apple-darwin/install/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-apple-darwin --with-pkgversion='SiFive GCC 8.3.0-2019.08.0' --with-bugurl=https://github.com/sifive/freedom-tools/issues --disable-shared --disable-threads --enable-languages=c,c++ --enable-tls --with-newlib --with-sysroot=/Users/mac/git/freedom-tools-master/obj/x86_64-apple-darwin/install/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-apple-darwin/riscv64-unknown-elf --with-native-system-header-dir=/include --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libgomp --disable-nls --disable-tm-clone-registry --src=../riscv-gcc --with-system-zlib --enable-checking=yes --enable-multilib --with-abi=lp64d --with-arch=rv64imafdc CFLAGS=-O2 CXXFLAGS=-O2 'CFLAGS_FOR_TARGET=-Os  -mcmodel=medany' 'CXXFLAGS_FOR_TARGET=-Os  -mcmodel=medany'
Thread model: single
gcc version 8.3.0 (SiFive GCC 8.3.0-2019.08.0) 
COMPILER_PATH=/Users/sychram/Repositories/bl_iot_sdk/toolchain/riscv/Darwin/bin/../libexec/gcc/riscv64-unknown-elf/8.3.0/:/Users/sychram/Repositories/bl_iot_sdk/toolchain/riscv/Darwin/bin/../libexec/gcc/:/Users/sychram/Repositories/bl_iot_sdk/toolchain/riscv/Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/
LIBRARY_PATH=/Users/sychram/Repositories/bl_iot_sdk/toolchain/riscv/Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/rv32imf/ilp32f/:/Users/sychram/Repositories/bl_iot_sdk/toolchain/riscv/Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/lib/rv32imf/ilp32f/:/Users/sychram/Repositories/bl_iot_sdk/toolchain/riscv/Darwin/bin/../riscv64-unknown-elf/lib/rv32imf/ilp32f/:/Users/sychram/Repositories/bl_iot_sdk/toolchain/riscv/Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/:/Users/sychram/Repositories/bl_iot_sdk/toolchain/riscv/Darwin/bin/../lib/gcc/:/Users/sychram/Repositories/bl_iot_sdk/toolchain/riscv/Darwin/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/lib/:/Users/sychram/Repositories/bl_iot_sdk/toolchain/riscv/Darwin/bin/../riscv64-unknown-elf/lib/
COLLECT_GCC_OPTIONS='-v' '-march=rv32imfc' '-mabi=ilp32f' ...

So where do those come from? The build script and flags and the LIBRARY_PATH?

robertlipe commented 3 years ago

Your build left the rails way before that. That invocation is wrong. The

-march=rv32imfc \ -mabi=ilp32f \ part matters.

More importantly, you're running some random toolchain and NOT the one that's provided. You're running underscoreDarwin, not the provided Darwin chain.

Wait. I can replicate the error you're describing, "All" I have to do is is leave out about 35 lines worth of stuff that's supposed to get passed to the compiler. Make should be calling "blah-gcc -v -march=rv32imfc \ -mabi=ilp32f -Wl,--cref -nostartfiles -Wl,--gc-se ALL THAT OTHER STUFF". If I just call gcc like you did (no -m flags, so it tries to do 64-bit, no libraries to link against, no input files to link together (!) and just make an empty elf and use the provided .map, I get the same error you're describing.

Why is that machine even trying to look in _Darwin? Why is make generating such a butchered call to gcc?

I think you may need to check out a full tree again and see why that machine is so weird. I'm suspecting this not be a bug so much as an (intentionally?) mutated tree that doesn't reflect what's in the release.

suculent commented 3 years ago

The issue was actually caused by existing environment variable LDFLAGS.

Issue was solved using:

unset LDFLAGS
unset CPPFLAGS
make
robertlipe commented 3 years ago

You're welcome. This was gnarly to stick with to the end.

This is very much a reason to never set things like CC, LDFLAGS, CFLAGS, and such in a .login or similar place. Even CPU=BL602 (or whatever it is) doesn't leak into my global build environment; it stays in little scripts that build the local project.

I have way too many projects (and compilers and cpus and ...) to inflict such pain on myself. :-)

Glad you found the source of the issue on that machine. Happy hacking.