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.
Related
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'
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.
According to the gFortran docs in order to enable OpenACC support it is necessary to use the -fopenacc switch. However, this does not seem to work.
gfortran: error: unrecognized command line option ‘-fopenacc’
gFortran version is GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28).
What is the correct way to compile Fortran code with OpenACC support?
Your version is WAY too old. The currently supported versions of GCC are 7, 8 and 9.
The version specific manuals are available at https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gfortran/OpenACC.html#OpenACC Change the version number in the address to see other versions.
The option appears to be added in version 5 but the support in more recent versions is likely to be much better.
I am trying to achieve reproducibility of builds, and in order to do that I am compiling same code with same compiler on other machine(one is on my Ubuntu machine) and the other is another ubuntu machine with same configuration.
The ELF file for both are different, specifically the entry point are different.
Can someone explain why? different compiler version generating different output is acceptable but exactly same compiler for exact same code generating different ELF is something I don't understand.
I am using gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 on both the machine.
I have code which produces executables larger than 2GB (it's generated code).
On x64 with gcc 4.3.2 I get errors like:
crtstuff.c:(.text+0x20): relocation truncated to fit:
R_X86_64_32S against `.dtors'
So I understand i need the -mcmodel=large option. However that doesn't do anything or solve the problem on my system.
I am sure I read somewhere, that it was only supported from a particular version of gcc, and the option was ignored on versions before that. I would tell my operations team to install that version of gcc if only I knew what it was. But I just can't find any evidence right now to tell me if that hypothesis is true, and if so in which version the feature was introduced.
For example
(1) Here it is stated that the option doesn't do anything. The book in question claims to cover "GCC 4.x". The book came out 2006.
(2) Here a compiler bug is being reported against the option, therefore I conclude in that version it must do at least something. That seems to be gcc 4.6.1.
So although I can no longer find evidence of exactly in which version the feature was implemented, at least there is evidence that this has changed over time.
I have tried looking through the changelogs for all the various GCC 4.x versions to no avail (and normally they are pretty good so the lack of information there almost implies that I am wrong and nothing has changed between versions.)
Edit: This seems to imply that perhaps it did work, but I need to "recompile crtstuff.c", but I don't really know where I find that file or how I do that.
I believe 4.4 is the version that added support for this feature. I demonstrate below that 4.1 doesn't work while 4.4 does, on something that needs a large data block (rather than code). I'm not sure about 4.2 and 4.3, but both your example and my memory suggest 4.3 didn't have working support for this. My example should let you validate whether a particular installation works or not though, on an otherwise easy to compile bit of code.
As background, I maintain a program that's a fork of the stream benchmark, modified specially to use 64 bit structures for testing larger systems. I was plagued with these "relocation truncated to fit" errors until I started using "-mcmodel=large", and my fork won't compile/run unless that really does work. The oldest version of gcc I've definitely found my program compatible with is the 4.4.5 that ships with Debian Squeeze.
Here's a complete test case showing my fork of stream compiling and using >4GB of RAM with the large model, after failing to do so without the option:
$ gcc --version
gcc (Debian 4.4.5-8) 4.4.5
...
$ git clone https://github.com/gregs1104/stream-scaling.git
$ cd stream-scaling
$ gcc -O3 -DN=200000000 -fopenmp stream.c -o stream
/tmp/cca8rR1I.o: In function `checkSTREAMresults':
stream.c:(.text+0x34): relocation truncated to fit: R_X86_64_32S against `.bss'
...
stream.c:(.text+0x6ab): additional relocation overflows omitted from the output
collect2: ld returned 1 exit status
$ gcc -O3 -DN=200000000 -fopenmp stream.c -o stream -mcmodel=large
$ ./stream
-------------------------------------------------------------
STREAM version $Revision: 5.9 $
-------------------------------------------------------------
This system uses 8 bytes per DOUBLE PRECISION word.
-------------------------------------------------------------
Array size = 200000000, Offset = 0
Total memory required = 4577.6 MB.
...
And here's what happens on a version of gcc that doesn't have the large model, one running RedHat 5 derived software (CentOS 5.8):
$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52)
...
$ gcc -O3 -DN=200000000 -fopenmp stream.c -o stream -mcmodel=large
stream.c:1: sorry, unimplemented: code model ‘large’ not supported yet
So on older versions of gcc, it should throw that error out, not just ignore the option.
crtstuff is a library coming with gcc. The bug report you linked to on the gcc mailing list was from someone trying to build their own gcc for a RedHat 5 system, which as you can see in this last example ships with gcc 4.1. They rebuilt part of gcc with the large model, but it was still linking against the original, 4.1 built crtstuff library. You shouldn't run into that problem if you're using a properly packaged gcc, which is why it wasn't considered a real bug by the gcc developers. I think you just need gcc 4.4 or later.