search

earlephilhower / esp-quick-toolchain

GCC toolchain for esp8266/arduino on MacOS, Linux, ARM64, Raspberry Pi, and Windows
87 stars 24 forks source link

EQT build on FreeBSD 12.2 #28

Closed kmihaylov closed 2 years ago

kmihaylov commented 3 years ago

Hello.

Few months ago I had some difficulties when I tried to build esp-quick-toolchain. However with minor Makefile modification I succeeded.

The last few days I tried to build it again and unfortunately I stuck again on a problem unknown to me. When building binutils-gdb-gnu the linker exits with this error:

  CXX    xtensa-tdep.o
  CXX    init.o
  CXXLD  gdb
ld: error: undefined symbol: _libmd_SHA256_Init
>>> referenced by check.h:143 (/usr/src/contrib/xz/src/liblzma/check/check.h:143)
>>>               check.o:(lzma_check_init) in archive /usr/lib/liblzma.a

ld: error: undefined symbol: _libmd_SHA256_Update
>>> referenced by check.h:160 (/usr/src/contrib/xz/src/liblzma/check/check.h:160)
>>>               check.o:(lzma_check_update) in archive /usr/lib/liblzma.a

ld: error: undefined symbol: _libmd_SHA256_Final
>>> referenced by check.h:167 (/usr/src/contrib/xz/src/liblzma/check/check.h:167)
>>>               check.o:(lzma_check_finish) in archive /usr/lib/liblzma.a
c++: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [Makefile:1889: gdb] Error 1
gmake[2]: Leaving directory '/home/esp-quick-toolchain/arena.x86_64/binutils-gdb-gnu/gdb'
gmake[1]: *** [Makefile:10118: all-gdb] Error 2
gmake[1]: Leaving directory '/home/esp-quick-toolchain/arena.x86_64/binutils-gdb-gnu'
gmake: *** [Makefile:849: all] Error 2

I found that removing the LDFLAGS=-static variable "solves" the issue. Unfortunately I'm unaware with the consequences of this "solution". I suspect it might have something to do with the compiler (since I think this is build widh clang's cc instead gcc) so this is my next step to check, though...

Switched from clang to gcc (added CC=gcc9 and CXX=g++9 before the configure and make lines in the main Makefile) and the build stops again with the same error:

  CXXLD  gdb
/usr/local/bin/ld: /usr/lib/liblzma.a(check.o): in function `lzma_sha256_init':
/usr/src/contrib/xz/src/liblzma/check/check.h:143: undefined reference to `_libmd_SHA256_Init'
/usr/local/bin/ld: /usr/lib/liblzma.a(check.o): in function `lzma_sha256_update':
/usr/src/contrib/xz/src/liblzma/check/check.h:160: undefined reference to `_libmd_SHA256_Update'
/usr/local/bin/ld: /usr/lib/liblzma.a(check.o): in function `lzma_sha256_finish':
/usr/src/contrib/xz/src/liblzma/check/check.h:167: undefined reference to `_libmd_SHA256_Final'
collect2: error: ld returned 1 exit status
gmake[2]: *** [Makefile:1889: gdb] Error 1
gmake[2]: Leaving directory '/home/esp-quick-toolchain/arena.x86_64/binutils-gdb-gnu/gdb'
gmake[1]: *** [Makefile:10420: all-gdb] Error 2
gmake[1]: Leaving directory '/home/esp-quick-toolchain/arena.x86_64/binutils-gdb-gnu'
gmake: *** [Makefile:849: all] Error 2

Now the binaries should be gcc built, only the linker is the FreeBSD native linker (/usr/local/bin/ld).

Will be very glad for advice.

earlephilhower commented 3 years ago

I don't have any experience w/FreeBSD, but to me it looks like a system library issue. I've got versions 5.00 and 5.22 of liblzma on my system and the Docker image. Maybe you can go backwards /forwards from your installed version?

I also see other folks w/FreeBSD having the same issue q/a quick GOOG search: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247558 . So, seems like a potential mismatch in some of your system libraries possibly.

Good luck!

kmihaylov commented 3 years ago

Just came here to leave a note that nm liblzma.a for FreeBSD 12.1 is different that the one for FreeBSD 12.2. I discuss the issue in the FreeBSD forums and hope that they may give some light in the problem. Thank you for your quick response! I'll leave the issue open for some time. If I manage to solve it I'll post.

