What caused my executable file not to run on a Linux of old version 2.4.36.1

What caused my executable file not to run on a Linux of old version 2.4.36.1

[Dingjun Chen]

[-- Attachment #1: Type: text/plain, Size: 2509 bytes --]

Hi, Dear Sir or Madam,

I used the following gcc/g++ to build 32-bit executable file: vtem_xyz and please see the following information below:

dingjun@G02515:~/DAQ_XYZCross2_cmake/bin$ objdump -f vtem_xyz
vtem_xyz:     file format elf32-i386
architecture: i386, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x000027d0

The Linux version and gcc/g++ version information are given below when building above executable file:

dingjun@G02515:~/DAQ_XYZCross2_cmake/bin$ uname -a
Linux G02515 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

dingjun@G02515:~/DAQ_XYZCross2_cmake/bin$ g++ --version
g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

dingjun@G02515:~/DAQ_XYZCross2_cmake/bin$ gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


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.

Could you please tell me if your GNU libraries are compatible with the Linux of old version?  Do you have any suggestions when building an executable file running under a Linux of old version?

I look forward to your help and your reply would be greatly appreciated.

Thanks and regards,

Dingjun








Dingjun Chen  | Software Developer

[Geotech Airborne Geophysical Surveys]

Geotech Ltd. dba Geotech Airborne | 270 INDUSTRIAL PKY S | AURORA ON CA | L4G 3T9
T: +1 905 841 5004 | Dingjun.Chen@geotechairborne.com<mailto:Dingjun.Chen@geotechairborne.com> | www.geotechairborne.com<www.geotech.ca>

P Please consider the environment before printing this email

This message may contain PRIVILEGED AND PROPRIETARY INFORMATION intended solely for the use of the addressee (s) named above. Any disclosure, distribution, copying, or use of the information by others is strictly prohibited. If you have received this message in error, please advise the sender by immediate reply and delete the original message.

Fw: What caused my executable file not to run on a Linux of old version 2.4.36.1

[Dingjun Chen]

[-- Attachment #1: Type: text/plain, Size: 2317 bytes --]

Hi again, Dear Sir or Madam,


Is the setting

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=gnu++14") used in my CMakeLists.txt

having impact on the binary codes?

If so, what kind of setting for -std=????

I look forward to hearing from you.

Thanks and regards,

Dingjun
________________________________
From: Dingjun Chen
Sent: Friday, October 6, 2023 10:43 AM
To: gcc-help@gcc.gnu.org <gcc-help@gcc.gnu.org>
Subject: What caused my executable file not to run on a Linux of old version 2.4.36.1

Hi, Dear Sir or Madam,

I used the following gcc/g++ to build 32-bit executable file: vtem_xyz and please see the following information below:

dingjun@G02515:~/DAQ_XYZCross2_cmake/bin$ objdump -f vtem_xyz
vtem_xyz:     file format elf32-i386
architecture: i386, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x000027d0

The Linux version and gcc/g++ version information are given below when building above executable file:

dingjun@G02515:~/DAQ_XYZCross2_cmake/bin$ uname -a
Linux G02515 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

dingjun@G02515:~/DAQ_XYZCross2_cmake/bin$ g++ --version
g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

dingjun@G02515:~/DAQ_XYZCross2_cmake/bin$ gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


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.

Could you please tell me if your GNU libraries are compatible with the Linux of old version?  Do you have any suggestions when building an executable file running under a Linux of old version?

I look forward to your help and your reply would be greatly appreciated.

Thanks and regards,

Dingjun

Re: What caused my executable file not to run on a Linux of old version 2.4.36.1

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 2783 bytes --]

On Fri, 6 Oct 2023, 15:44 Dingjun Chen, <Dingjun.Chen@geotechairborne.com>
wrote:

> Hi, Dear Sir or Madam,
>
> I used the following gcc/g++ to build 32-bit executable file: vtem_xyz and
> please see the following information below:
>
> dingjun@G02515:~/DAQ_XYZCross2_cmake/bin$ objdump -f vtem_xyz
> vtem_xyz:     file format elf32-i386
> architecture: i386, flags 0x00000150:
> HAS_SYMS, DYNAMIC, D_PAGED
> start address 0x000027d0
>
> The Linux version and gcc/g++ version information are given below when
> building above executable file:
>
> dingjun@G02515:~/DAQ_XYZCross2_cmake/bin$ uname -a
> Linux G02515 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13
> UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
>
> dingjun@G02515:~/DAQ_XYZCross2_cmake/bin$ g++ --version
> g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
> Copyright (C) 2021 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> dingjun@G02515:~/DAQ_XYZCross2_cmake/bin$ gcc --version
> gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
> Copyright (C) 2021 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>
> 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?



> Could you please tell me if your GNU libraries are compatible with the
> Linux of old version?  Do you have any suggestions when building an
> executable file running under a Linux of old version?
>
> I look forward to your help and your reply would be greatly appreciated.
>
> Thanks and regards,
>
> Dingjun
>
>
>
>
>
>
>
>
> Dingjun Chen  | Software Developer
>
> [Geotech Airborne Geophysical Surveys]
>
> Geotech Ltd. dba Geotech Airborne | 270 INDUSTRIAL PKY S | AURORA ON CA |
> L4G 3T9
> T: +1 905 841 5004 | Dingjun.Chen@geotechairborne.com<mailto:
> Dingjun.Chen@geotechairborne.com> | www.geotechairborne.com<www.geotech.ca
> >
>
> P Please consider the environment before printing this email
>
> This message may contain PRIVILEGED AND PROPRIETARY INFORMATION intended
> solely for the use of the addressee (s) named above. Any disclosure,
> distribution, copying, or use of the information by others is strictly
> prohibited. If you have received this message in error, please advise the
> sender by immediate reply and delete the original message.
>

Re: What caused my executable file not to run on a Linux of old version 2.4.36.1

[Xi Ruoyao]

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.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: What caused my executable file not to run on a Linux of old version 2.4.36.1

[Kai Ruottu]

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)

