Linux from Scratch 5.7.2 Toolchain sanity check - linux

I started the Project "Linux from Scratch" some time ago. First I started with Ubuntu 15.10 64bit and did everything according to the PDF-File. By the Check in paragraph 5.7.2, it didn't worked. Afterwards I started all over again, with CentOS 7.2 but it works neither.In both attempts i got no Errors while compiling and installing the previous packages.
Input:
echo 'int main(){}' > dummy.c
$LFS_TGT-gcc dummy.c
Output:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-lfs-linux-gnu/5.3.0/../../../../x86_64-lfs-linux-gnu/bin/ld: cannot find crt1.o: No such file or directory
/mnt/lfs/tools/bin/../lib/gcc/x86_64-lfs-linux-gnu/5.3.0/../../../../x86_64-lfs-linux-gnu/bin/ld: cannot find crti.o: No such file or directory
/mnt/lfs/tools/bin/../lib/gcc/x86_64-lfs-linux-gnu/5.3.0/../../../../x86_64-lfs-linux-gnu/bin/ld: cannot find -lc
/mnt/lfs/tools/bin/../lib/gcc/x86_64-lfs-linux-gnu/5.3.0/../../../../x86_64-lfs-linux-gnu/bin/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
Input:
readelf -l a.out | grep ': /tools'
Output:
readelf: Error: 'a.out': No such file
I found no solution that worked in StackOverFlow or different platforms.
Here my Output of the version-check.sh:
lfs:~$ bash version-check.sh
bash, version 4.2.46(1)-release
/bin/sh -> /usr/bin/bash
Binutils: version 2.23.52.0.1-55.el7 20130226
bison (GNU Bison) 2.7
/usr/bin/yacc -> /usr/bin/bison
bzip2, Version 1.0.6, 6-Sept-2010.
Coreutils: 8.22
diff (GNU diffutils) 3.3
find (GNU findutils) 4.5.11
GNU Awk 4.0.2
/usr/bin/awk -> /usr/bin/gawk
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)
(GNU libc) 2.17
grep (GNU grep) 2.20
gzip 1.5
Linux version 3.10.0-327.el7.x86_64 (builder#kbuilder.dev.centos.org) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Thu Nov 19 22:10:57 UTC 2015
m4 (GNU M4) 1.4.16
GNU Make 3.82
GNU patch 2.7.1
Perl version='5.16.3';
sed (GNU sed) 4.2.2
tar (GNU tar) 1.26
makeinfo (GNU texinfo) 5.1
xz (XZ Utils) 5.1.2alpha
g++ compilation OK
My ~/.bashrc of the LSF User:
set +h
umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
LFS_TGT=$(uname -m)-lfs-linux-gnu
PATH=/tools/bin:/bin:/usr/bin
export LFS LC_ALL LFS_TGT PATH
My ~/.bash_profile of the LFS User
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
Thanks for your help!

This error occurs when you've not installed the Binutils package properly. ld is provided by the binutils pacakage.
Please adhere to the steps provided in the book becuase if you deviate even a little it'll cause such errors.

Related

Bash: No such file or directory?

I try to use an executable script (wkhtmltopdf) on a Linux shared webserver (Debian, 64bit). I am pretty sure that I compiled everything correct, but whenever I want to execute the file I get as an response :
> ./wkhtmltopdf -H
-bash: ./wkhtmltopdf: No such file or directory
To be sure that the file is there, here the ls output :
> ls
wkhtmltoimage wkhtmltopdf
Furthermore I tested the file command on it, which outputs the following :
> file wkhtmltopdf
wkhtmltopdf: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
My question is now :
Why does bash tells me that there is no 'file or directory', when there obviously is one?
My first guess would be that the shared server does not allow to execute binary files? But shouldn't it then be a problem of permissions, with a different bash output?
Edit :
> id
uid=2725674(p8907906) gid=600(ftpusers) groups=600(ftpusers)
> ls -l wkhtmltopdf
-rwxrwxrwx 1 p8907906 ftpusers 39745960 Jan 20 09:33 wkhtmltopdf
> ls -ld
drwx---r-x 2 p8907906 ftpusers 44 Jan 28 21:02 .
I bet you miss dynamic linker. Just do a
readelf --all ./wkhtmltopdf | grep interpreter
You should get an output like this:
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
There are high chances that you system lacks the interpreter (/lib64/ld-linux-x86-64.so.2 in the example). In this case bash would yell No such file or directory, just like when the binary itself is missing.
You can try to use a different linker. Sometime you can succeed. Just do a:
/path/to/the/linker /path/to/your/executable
This command:
find /lib* -name ld-linux\*
will help you find the linkers on your system. Or you can do the readelf command on some command that does run. It will show you correct, working linker.
OR, since you are running Debian system, just do a
sudo apt-get install wkhtmltopdf
to install native version of the tool :)
In my case
$ readelf --all ./wkhtmltopdf | grep interpreter # readelf: Displays information about ELF files.
[Requesting program interpreter: /lib/ld-linux.so.2]
On a machine where the executable was working:
$ ls -lah /lib/ld-linux.so.2
lrwxrwxrwx 1 root root 25 Apr 16 2018 /lib/ld-linux.so.2 -> i386-linux-gnu/ld-2.27.so
$ dpkg -S /lib/ld-linux.so.2 # -S, --search filename-search-pattern: Search for a filename from installed packages.
libc6:i386: /lib/ld-linux.so.2
So to fix the problem (reference)
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libc6:i386 # GNU C Library: Shared libraries (from apt show)
Missing the linker was my case as well. I could fix it with the help of nsilent22 answer like this:
readelf --all /usr/local/myprogram | grep interpreter
[Requesting program interpreter: /lib64/ld-lsb-x86-64.so.3]
But that linker did not exist anymore.
The old situation in /lib64 was:
ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.31.so
ld-linux-x86-64.so.3 -> ld-linux-x86-64.so.2
So it turned out this was just a symlink to the systems' linker.
Moving over to /lib64 , which itself is a symlink to usr/lib64 and creating a symlink over there did not work. I assume that there are to many symbolic link levels after Debian moved everything into /usr
However creating a 'direct' symlink
ln -s /usr/lib64/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3
did the job; /usr/lib64 now shows:
ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.31.so
ld-lsb-x86-64.so.3 -> /usr/lib64/ld-linux-x86-64.so.2
I ran into this issue on my raspberry pi 4 running aarch64 alpine 3.13. Using the answer provided by #vkersten, I was able to determine that I was missing /lib/ld-linux-aarch64.so.1.
I resolved this by installing gcompat with apk add gcompat.

