undefined reference to 'memchr'

[oldbronco]

I've done the 'make' and the script reports that Xtensa toolchain is built, to use it:

export PATH=/home/wi24554/esp-open-sdk/xtensa-lx106-elf/bin:$PATH

Espressif ESP8266 SDK is installed, its libraries and headers are merged with the toolchain

but when I go to make blinky in the example I get the following error.

/esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot/usr/lib/liblwip.a(espconn_buf.o): In function ringbuf_head': (.text+0x1cc): undefined reference tomemchr' /esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot/usr/lib/liblwip.a(espconn_buf.o): In function ringbuf_findchr': (.text+0x24f): undefined reference tomemchr' collect2: error: ld returned 1 exit status make: *\ [blinky] Error 1

From suggestions on the arduino toolset crowd, I added a memchr2 function, and replaced the function call for memchr to memchr2 for the espconn_buf.c file, but I get the same error. I also had to add a -std=c99 to the blinky makefile

thanks in advance bronco

[k-a-z-u]

someone suggested just grabbing an implementation of memchr() from somewhere [e.g. http://stackoverflow.com/questions/525123/how-does-memchr-work-under-the-hood], and adding it to some .c file

[jcmvbkbc]

You can just request linking with libc in the blinky Makefile like this: LDLIBS = -nostdlib -Wl,--start-group -lmain -lnet80211 -lwpa -llwip -lpp -lphy -lc -Wl,--end-group -lgcc

[oldbronco]

Thanks jcmvbkbc! solved!

[ghost]

I still have the problem even though my makefile looks exactly like above.

[erikjl]

I also have this issue. The Makefile's LDLIBS looks just like what jcmvbkbc posted.

[SebNag]

By default the LDLIBS variable in the Makefile does not contain the -lc option! After adding the -lc option building the blinky example just worked fine

[pearson]

Thanks for that! I must have looked at the includes so many times and didn't notice the difference. Adding -lc worked for me.

[aemiller51]

-lc worked for me too! Thanks :) LDLIBS = -nostdlib -Wl,--start-group -lmain -lnet80211 -lwpa -llwip -lpp -lphy -Wl,--end-group -lgcc -lc

[pali24]

I had the same error message at "blinky", and thanks for jcmvbkbc, -lc worked me too. But... I got two files: blinky-0x00000.bin and blinky-0x10000.bin and the "make flash" sends an error message, that needs blinky-0x40000.bin (if I rename it to blinky-0x40000.bin, error: Digest mismatch:....)

[dejarp]

@pali24 if I understand correctly you can't just rename the 0x10000.bin to 0x40000.bin and flash it to 0x40000 on the esp. I'm having the same issue with the files generated in the blinky example not being the same as the files in the Makefile for the flash make recipe. There's some additional conversation going on over here https://github.com/pfalcon/esp-open-sdk/issues/226, and updating the Makefile to flash 0x10000.bin to 0x10000 seems to have worked for some people, but it didn't work for me ( using NodeMCU dev board with esp-12e ). I'm pretty new to all this so would appreciate any pointers for gathing more information @jcmvbkbc.

so far I've tried creating a screen on linux to monitor /dev/ttyUSB0 with various baud rates ( 115200, 9600, 57600, and, 76800 ) and have gotten nothing but gibberish with various combinations of esptool.py options and different flash baud rates. One thing that seemed a little suspect was that I tried running the esptool verify_flash 0x00000 blinky-0x00000.bin and it seemed to indicate that what was flashed to the chip was not what was in the file (even though verify_flash succeeded for 0x10000 blinky-0x10000.bin), so maybe this is more of an issue to file with the esptool, but I'm not sure (note: ran erase_flash prior to running "make flash" with the assumption that it is good to erase the flash prior to writing but that could be wrong and if so ignore suggestion in next following sentence). Perhaps adding an erase_flash recipe to the Makefile would be handy for noobs like me as well :).

What could be cool to have a basic example which is even more stripped down than blinky which just configures one gpio pin and sets it to HIGH as a sort of looks-like-you-just-compiled-your-first-toolchain-ever example. Not sure it would be any less prone to the missing includes or the base address changes issues previously mentioned/fixed though.

[dejarp]

ok so after following the instructions here http://sensornodeinfo.rockingdlabs.com/blog/2016/01/19/baud74880/ to set a custom baud rate in linux to 74880 I was able to get at least a little more info which indicated that the chip was infinitely resetting, and was able to google a bit more and found that there's an additional esp_init_data_default.bin which can be flashed to 0x3fc000 which I'd clearly missed by just jumping head first into building the toolchain without RTFM'ing very much. Flashing that in addition to the bootloader and user section after clearing the flash seemed to work (albiet with a bit of head scratch and the annoyance of needing the clear the flash every time). Then I went digging around for references to that address and found the README in bin/at, had the aha moment, and flashed blank.bin to 0x7e000 and 0x3fe000 in addition to bootloader and user section but without the esp_init_data_default.bin which is marked as optional. The full command was.

esptool.py -p /dev/ttyUSB0 write_flash --flash_mode dio 0 blinky-0x00000.bin 0x10000 blinky-0x10000.bin 0x7e000 blank.bin 0x3fe000 blank.bin

edit: if I'd read through the recent commit history, this would have been obvious https://github.com/pfalcon/esp-open-sdk/commit/24f10eb164947fdd38b6225f72e752d5eb785391