Re: What caused my executable file not to run on a Linux of old version 2.4.36.1

[Dingjun Chen]

[-- Attachment #1: Type: text/plain, Size: 5905 bytes --]

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@wippies.com>
Sent: Saturday, October 7, 2023 7:19 AM
To: Xi Ruoyao <xry111@xry111.site>; Jonathan Wakely <jwakely.gcc@gmail.com>; Dingjun Chen <Dingjun.Chen@geotechairborne.com>
Cc: gcc-help <gcc-help@gcc.gnu.org>
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)

Re: What caused my executable file not to run on a Linux of old version 2.4.36.1

[Dingjun Chen]

[-- Attachment #1: Type: text/plain, Size: 4937 bytes --]

Hi, guys,

Right now the linked errors occurred have changed into the following case. Could someone tell me how to fix such errors?

Thanks and regards,

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: /usr/lib/gcc/x86_64-linux-gnu/11/../../../librtd-dm6620.a: warning: relocation in read-only section `.text'
/usr/bin/ld: CMakeFiles/vtem_xyz.dir/src/Vtem24.cc.o: in function `main':
Vtem24.cc:(.text+0x34b): undefined reference to `__stack_chk_fail_local'
/usr/bin/ld: CMakeFiles/vtem_xyz.dir/src/_d_dngl.cc.o: in function `dongle_interface::Initialize(char const*, long, int, int, int, unsigned char (&) [8])':
_d_dngl.cc:(.text+0x1d5): undefined reference to `__stack_chk_fail_local'
/usr/bin/ld: CMakeFiles/vtem_xyz.dir/src/_d_dngl.cc.o: in function `dongle_interface::Transform()':
_d_dngl.cc:(.text+0x3e8): undefined reference to `__stack_chk_fail_local'
/usr/bin/ld: CMakeFiles/vtem_xyz.dir/src/_d_dngl.cc.o: in function `dongle_interface::SendCommand(unsigned char (&) [2], unsigned char (&) [8], unsigned char (&) [8], unsigned char (&) [16])':
_d_dngl.cc:(.text+0x52a): undefined reference to `__stack_chk_fail_local'
/usr/bin/ld: CMakeFiles/vtem_xyz.dir/src/_d_dngl.cc.o: in function `dongle_interface::ReceiveResponse(unsigned char (&) [2], unsigned char (&) [2], unsigned char (&) [8], unsigned char (&) [8], unsigned char (&) [16], unsigned char (&) [16])':
_d_dngl.cc:(.text+0x803): undefined reference to `__stack_chk_fail_local'
/usr/bin/ld: CMakeFiles/vtem_xyz.dir/src/_d_dngl.cc.o:_d_dngl.cc:(.text+0x8ea): more undefined references to `__stack_chk_fail_local' follow
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/32/libstdc++.so: undefined reference to `__mbsnrtowcs_chk@GLIBC_2.4'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/32/libstdc++.so: undefined reference to `stat64@GLIBC_2.33'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/32/libstdc++.so: undefined reference to `fstat64@GLIBC_2.33'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/32/libstdc++.so: undefined reference to `__wmemcpy_chk@GLIBC_2.4'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/32/libstdc++.so: undefined reference to `__ctzdi2@GCC_3.4'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/32/libstdc++.so: undefined reference to `utimensat@GLIBC_2.6'
/usr/bin/ld: ../bin/vtem_xyz: hidden symbol `__stack_chk_fail_local' isn't defined
/usr/bin/ld: final link failed: bad value
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: Xi Ruoyao <xry111@xry111.site>
Sent: Saturday, October 7, 2023 2:18 AM
To: Jonathan Wakely <jwakely.gcc@gmail.com>; Dingjun Chen <Dingjun.Chen@geotechairborne.com>
Cc: gcc-help <gcc-help@gcc.gnu.org>
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.



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.

--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: What caused my executable file not to run on a Linux of old version 2.4.36.1

[Xi Ruoyao]

On Tue, 2023-10-10 at 10:28 +0000, Dingjun Chen wrote:
> 
> 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? 

I've told you:

   Build a cross compiler and use the root FS of the target board as the
   sysroot.

> By the way, the GNU ld command is 64-bit. However I want to build 32-
> bit executables. 

The 64-bit ld can link 32-bit executables (with -m elf_i386).

> 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?

No.

> Which GNU C/C++ compiler version can offer us a 32-bit ld to link the
> objects? 

ld is not a part of GCC.

> I look forward to your help! 

But now this is just being annoying.  You are lacking some common
knowledge about how a program is linked and executed.  gcc-help is not
for teaching these common knowledge.

Try to find a textbook.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: What caused my executable file not to run on a Linux of old version 2.4.36.1

[Dingjun Chen]

[-- Attachment #1: Type: text/plain, Size: 3192 bytes --]

Hi, Ruoyao,

Could you please tell me how to build cross compiler for Linux of different versions?

I followed the following method, but I failed. I look forward to your help!

Thanks again and regards,

Dingjun


How to Build a GCC Cross-Compiler (preshing.com)<https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/>
How to Build a GCC Cross-Compiler<https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/>
GCC is not just a compiler. It&rsquo;s an open source project that lets you build all kinds of compilers. Some compilers support multithreading; some support shared libraries; &hellip;
preshing.com







> 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.

________________________________
From: Xi Ruoyao <xry111@xry111.site>
Sent: Saturday, October 7, 2023 2:18 AM
To: Jonathan Wakely <jwakely.gcc@gmail.com>; Dingjun Chen <Dingjun.Chen@geotechairborne.com>
Cc: gcc-help <gcc-help@gcc.gnu.org>
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.



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.

--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: What caused my executable file not to run on a Linux of old version 2.4.36.1

[Kai Ruottu]

Dingjun Chen kirjoitti 10.10.2023 klo 20.13:
> Hi, Ruoyao,
>
> Could you please tell me how to build cross compiler for Linux of different versions?
>
> I followed the following method, but I failed. I look forward to your help!
>
> How to Build a GCC Cross-Compiler (preshing.com)<https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/>
This "method" belongs in the group "Linux from scratch", not in 
"producing a cross compiler for existing Linux target". The idea in the
latter is "to do same things on another host system as one could do on 
the existing Linux target system". What already exists, it is
available and there isn't any reason to "reinvent the wheel". So you 
only need to produce GNU binutils and GCC from their sources
to work on another host system and to produce stuff for the target 
system there. For the "Linux distros" their install RPMs, '.deb'
packages etc will provide the required "run-time libraries" usually 
natively in '/lib' on the target system, the "development libraries"
in '/usr/lib' and "development headers & kernel headers" in 
'/usr/include'.  These are the basic "sysroot" stuff required during the
GCC build Xi told about.

So please choose your install $prefix for the cross binutils and cross 
GCC binaries (the same for both) and $sysroot for the C library
etc coming from / belonging to the target system. Then configure and 
build the sources and be happy!  It really isn't complicated at
all!