GCC verbose mode output explanation

I'm new to linux. Can anyone explain to me the following verbose mode output for my hello world program? Also, what do the files crt1.o, crti.o, crtend.o, crtbegin.o and crtn.o and lc and lgcc do? Any other explanatory links are also welcome.
$ gcc -v hello.c
Reading specs from /usr/lib/gcc-lib/i686/3.3.1/specs
Configured with: ../configure --prefix=/usr
Thread model: posix
gcc version 3.3.1
/usr/lib/gcc-lib/i686/3.3.1/cc1 -quiet -v -D__GNUC__=3
-D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=1
hello.c -quiet -dumpbase hello.c -auxbase hello -Wall
-version -o /tmp/cceCee26.s
GNU C version 3.3.1 (i686-pc-linux-gnu)
compiled by GNU C version 3.3.1 (i686-pc-linux-gnu)
GGC heuristics: --param ggc-min-expand=51
--param ggc-min-heapsize=40036
ignoring nonexistent directory "/usr/i686/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/include
/usr/lib/gcc-lib/i686/3.3.1/include
/usr/include
End of search list.
as -V -Qy -o /tmp/ccQynbTm.o /tmp/cceCee26.s
GNU assembler version 2.12.90.0.1 (i386-linux)
using BFD version 2.12.90.0.1 20020307 Debian/GNU
Linux
/usr/lib/gcc-lib/i686/3.3.1/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker
/lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/gcc-lib/i686/3.3.1/crtbegin.o
-L/usr/lib/gcc-lib/i686/3.3.1
-L/usr/lib/gcc-lib/i686/3.3.1/../../.. /tmp/ccQynbTm.o
-lgcc -lgcc_eh -lc -lgcc -lgcc_eh
/usr/lib/gcc-lib/i686/3.3.1/crtend.o
/usr/lib/crtn.o
The first part is the version and configuration data for the compiler driver (that's the gcc binary, which is not actually the compiler itself):
Reading specs from /usr/lib/gcc-lib/i686/3.3.1/specs
Configured with: ../configure --prefix=/usr
Thread model: posix
gcc version 3.3.1
Then it prints the command it uses to call the real compiler, cc1:
/usr/lib/gcc-lib/i686/3.3.1/cc1 -quiet -v -D__GNUC__=3
-D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=1
hello.c -quiet -dumpbase hello.c -auxbase hello -Wall
-version -o /tmp/cceCee26.s
And cc1 prints it's version and config info.
GNU C version 3.3.1 (i686-pc-linux-gnu)
compiled by GNU C version 3.3.1 (i686-pc-linux-gnu)
GGC heuristics: --param ggc-min-expand=51
--param ggc-min-heapsize=40036
Then cc1 tells you what directories it will search for include files.
ignoring nonexistent directory "/usr/i686/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/include
/usr/lib/gcc-lib/i686/3.3.1/include
/usr/include
End of search list.
The compiler is now complete, so gcc tells you the assembler command it will use.
as -V -Qy -o /tmp/ccQynbTm.o /tmp/cceCee26.s
And the assembler, as, gives its version info.
GNU assembler version 2.12.90.0.1 (i386-linux)
using BFD version 2.12.90.0.1 20020307 Debian/GNU
Linux
The assembler is now done so gcc gives the linker command. It's using collect2 as an intermediary to the real linker ld, but that's not important here.
/usr/lib/gcc-lib/i686/3.3.1/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker
/lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/gcc-lib/i686/3.3.1/crtbegin.o
-L/usr/lib/gcc-lib/i686/3.3.1
-L/usr/lib/gcc-lib/i686/3.3.1/../../.. /tmp/ccQynbTm.o
-lgcc -lgcc_eh -lc -lgcc -lgcc_eh
/usr/lib/gcc-lib/i686/3.3.1/crtend.o
/usr/lib/crtn.o
The linker gives no verbose output (try -Wl,-v), so that's it.
The "crt" files mean "C RunTime". They are small sections of code inserted at the start of your program, and at the end. They take care of initialising your global variables, heap, and stack. They call atexit functions after you return from main. And some more besides.
Hope that helps.

Missing some files in Cygwin

Can anyone tell me where to find the following files in Cygwin setup.exe?
sys/socket.h
netinet/in_systm.h
netinet/in.h
netinet/ip.h
arpa/inet.h
netdb.h
here is what -v is printing out
$ make
gcc -g -c -v it.c
Using built-in specs.
Target: i686-w64-mingw32
Configured with: ../gcc44-svn/configure --target=i686-w64-mingw32 --host=i686-w6
4-mingw32 --disable-multilib --disable-nls --disable-win32-registry --prefix=/mi
ngw32 --with-gmp=/mingw32 --with-mpfr=/mingw32 --enable-languages=c,c++
Thread model: win32
gcc version 4.4.3 (GCC)
COLLECT_GCC_OPTIONS='-g' '-c' '-v' '-mtune=generic'
c:/strawberry/c/bin/../libexec/gcc/i686-w64-mingw32/4.4.3/cc1.exe -quiet -v -ip
refix c:\strawberry\c\bin\../lib/gcc/i686-w64-mingw32/4.4.3/ it.c -quiet -dumpba
se it.c -mtune=generic -auxbase it -g -version -o C:\Users\AppData\Local\
Temp\ccuWjX0W.s
ignoring nonexistent directory "/mingw32/include"
ignoring duplicate directory "c:/strawberry/c/lib/gcc/../../include"
ignoring duplicate directory "c:/strawberry/c/lib/gcc/../../lib/gcc/i686-w64-min
gw32/4.4.3/include"
ignoring duplicate directory "c:/strawberry/c/lib/gcc/../../lib/gcc/i686-w64-min
gw32/4.4.3/include-fixed"
ignoring duplicate directory "c:/strawberry/c/lib/gcc/../../lib/gcc/i686-w64-min
gw32/4.4.3/../../../../i686-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
c:\strawberry\c\bin\../lib/gcc/i686-w64-mingw32/4.4.3/../../../../include
c:\strawberry\c\bin\../lib/gcc/i686-w64-mingw32/4.4.3/include
c:\strawberry\c\bin\../lib/gcc/i686-w64-mingw32/4.4.3/include-fixed
c:\strawberry\c\bin\../lib/gcc/i686-w64-mingw32/4.4.3/../../../../i686-w64-ming
w32/include
/mingw/include
End of search list.
GNU C (GCC) version 4.4.3 (i686-w64-mingw32)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p
3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4728d1fc720cf46696475c98813fbdef
i think it is looking in strawberry for the files.
NOTE: netinet/in_system.h is actually spelled netinet/in_systm.h; I've edited your question to correct it.
These should all be part of the cygwin package. You can't have a working Cygwin installation without that package.
They're all under /usr/include.
$ cygcheck -c cygwin
Cygwin Package Information
Package Version Status
cygwin 1.7.16-1 OK
$ cygcheck -l cygwin | wc -l
280
$ cygcheck -l cygwin | egrep 'sys/socket.h|netinet/in_systm.h|netinet/in.h|netinet/ip.h|arpa/inet.h|netdb.h'
/usr/include/netdb.h
/usr/include/netinet/in.h
/usr/include/netinet/in_systm.h
/usr/include/netinet/ip.h
/usr/include/arpa/inet.h
/usr/include/sys/socket.h
$
If those files are missing, you might try reinstalling the cygwin package -- but first make sure you're looking for them in the right place, under /usr/include.

Howto debug a (slow) linker on a debian system

At my company we have a really annoying problem with our linker (ld 2.17). It links very very slow on a relatively fast system (Core Duo, 2GB Ram) and I don't really now how to fix this. It takes about five to ten minutes to compile a relatively big project (which takes about 5 seconds to link on my Gentoo system).
Personally i think it is a huge productivity killer, at least for me. We tried to use a more recent version of ld (2.19) but without any success. I asked in #debian on #freenode, but this problem seems to be very unique. I did not find any information about similar problems on the net. It only happens when we build with debug symbols. I changed the gcc debug-information flags to -g, -g3, and -ggdb, but that did not help either.
So my question is, how do you profile and debug a linker? I have never done anything like it, and I am unable to find any documentation about it. Basically any reasonable gprof gmon.out would be very helpful, as I could ask the binutils developers about a concrete problem. I am just completely oblivious about this.
Edit: We 'fixed' our problem switching to debian lenny on most systems. Thanks for the answers!
You can try gold (binutils-gold) instead of ld.
It is supposed to be faster.
Here is a quote from Wikipedia Gold(linker)
The motivation for writing gold was to
make a linker that is faster than the
GNU linker[3], especially for large
applications coded in C++.
The author of gold (Ian Lance Taylor) has published an (longish) article about linkers where he explains his motifs in writing gold and why most linkers are slow. If you are interested in the inner workings of linkers this article is worth reading.
If you're observing the slowdown running gcc (as opposed to directly running the linker as ld), try compiling with
$ gcc -save-temps -v [... rest of your command line ...]
This will print out all the intermediary commands, such as the internal collect2 and final ld, as well as ensure that the objects passed to those commands will remain on disk even after the command has completed.
Then you should be able to run the commands individually to find the worst stage, and then run it with different options or profiling.
For example,
$ echo 'int main() {}' > test.c
$ gcc -save-temps -v test.c
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/paludis/sys-devel-gcc-4.3.3-r2/work/gcc-4.3.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --disable-libgcj --enable-objc-gc --enable-languages=c,c++,objc,obj-c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.3-r2 p1.1, pie-10.1.5'
Thread model: posix
gcc version 4.3.3 (Gentoo 4.3.3-r2 p1.1, pie-10.1.5)
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-mtune=generic'
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.3/cc1 -E -quiet -v test.c -D_FORTIFY_SOURCE=2 -mtune=generic -fpch-preprocess -o test.i
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-mtune=generic'
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.3/cc1 -fpreprocessed test.i -quiet -dumpbase test.c -mtune=generic -auxbase test -version -o test.s
GNU C (Gentoo 4.3.3-r2 p1.1, pie-10.1.5) version 4.3.3 (x86_64-pc-linux-gnu)
compiled by GNU C version 4.3.3, GMP version 4.2.4, MPFR version 2.4.1-p5.
warning: GMP header version 4.2.4 differs from library version 4.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 20f3dbffbfd03e5311a257ae1239cd71
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-mtune=generic'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/bin/as -V -Qy -o test.o test.s
GNU assembler version 2.19.1 (x86_64-pc-linux-gnu) using BFD version (GNU Binutils) 2.19.1
COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.3/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.3/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.3/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-mtune=generic'
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.3/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/crtbegin.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../.. test.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/crtend.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crtn.o
$ ls
a.out test.c test.i test.o test.s
$ /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.3/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/crtbegin.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../.. test.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/crtend.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crtn.o
$ .../collect2 -v ...
collect2 version 4.3.3 (x86-64 Linux/ELF)
/usr/bin/ld -v --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/crtbegin.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../.. test.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/crtend.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crtn.o
GNU ld (GNU Binutils) 2.19.1
$
If you need help building a debug version of ld, here's a quick recipe to get you going.
$ sudo apt-get install build-essential dpkg-dev
$ sudo apt-get build-dep binutils
$ apt-get source binutils
$ cd binutils-*
$ DEB_BUILD_OPTIONS='debug noopt nostrip' dpkg-buildpackage -uc -us
$ cd ..
$ sudo dpkg -i *.deb
Instead of that quick hack, though, I'd recommend using schroot or sbuild to avoid polluting your own system.
To answer the profiling question; you should look at OProfile - this is a system-level profiler that can profile multiple running processes. It should allow you to identify which sub-process of the link is taking the most time, and furthermore will show which functions the most time is being spent.
I'd like to suggest two ways to check:
use strace to check what files linker is loading/parsing to link; with this you may know is there any unnecessary path is searched by linker.
use ld with -verbose option to know what ld is doing. Five minutes compare to five seconds should not be the linker's problem, it should be some problem of your host machine or some option.

How can I find the version of the Fedora I use?

sudo find /etc | xargs grep -i fedora > searchFedora
gives:
/etc/netplug.d/netplug: # At least on Fedora Core 1
...
But see the Fedora version in the /etc/netplug.d/netplug file. Is it serious?
cat /etc/issue
Or cat /etc/fedora-release as suggested by #Bruce ONeel
You can also try /etc/redhat-release or /etc/fedora-release:
cat /etc/fedora-release
Fedora release 7 (Moonshine)
The proposed standard file is /etc/os-release. See http://www.freedesktop.org/software/systemd/man/os-release.html
You can execute something like:
$ source /etc/os-release
$ echo $ID
fedora
$ echo $VERSION_ID
17
$ echo $VERSION
17 (Beefy Miracle)
The simplest command which can give you what you need but some other good info too is:
hostnamectl
You could try
lsb_release -a
which works on at least Debian and Ubuntu (and since it's LSB, it should surely be on most of the other mainstream distros at least). http://rpmfind.net/linux/RPM/sourceforge/l/ls/lsb/lsb_release-1.0-1.i386.html suggests it's been around quite a while.
cat /etc/*release
It's universal for almost any major distribution.
[Belmiro#HP-550 ~]$ uname -a
Linux HP-550 2.6.30.10-105.2.23.fc11.x86_64 #1 SMP Thu Feb 11 07:06:34 UTC 2010
x86_64 x86_64 x86_64 GNU/Linux
[Belmiro#HP-550 ~]$ lsb_release -a
LSB Version: :core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:deskt
op-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch
Distributor ID: Fedora
Description: Fedora release 11 (Leonidas)
Release: 11
Codename: Leonidas
[Belmiro#HP-550 ~]$
These commands worked for Artik 10 :
cat /etc/fedora-release
cat /etc/issue
hostnamectl
and these others didn't :
lsb_release -a
uname -a
What about uname -a ?
On my installation of Fedora 25 (workstation) all of the distribution ID info was found in this file:
/usr/lib/os.release.d/os-release-workstation
This included,
NAME=Fedora
VERSION="25 (Workstation Edition)"
ID=fedora
VERSION_ID=25
PRETTY_NAME="Fedora 25 (Workstation Edition)"
<...>
VARIANT="Workstation Edition"
VARIANT_ID=workstation
You can simply run this command to get the version number:
rpm -E %fedora
output:
uname -a works with my fc11
use commmand , screenfetch
output format info.

Resources