From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fgw22-4.mail.saunalahti.fi (fgw22-4.mail.saunalahti.fi [62.142.5.109]) by sourceware.org (Postfix) with ESMTPS id DF74D3858C53 for ; Sat, 7 Oct 2023 11:19:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DF74D3858C53 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=wippies.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=wippies.com Received: from [10.0.0.36] (yritysnetti-567379-253.businessinternet.fi [86.115.121.253]) by fgw22.mail.saunalahti.fi (Halon) with ESMTPSA id 62f6ec9c-6503-11ee-a9de-005056bdf889; Sat, 07 Oct 2023 14:19:32 +0300 (EEST) Message-ID: <2abfaf68-fe2c-f151-6c7f-14bb1bf8ce03@wippies.com> Date: Sat, 7 Oct 2023 14:19:30 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: What caused my executable file not to run on a Linux of old version 2.4.36.1 To: Xi Ruoyao , Jonathan Wakely , Dingjun Chen Cc: gcc-help References: From: Kai Ruottu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_NUMSUBJECT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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)