Hi, Ruoyao and Kai, The kernel is too old and Please see errors occurred below. You mentioned "because the executable may use symbols which don't exist in the old Glibc" and You are right. How to fix it? By the way, the GNU ld command is 64-bit. However I want to build 32-bit executables. dingjun@G02515:~/DAQ_XYZCross2_cmake/build$ objdump -f /usr/bin/ld /usr/bin/ld: file format elf64-x86-64 architecture: i386:x86-64, flags 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x0000000000048630 Can I fix such an error with 32-bit ld? Which GNU C/C++ compiler version can offer us a 32-bit ld to link the objects? I look forward to your help! Thanks in advance for your responses! Dingjun ...................... [ 90%] Building CXX object CMakeFiles/vtem_xyz.dir/src/serialmsg.cc.o [ 95%] Building CXX object CMakeFiles/vtem_xyz.dir/src/simulant.cc.o [100%] Linking CXX executable ../bin/vtem_xyz /usr/bin/ld: CMakeFiles/vtem_xyz.dir/src/_d_dngl.cc.o: undefined reference to symbol '_Unwind_Resume@@GCC_3.0' /usr/bin/ld: /home/dingjun/sbc_lib_test/libgcc_s.so.1: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/vtem_xyz.dir/build.make:417: ../bin/vtem_xyz] Error 1 make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/vtem_xyz.dir/all] Error 2 make: *** [Makefile:91: all] Error 2 ________________________________ From: Kai Ruottu <kai.ruottu@xxxxxxxxxxx> Sent: Saturday, October 7, 2023 7:19 AM To: Xi Ruoyao <xry111@xxxxxxxxxxx>; Jonathan Wakely <jwakely.gcc@xxxxxxxxx>; Dingjun Chen <Dingjun.Chen@xxxxxxxxxxxxxxxxxxx> Cc: gcc-help <gcc-help@xxxxxxxxxxx> Subject: Re: What caused my executable file not to run on a Linux of old version 2.4.36.1 External Email Warning: Do not click any links or open any attachments unless you trust the sender and know the content is safe. From Geotech IT. Xi Ruoyao via Gcc-help kirjoitti 7.10.2023 klo 9.18: > On Fri, 2023-10-06 at 18:07 +0100, Jonathan Wakely via Gcc-help wrote: >>> However, the executable file: vtem_xyz cannot run on RTD single board >>> computer with Linux 2.4.36.1 2009, i686. >>> All shared .so libraries are under the same directory with the executable >>> file: vtem_xyz. I am wondering what's wrong with it. >>> >> You haven't told us what happens, so we can't help you. What does "cannot >> run" mean? What happens when you try to run it? > Linux 2.4.36.1? Really? The recent Glibc releases needs Linux kernel <= 3.2. > So if you copy the Glibc from the host system (or statically > link it into the executable) it won't work because the kernel version is > too low. If you just link the executable dynamically with host Glibc > but attempt to run it with the Glibc on your target board it won't work > too because the executable may use symbols which don't exist in the old > Glibc. > > Running Linux 2.4.36.1 is just wrong in 2023 (it was already wrong even > in 2013). > >> Do you have any suggestions when building an executable file running >> under a Linux of old version? > Build a cross compiler and use the root FS of the target board as the > sysroot. But again it's just wrong to run Linux 2.4 today, so you'll > likely encounter problems here or there. And it's very difficult to > find any support because nobody wants to install something based on > Linux 2.4 and reproduce the problem for you, in 2023. > > Try upgrade the software stack for the target board. For pure curiosity I checked whether one could create a cross-GCC for some quite old Linux system like CentOS 3.9/i386 for which I still had target headers (including the kernel ones) and libraries in a sysroot. The GCC sources were gcc-11.4.0 and GNU binutils sources were 2.39. The 'usr/include/linux/version.h' seemed to tell the kernel being 2.4.20 in CentOS 3.9/i386. The sysroot inluded also the original native GCC for CentOS 3.9/i386 and it seemed still to run somehow in my uptodate Fedora Linux : [root@fedora bin]# ./i386-redhat-linux-gcc -v Reading specs from ./../lib/gcc-lib/i386-redhat-linux/3.2.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Säiemalli: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-60) [root@fedora bin]# uname -a Linux fedora 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 20:51:12 UTC 2023 x86_64 GNU/Linux The cross-GCC built almost succeeded with the same configure options I had used for CentOS 6.10/i686. Only producing libsanitizer for the target CentOS 3.9 didn't work so adding '--disable-libsanitizer' was required. Some missing header in 'usr/include/linux' stopped the build in the first try. [root@fedora bin]# i386-centos-linux3.9-gcc-11 -v Using built-in specs. COLLECT_GCC=i386-centos-linux3.9-gcc-11 COLLECT_LTO_WRAPPER=/run/media/kairuottu/2c439158-ef3e-4dcf-a63b-03191c302829/opt/cross64/bin/../lib/gcc/i386-centos-linux3.9/11.4.0/lto-wrapper Target: i386-centos-linux3.9 Configured with: ../configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=i386-centos-linux3.9 --prefix=/opt/cross --libdir=/opt/cross/lib --libexecdir=/opt/cross/lib --with-sysroot=/opt/host-i386-centos-linux3.9 --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-checking=release --disable-nls --disable-libsanitizer --disable-libunwind-exceptions --disable-dssi --disable-plugin --with-tune=generic --with-arch=i686 --enable-version-specific-runtime-libs --with-gxx-include-dir=/opt/cross/include/c++/11.4 --program-prefix=i386-centos-linux3.9- --program-suffix=-11 Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.4.0 (GCC)
