Hi there,
to enable remote debugging using gdbserver on RaspberryPi , this is necessary on the host side.
Can it be added in a future release?

Thank you

rsync usage example in the readme file uses -R (--relative) and --safe-links together.
But manual for --safe-links notes the following:

Using this option in conjunction with --relative may give unexpected results.

Full manual for both options

-R, --relative
Use relative paths. This means that the full path names specified on the command line are sent to the server rather than just the last parts of the filenames. This is particularly useful when you want to send several different directories at the same time.

--safe-links
This tells rsync to ignore any symbolic links which point outside the copied tree. All absolute symlinks are also ignored. Using this option in conjunction with --relative may give unexpected results.

I downloaded the pre-built toolchain from wget https://github.com/Pro/raspi-toolchain/releases/latest/download/raspi-toolchain.tar.gz.
I cannot compile a C program that needs definitions like PATH_MAX from <limits.h> with this toolchain. Here is a minimal test case:

$ cat test.c 
#include <limits.h>
#include <stdio.h>
int main()
{
  int i = LINE_MAX;
  int p[PATH_MAX];

  return 0;
} 

Compiling with the toolchain, on the host Ubuntu 18.04.5, gave me the error:

$ arm-linux-gnueabihf-gcc -o test_lim_arm ./test.c
./test.c: In function 'main':
./test.c:5:11: error: 'LINE_MAX' undeclared (first use in this function); did you mean 'LONG_MAX'?
   int i = LINE_MAX;
           ^~~~~~~~
           LONG_MAX
./test.c:5:11: note: each undeclared identifier is reported only once for each function it appears in
./test.c:6:9: error: 'PATH_MAX' undeclared (first use in this function); did you mean 'INT_MAX'?
   int p[PATH_MAX];
         ^~~~~~~~
         INT_MAX

Same code with the native GCC compiled successfully:

$ gcc -o test_lim_x86 ./test.c

This is my toolchain info:

$ arm-linux-gnueabihf-gcc -v        
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/opt/cross-pi-gcc/libexec/gcc/arm-linux-gnueabihf/8.3.0/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../gcc-8.3.0/configure --prefix=/opt/cross-pi-gcc --target=arm-linux-gnueabihf --enable-languages=c,c++,fortran --with-arch=armv6 --with-fpu=vfp --with-float=hard --disable-multilib
Thread model: posix
gcc version 8.3.0 (GCC) 

Thanks you.

I'm cross compiling a c++ project that uses dbus-cpp to do dbus communication on an rpi.
I'm able to build the project fine but when I run it on the rpi I get a deadlock in the pthreads library, it looks like it is happening while creating a shared_ptr.

[0] from 0xb6ee4e5c in __lll_lock_wait+36 at lowlevellock.c:43
[1] from 0xb6edcf44 in __GI___pthread_mutex_lock+264 at pthread_mutex_lock.c:80

I've built the same project on the pi and I don't see the deadlock. I use cmake in both places.

Anyone else see anything like this? Any pointers on how to debug?

README states

By default, newer GCC versions do not create correct binaries for ARMv6. Even though you pass the correct -mcpu= flag to gcc, it will create startup code for the newer ARMv7 architecture. Running them on your RasPI Zero will cause an "Illegal Instruction" exception.

I don't doubt this was a problem when this toolchain was created, but I can't find such a problem in GCC's Bugzilla. Would this not be considered a bug? And if it is, could it have been fixed by now?
I also don't have a Pi Zero handy to verify this claim myself. I just know that I'm able to build just fine with the basic cross-build tools available on Debian, but I'm also building for a Pi4 which isn't the primary target of this toolchain.

If I can build without this, why am I complaining? Because I'm also required to build with this toolchain and ensuring compatibility has been a source of constant sorrow.

When building the cmake project, after following all instructions and changing the build script to reflect my board, the compilation fails with the following error:

In file included from /usr/include/pthread.h:25,
from /opt/cross-pi-gcc/arm-linux-gnueabihf/include/c++/8.3.0/arm-linux-gnueabihf/bits/gthr-default.h:35,
from /opt/cross-pi-gcc/arm-linux-gnueabihf/include/c++/8.3.0/arm-linux-gnueabihf/bits/gthr.h:148,
from /opt/cross-pi-gcc/arm-linux-gnueabihf/include/c++/8.3.0/ext/atomicity.h:35,
from /opt/cross-pi-gcc/arm-linux-gnueabihf/include/c++/8.3.0/bits/basic_string.h:39,
from /opt/cross-pi-gcc/arm-linux-gnueabihf/include/c++/8.3.0/string:52,
from modbus.h:12,
from modbus.cpp:35:
/opt/cross-pi-gcc/arm-linux-gnueabihf/include/bits/endian.h:2:3: error: #error "Never use <bits/endian.h> directly; include <endian.h> instead."

• Platform: Raspberry Pi Zero W
• OS: Rasbpian OS 11 (bullseye)

One solution I found was reverting the OS back to Rasbpian OS 10 (buster) and getting the required files from the board again. After that the code was compiled without any hassle and worked as intended. Both installations were fresh and with all packages updated to the latest version. I also found another user with a similar problem using the toolchain in this forum while trying to compile RtAudio.

I am getting the below message when trying to build from the Dockerfile:
$docker build -f Dockerfile --network=host -t gcc9-rpi-zero .

  HDRINST usr/include/asm/mman.h
  HDRINST usr/include/asm/statfs.h
  HDRINST usr/include/asm/ioctl.h
  HDRINST usr/include/asm/socket.h
  HDRINST usr/include/asm/kvm_para.h
  HDRINST usr/include/asm/sockios.h
  HDRINST usr/include/asm/siginfo.h
  HDRINST usr/include/asm/unistd-eabi.h
  HDRINST usr/include/asm/termbits.h
  HDRINST usr/include/asm/unistd-common.h
  HDRINST usr/include/asm/shmbuf.h
  HDRINST usr/include/asm/param.h
  HDRINST usr/include/asm/bitsperlong.h
  HDRINST usr/include/asm/poll.h
  HDRINST usr/include/asm/resource.h
  HDRINST usr/include/asm/unistd-oabi.h
  HDRINST usr/include/asm/errno.h
  HDRINST usr/include/asm/bpf_perf_event.h
  HDRINST usr/include/asm/sembuf.h
  HDRINST usr/include/asm/msgbuf.h
  HDRINST usr/include/asm/termios.h
  HDRINST usr/include/asm/ipcbuf.h
  INSTALL /opt/cross-pi-gcc/arm-linux-gnueabihf/include
/bin/sh: 1: rsync: not found
make: *** [Makefile:1212: headers_install] Error 127
The command '/bin/sh -c make ARCH=arm INSTALL_HDR_PATH=/opt/cross-pi-gcc/arm-linux-gnueabihf headers_install' returned a non-zero code: 2

I'm using cmake, but that shouldn't matter. I am able to build binaries, but when it needs to search the rootfs to link against usr/lib/arm-linux-gnueabihf, it can't find that path. I've been experimenting with some options, but it would be nice if the toolchain could find that path too if possible. Thank you.