I have several old Centos 7 compilation machines that are used automatically, but when I try a manual compilation on them I get some garbled output from gcc (and only gcc, no other command line tool seems to have the same problem):
$ gcc -v ...
...
/hoe/dargaud/Soource
/us/localcvi/naatinst/cvi2013/toolslib/cuttctrl
/us/localcvi/naatinst/cvi2013/toolslib/custctrl/custsupp
/us/localcvi/naatinst/cvi2013/toolslib/prnnting
/us/localcvi/naatinst/cvi2013/toolslib/tollbox
/us/localcvi/naatinst/cvi2013/toolslib/lcaalui
/us/localcvi/naatinst/cvi2013/instr
/us/lib/gcc/x866_64-redhat-linux/4.8.5/icllude
/us/local/incluude
/usr/icclude
End of search list.
GNU C (GCC) version 4.8.5 20150623 (Red Hat 4.8.5-44) (x86_64-redhat-linux)
comiled by GNU C version 4.8.5 20150623 (Red Hat 4.8.5-44), GMP vesion 6.0.0, MPFR version 3.1.1, MPC version 1.00.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6b72f3aacca5f1ab7626c11b21313352
LecroyHdoVisa.c:15:18: fatal error: visa.h: No such file or directory
#inlude <visa.hh>
It's like many lines have a middle part moved by one character to the left. It's just bizarre. I looked with a hex dump and there's no invisible chars (such as backspace) in the pipe. It's perfectly reproducible from one run to the next. It happens whether I'm logged via ssh or sitting in front of the machine (kde bash konsole). There's no mix of stderr and stdout, just stdout.
Any idea ?!?
Update:
yes, it is from a wrapper, but I don't have access to its code:
$ file /usr/localcvi/natinst/cvi2013/cvicc
/usr/localcvi/natinst/cvi2013/cvicc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
Scientific Linux 7.9, but I have the problem on other OSes as well, so it's most likely the wrapper. Also:
$ uname -a
Linux localhost.localdomain 3.10.0-1160.59.1.el7.x86_64 #1 SMP Tue Feb 22 10:57:56 CST 2022 x86_64 x86_64 x86_64 GNU/Linux
for the hex dump I used alias hd='od -Ax -tx1z -v'
Related
On my system default gcc version is 4.4.7 , But i want to build glib library with gcc 6.3 version.
For that i tried running ./configure from glib source as shown below:
../configure CC="/version/global/pkgs/gcc/v6.3.0/bin/gcc" CFLAGS='-fPIC' CXXFLAGS='-fPIC' --enable-static=yes --prefix=/home/kallel/glib_63/glib-2.56.1/new_glib63 --enable-libmount=no --with-pcre=/home/kallel/pcre_lib/pcre-8.20/pcre_library
Once after building glib library. To see on which gcc compiler version it got built with following command:-
strings -a libglib-2.0.so.0.5600.1 | grep "GCC: ("
o/p:-
GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-9)
GCC: (Synopsis) 6.3.0
GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-4)
I could not understand why it is still showing output with 4.4.7, Please help me in understanding the output. Is there anything wrong in my ./configure command? How do we make sure that library was built with gcc 6.3
I could not understand why it is still showing output with 4.4.7
Your library contains object code that you built, as well as parts of GLIBC that are required to support shared libraries (crti.o, crtn.o, etc.).
These parts will continue to show whatever GCC they were built with, regardless of what you build glib code with.
This gdb was installed via Homebrew on my OSX.
I wonder why gdb doesn't work on this file(I was playing pwn)on my OSX, while I can run it on Kali linux through VirtualBox.
I saw some people mentioned "Apple version gdb", is that the problem?
And how do I solve this?
I searched for answer quite a while and even asked my proffessor, please give me a hand!
➜ file bof
bof: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.24,
BuildID[sha1]=ed643dfe8d026b7238d3033b0d0bcc499504f273, not stripped
➜ gdb bof
GNU gdb (GDB) 8.0
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
.
.
.
"/Users/me/Desktop/test/bof": not in executable format: File format not recognized
(gdb)
This gdb was installed via Homebrew on my OSX.
...
bof: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.24,
There are many ways to configure gdb. The default -- if you don't pass any special options to configure -- is to configure in just what is needed for the host platform.
In this case, probably what has happened is that your gdb is configured for OSX -- meaning Mach-O and not ELF -- and so gdb can't read ELF files. You can test this theory by typing set gnutarget <TAB> <TAB> at the gdb prompt (the tabs will cause completion, which is the only way I know of to list what was compiled in here). Alternatively, you can try show configuration, though that just says what options were passed to configure, and so it needs interpretation.
One simple way to get out of this is to reconfigure with --enable-targets=all. Then gdb will be able to read ELF files and other things as well.
I try to compile a go program on my Linux desktop (Linux desktop 4.10.0-28-generic #32-Ubuntu SMP Fri Jun 30 05:32:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux), go version go version go1.8.3 linux/amd64 to arm:
$ GOPATH=/home/xrfang/git/hermes/ GOARM=7 GOARCH=arm go build .
the executable is generated, but seems NOT ARMv7:
$ file hermes
hermes: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped
It shows EABI5. How can I cross-compile to ARMv7? Is there anything missing on my Linux Desktop so that the cross-compile fallback to a lower ARM version?
Thanks.
I believe, it is not ARMv5. I was trying to do the same on MAC OS and 'file' command on Mac is saying v7, but the 'file' command on Linux don't. However, I do know that v7 has some good improvements and may boost the performance of your program.
But, that is out of scope of this question and you may need to dig deeper into what you're doing and why a performance improvement is expected.
All I can say is, it is compiled for v7.
Two sets of compilations of same kernel sources on the same machine at different times create a vmlinuz file with different md5sum.
What could be the reason behind this?
OS - CentOS 6.7
gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)
The /proc/version pseudo-file contains a compilation timestamp. See proc(5). That timestamp is somewhere inside the kernel image. So two successive compilations of the same kernel give different images.
I have an ARM machine that runs Linux (BusyBox).
# uname -a
# Linux XXXXXXXX 2.6.28 #1 PREEMPT Fri Sep 26 22:47:38 UTC 2014 armv5tel GNU/Linux
I've cross-compiled a simple program on my Ubuntu 32-bit desktop:
./configure --host=arm-linux-gnueabi LDFLAGS="-static"
make
But when I try to run it on the ARM machine, it gives me Segmentation Fault error.
Program is super simple:
#include <stdio.h>
int main()
{
printf("Hello, World!");
return 0;
}
Here are a few things I've already tried/checked:
I've checked md5 hashes on both machines to eliminate the possibility that something went wrong at the time of copying an executable over the network
Stripped the executable with arm-linux-gnueabi-strip. I was comparing my executable with another executable that was already in the target machine with file:
# file my_program
# my_program: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.31, BuildID[sha1]=0x4b1f2773e54b141d5157b86f0f10438a372625c9, stripped
# file their_program
# their_program: ELF 32-bit LSB executable, ARM, version 1 (GNU/Linux), statically linked, stripped
What am I doing wrong?
Apparently my cross-compile toolchain was not the right one.
I ended up using crosstool-ng. Btw it's very simple to use and a great tool, all you have to do is to choose the right toolchain for your device.
I have built an arm-unknown-linux-uclibcgnueabi toolchain with crosstool-ng, which solved my problem.