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.
Related
I have gcc installed in /usr/local/bin
[root#iz2 usr]# ls /usr/local/bin | grep gcc
gcc
gcc-ar
gcc-nm
gcc-ranlib
x86_64-pc-linux-gnu-gcc
x86_64-pc-linux-gnu-gcc-7.3.0
x86_64-pc-linux-gnu-gcc-ar
x86_64-pc-linux-gnu-gcc-nm
x86_64-pc-linux-gnu-gcc-ranlib
And there is no gcc in /usr/bin
[root#iz2 usr]# ls /usr/bin | grep gcc
[root#iz2 usr]#
My $PATH like this
[root#iz2 usr]# $PATH
-bash: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin: No such file or directory
when I run commond gcc --version, my linux can't find it, why?
[root#iz2 usr]# gcc --version
-bash: /usr/bin/gcc: No such file or directory
why linux just search /usr/bin directory and ignore the /usr/local/bin directory which has gcc?
It looks like you have not restarted your bash shell since deinstalling /usr/bin/gcc and installing /usr/local/bin/gcc, so it still has an outdated command cache. You can flush the cache using hash -r, or you can just log out and log in again.
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.
I've got a c++-project which uses Clang API, and I'd like to have ability to debug into clang/llvm function when I debugging my project.
I built llvm+clang v3.7.0 using CMake with the following opts:
-DCMAKE_INSTALL_PREFIX=$HOME/opt/llvm -DCMAKE_BUILD_TYPE=Debug
but GDB doesn't step into clang API's functions.
What am I doing wrong?
It's likely what you're doing is not setting a breakpoint on the command line with -cc1 on it. clang forks immediately for error handling purposes, so if you set a breakpoint on main you'll see it happen. If you want to debug starting at clang then you should:
Build with debug symbols (looks like you're doing that)
Run clang with -v to get the various command lines, e.g.
dzur:~/tmp> ~/builds/build-llvm/bin/clang -v t.c -S
"/usr/local/google/home/echristo/builds/build-llvm/bin/clang-3.9" -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name t.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim
-fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -v -dwarf-column-info -debugger-tuning=gdb -coverage-file /usr/local/google/home/echristo/tmp/t.c -resource-dir /usr/local/google/home/echristo/builds/build-llvm/bin/../lib/clang/3.9.0 -internal-isystem /usr/local/include -internal-isystem /usr/local/google/home/echristo/builds/build-llvm/bin/../lib/clang/3.9.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir /usr/local/google/home/echristo/tmp -ferror-limit 19 -fmessage-length 120 -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics
-o t.s -x c t.c
Set a breakpoint on the this command line where you'd like in the sources.
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.
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.