kmihaylov commented 3 years ago

I'm attaching quick and dirty Makefile that does the job on my FreeBSD machine. I see that gcc is hardcoded several times in the Makefile. Maybe it would be better to change it to a variable?

Makefile.FreeBSD.dirty.txt

Also I didn't succeed to static build binutils-gcc, you'll see that LDFLAGS=-static is removed. Still investigating the problem though.

kmihaylov commented 3 years ago

@earlephilhower, In your Makefile the mkspiffs and mklittlefs stages use CC=$(call host,$@)-gcc CXX=$(call host,$@)-g++, but the other stages make relies on the default compiler, that should be the same as the called above.

Is there anything special for this handling or it happened so over time?

earlephilhower commented 3 years ago

Good work so far!

For those tools we need to invoke the cross-compiler, since those will be run on the ARM/Windows/etc. box. gcc won't cut it, unfortunately.

kmihaylov commented 3 years ago

@earlephilhower Would you please have a look at changes I did to the Makefile? https://github.com/kmihaylov/esp-quick-toolchain/commit/5517d54cea590a86c25aeaff46e7db07ea1c4ade

Can't understand why tarball=$(call host,$@).xtensa-lx106-elf... was empty (stage .package), so I changed it a bit. Something related to arch = $(subst .,,$(suffix $(basename $(1)))) ? (Since there is a dot in the _HOST).

I forgot to correct some things in this commit:

I'm unsure how to properly set _HOST, _AHOST. Shooting in the dark.

earlephilhower commented 3 years ago

This is going to sound obscene, but there is already a cross-compiling Docker image. Maybe we can add FreeBSD cross-compilers to it and simplify the whole thing?

So it would still "build under Linux" (which works w/o issue) but generate FreeBSD ELF/a.out/whatever bin format...

kmihaylov commented 3 years ago

Sure, I don't mind. I lack the experience to do it. The non-static version produces working binaries. If you have some spare time it would be nice if FreeBSD is supported by EQT.

trombik commented 3 years ago

just ported to FreeBSD based on @kmihaylov 's patch:

https://github.com/trombik/freebsd-ports-esp-quick-toolchain/tree/main/devel/esp-quick-toolchain

although haven't looked at the patch itself much, it works for me. use ports-mgmt/portshaker to build it yourself.

earlephilhower commented 3 years ago

Neat work, @trombik . I am a little curious, though, why it is needed? The Arduino IDE isn't distributed for FreeBSD, AFAICT. So it's probably being run by the Linux compatibility shims by users, right? Couldn't the same thing be done with the Linux ELF binaries for the toolchain?

trombik commented 3 years ago

there is no official Arduino IDE, but we ported because some people don't like compat linux for various reasons (wine on Linux doesn't work always, right?).

https://www.freshports.org/devel/arduino18/

also, a few of us don't like downloading random binaries from the Internet. i prefer packages from the FreeBSD ports. packages in the ports must be built in a safe environment, i.e. an isolated build environment. that means building packages on non-FreeBSD is not acceptable.

trombik commented 3 years ago

it compiles arendst/Tasmota fine (not the default environment, but the one for Arduino 3.0.0).

eventually, the reference to kmihaylov/esp-quick-toolchain will be removed and point to earlephilhower/esp-quick-toolchain repository instead. from the viewpoint of porters, the Makefile needs just little modifications.

but all of the above are optional. I can handle it.

Jason2866 commented 3 years ago

To use Arduino ESP8266 there is no ArduinoIDE needed ;-) @trombik Thx for using Tasmota project for your tests! The latest development version makes already use of the 2nd shared heap. Great feature!

trombik commented 3 years ago

To use Arduino ESP8266 there is no ArduinoIDE needed ;-)

I don't use the so-called IDE, but platformio. however, arduino-cli looks better, at the least, easier to deal with (better documentation).

Jason2866 commented 3 years ago

We couldnt handle Tasmota special needs without platformio. Easy with cli and there are nice IDE possibilitys.

trombik commented 3 years ago

my port has been working fine. if you are a FreeBSD user, try: https://github.com/trombik/freebsd-ports-esp-quick-toolchain/tree/main/devel/esp-quick-toolchain

as far as I am concerned, i am fine to this issue.