I am confused by this command. The man page http://linux.die.net/man/1/ld says it "emulates the emulation linker. You can list the available emulations with the --verbose or -V options." But what does the "available emulations" mean?
For example, I use the following command to link objects:
ld -r -nostdlib -L/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib \
-m elf_x86_64 --verbose ./arch/x86/x86_64.o ./mini-os_app.o ./blkfront.o ./events.o ./fbfront.o \
./gntmap.o ./gnttab.o ./hypervisor.o ./kernel.o ./lock.o ./main.o ./mm.o ./netfront.o ./sched.o \
./lib/ctype.o ./lib/math.o ./lib/printf.o ./lib/stack_chk_fail.o ./lib/string.o ./lib/sys.o \
./lib/xmalloc.o ./lib/xs.o ./xenbus/xenbus.o ./console/console.o ./console/xencons_ring.o \
./console/xenbus.o ./lwip.a -L./arch/x86 -lx86_64 -lc -lglib-2.0 -lvmi -o ./mini-os.o
GNU ld (GNU Binutils for Ubuntu) 2.22
Supported emulations:
elf_x86_64
elf32_x86_64
elf_i386
i386linux
elf_l1om
elf_k1om
using internal linker script:
==================================================
(>>> scripts displayed here, neglected <<<)
==================================================
...
attempt to open /media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a succeeded
(>>> lots of *.o listed here for libc.a <<<)
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a)mm.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a)sched.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a)setup.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a)time.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a)traps.o
...
attempt to open /media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libglib-2.0.a succeeded
(>>> why no *.o files listed here? <<<)
attempt to open /media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a succeeded
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-accessors.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-convenience.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-core.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-events.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-memory.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-read.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-interface.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-kvm.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-memory_cache.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-xen.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)lt1-libvmi_la-core.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)lt2-libvmi_la-memory.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-symbols.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)lt3-libvmi_la-core.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-kpcr.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)lt4-libvmi_la-memory.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-peparse.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-process.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)grammar.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)lexicon.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-cache.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-strmatch.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-file.o
As showed in the above outputs, it seems that each *.a library should have their own *.o listed. But what is the meaning if no *.o listed for a certain *.a library,such as glib-2.0.a showed above ?
Thank you in advance!
The ld -m option is used while linking .o files to create an executable file for a hardware platform provided as an argument with -m option.
E.g. if you specify ld -m elf_x86_64 ..., an executable file is created (assuming no error occurred) that can run on a x86_64 system. This is generally used during cross compiling. i.e. in the situation when you are trying to create an executable for a platform different from the one it is being built.
Related
I have been working on a 32-bit operating system project written in C using GNU LD version 2.34 as the linker.
As part of the build process, I use the following command:
ld -m elf_i386 -nostdlib -T ld/loader.ld build/bootloader/loader.o build/bootloader/loader.elf -o loader_full.elf
When using GNU LD version 2.34, this command succeeds. However, when I use a version higher than this, I get the following error:
ld: cannot use executable file 'build/bootloader/loader.elf' as input to a link
If necessary, here is the full Makefile script:
CC_FLAGS = -g -m32 -ffreestanding -nostartfiles -nostdlib -fno-stack-protector
LD_FLAGS = -m elf_i386 -nostdlib
CC := gcc ${CC_FLAGS}
LD := ld ${LD_FLAGS}
BOOTLOADER_DRIVERS = kernel/drivers/disk/ata.c kernel/drivers/io/screen.c kernel/drivers/utils/mem.c kernel/drivers/utils/ports.c
raw: prep os-image.bin
convert_vmdk: os-image.vmdk
all: prep os-image.bin
ESFS_raw_write: ESFS_raw_write.c
gcc $^ -o $#
# run OS in QEMU
run:
qemu-system-i386 -drive format=raw,file=os-image.bin
# assemble boot sector
build/bootloader/boot_sect.bin: boot/boot_sect.asm
nasm $^ -f bin -o $#
# compile second stage bootloader
build/bootloader/loader_2.o build/drivers/*.o: boot/*.c ${BOOTLOADER_DRIVERS}
${CC} -c $^
mv loader.o build/bootloader/loader_2.o
mv *.o build/drivers/
# link object files into kernel loader
build/bootloader/loader.elf: build/bootloader/loader_2.o build/drivers/*.o
${LD} -T ld/loader.ld $^ -o $#
rm build/bootloader/loader_2.o
# assemble first stage bootloader
build/bootloader/loader.o: boot/loader.asm
nasm $^ -f elf -o $#
# link first and second stage bootloaders
build/bootloader/loader_full.elf: build/bootloader/loader.o build/bootloader/loader.elf
${LD} -T ld/loader.ld $^ -o $#
# make bootloader binary file
build/bootloader/loader.bin: build/bootloader/loader_full.elf
objcopy $^ -O binary $#
./scripts/pad_loader.sh
# clean up unnecessary files
# rm build/bootloader/*.o build/bootloader/*.elf build/drivers/*.o
build/kernel/interrupt.o: kernel/cpu/interrupt.asm
nasm $^ -f elf -o $#
# compile kernel & write to 10MB raw drive image
build/kernel/hdd.bin: kernel/drivers/*/*.c kernel/cpu/*.c kernel/libc/*.c build/kernel/interrupt.o kernel/*.c
${CC} $^ -o build/kernel/kernel.o -T ld/kernel.ld
./scripts/write_kernel_to_drive.sh
# concat 3 boot stages into os-image file
os-image.bin: build/bootloader/boot_sect.bin build/bootloader/loader.bin build/kernel/hdd.bin
cat $^ > $#
os-image.vmdk:
VBoxManage convertfromraw os-image.bin os-image.vmdk --format VMDK
VBoxManage internalcommands sethduuid /home/tim/Dev/OSDev/os-image.vmdk 6372c00a-a62e-4241-9a21-90fa4c22f019
# prepare directory structure for build process
prep:
mkdir -p build/bootloader
mkdir -p build/drivers
mkdir -p build/kernel
# clean up build files and os-image binary
clean:
-rm -rf build/
-rm *.bin *.vmdk
-rm ESFS_raw_write
The project is also on GitHub, so you can build it for yourself:
http://github.com/TimCve/OSDev.git
I have just come up with a similar problem.
It seems ld version GNU ld (GNU Binutils) 2.36.1 links the file into an executable format.
To fix it, add -r in your ld command to output a relocatable format file.
From the ld manual:
-r
--relocateable
Generate relocatable output--i.e., generate an output file that can in turn serve as input to ld. This is often called partial linking. As a side effect, in environments that support standard Unix magic numbers, this option also sets the output file's magic number to OMAGIC. If this option is not specified, an absolute file is produced. When linking C++ programs, this option will not resolve references to constructors; to do that, use -Ur. This option does the same thing as -i.
It's not that ld can't take ELF files as input. It's that it won't take executable files as input. The error is:
ld: cannot use executable file '...' as input to a link
See https://sourceware.org/bugzilla/show_bug.cgi?id=26223
Does it work to simply use chmod -x $# after building the .elf file?
In my (eclipse-based) multicore MCUXpresso project, I had to add this line to my post-build steps to modify a byte inside of the generated "*.o" file so the linker step which used that file wouldn't complain anymore. This happened after I updated to version 11.6 which includes the LD version mentioned previously. I originally found this on the forums for NXP MCUXpresso, but I assume it will work similarly for just about anyone:
dd if=/dev/zero of="${BuildArtifactFileName}.o" bs=1 seek=16 conv=notrunc count=2
NXP MCUXpresso fix
I am about 3 hours new to Linux/Cygwin/virtually anything even borderline computer science. I have been tasked with installing a program for rotors/propellers for research (XROTOR), but I cannot figure out how to run the program. It seems to have been developed in Fortran (maybe?), and came with a README. The README is asking me to build the file, but I have no clue what that means. I have downloaded Cygwin, and have gotten as far as the "make libPLT.a" line. I then cd'ed to the bin folder, and typed in "make xrotor" like the README states, but I keep getting the following error:
$ make
ifort -c -I../src -O -static ../src/xrotor.f
sh: ifort: command not found
make: *** [Makefile:147: xrotor.o] Error 127
I've included the README as well. I don't know what I'm doing, and I figured this was a decent place to start. Any help is GREATLY appreciated!!!
EDIT: Left the README out for whatever reason, sorry. I've written it out here:
General
XROTOR and its plot library should compile on any Unix system
with normal Fortran-77, C, and X-Windows support. So far,
XROTOR has been tested on the following systems:
DEC-5000
Alpha
SGI
* Sun
* RS/6000
* HP-9000
* Pentium/Linux
The systems marked with "*" have peculiar features which require slight
modifications to the Makefiles in the plotlib/ and bin/ directories.
Examine these Makefiles before building the plot library and Xrotor.
Build Sequence
To install, first build the plot library in ./plotlib ...
% cd plotlib
% make libPlt.a
Then build the programs in ./bin ...
% make xrotor
% make jplot
The README is missing some details, but you need to compile the program from sources,
and to do so you need to adjust some variables in the Makefile's
As prerequisite for compiling you need gcc-fortran,make and library libX11-devel
plus the X11 system for the graphic. Installing xinit is a good start.
$ tar -xf Xrotor7.55.tar.tgz
$ cd Xrotor
$ cd plotlib
than modify config.make to set PLTLIB = libPlt.a
I used my preferred editor, but other are also ok
$ vim config.make
To build:
$ make libPlt.a
gfortran -c -O2 -fdefault-real-8 plt_base.f
gfortran -c -O2 -fdefault-real-8 plt_font.f
gfortran -c -O2 -fdefault-real-8 plt_util.f
gfortran -c -O2 -fdefault-real-8 plt_color.f
gfortran -c -O2 -fdefault-real-8 set_subs.f
gfortran -c -O2 -fdefault-real-8 gw_subs.f
gfortran -c -O2 -fdefault-real-8 ps_subs.f
gcc -c -O2 -DUNDERSCORE Xwin.c
gfortran -c -O2 -fdefault-real-8 plt_old.f
gfortran -c -O2 -fdefault-real-8 plt_3D.f
ar r libPlt.a plt_base.o plt_font.o plt_util.o plt_color.o set_subs.o gw_subs.o ps_subs.o Xwin.o plt_old.o plt_3D.o
ar: creating libPlt.a
ranlib libPlt.a
Than moving to program build directory
$ cd ../bin
again modify Makefile.gfortran to set PLTOBJ = ../plotlib/libPlt.a and LIBS = -L/usr/lib -lX11
$ vim Makefile.gfortran
and build all program in one shot
$ make -f Makefile.gfortran
gfortran -c -I../src -O ../src/xrotor.f
gfortran -c -I../src -O ../src/xoper.f
gfortran -c -I../src -O ../src/xdesi.f
gfortran -c -I../src -O ../src/xmodi.f
...
gfortran -c -I../src -O ../src/plotdata.f
gfortran -o xrotor xrotor.o xoper.o xdesi.o xmodi.o xaero.o xjmap.o xio.o xnoise.o xrotpl.o xcasepl.o xbend.o xinte.o xutils.o jputil.o plutil.o modify.o srclin.o spline.o userio.o vortex.o plotdata.o ../plotlib/libPlt.a -L/usr/lib -lX11
gfortran -c -I../src -O ../src/jplot.f
../src/jplot.f:107:72:
PAUSE 'Hit return to see J values'
1
Warning: Deleted feature: PAUSE statement at (1)
../src/jplot.f:112:72:
PAUSE 'Hit return to see CP values'
1
Warning: Deleted feature: PAUSE statement at (1)
gfortran -o jplot jplot.o xutils.o jputil.o userio.o ../plotlib/libPlt.a -L/usr/lib -lX11
gfortran -c -I../src -O ../src/jplote.f
gfortran -o jplote jplote.o xutils.o jputil.o userio.o ../plotlib/libPlt.a -L/usr/lib -lX11
The Warning means that the PAUSE command does not exist anymore so the progran will
likely not pause on the expected locations.
This could explain why it is not working as expected, but probably as the code is very old some code assumptions about the Unix system are not anymore valid.
Running it after starting the Xwindow graphic system from inside a Xterm
$ ./xrotor
=========================
XROTOR Version 7.55
=========================
Note: The following floating-point exceptions are signalling: IEEE_DENORMAL
STOP COLORSPECTRUM: Non-monotonic color axis. Check COLWIDTH.
Need to edit the COLORSPECTRUMTRP subroutine xrotor/plotlib/plt_color.f. Add the following after line 508
COLWIDTH=(/1.0,1.20000005,0.5,1.4,1.0,1.20000005,1.5/)
I'm new in assembly language, so i am following Dr.Paul Carter's pcasm tutorial(
http://pacman128.github.io/pcasm/
).
Exactly pdf file(http://pacman128.github.io/static/pcasm-book.pdf) page-33, and book's page-23
From that site, i downloaded Linux Example (http://pacman128.github.io/static/linux-ex.zip)
and at the terminal i input
nasm -f coff first.asm
gcc -c driver.c
nasm -f coff asm_io.o
gcc -o first driver.o first.o asm_io.o
But it returned it
Where is problem?
(Screenshot's command -lc is no matter, if there is no -lc, it returned the same thing)
For Linux asm_io doesn't work with 64-bit. You have to create 32-bit programs. Compile C files as 32-bit using the -m32 option. You also have to assemble asm_io.asm with a special define -d ELF_TYPE for this to work on Linux. Don't use coff. Commands like this should work:
nasm -f elf -d ELF_TYPE asm_io.asm
nasm -f elf first.asm
gcc -m32 -c driver.c
gcc -m32 -o first driver.o first.o asm_io.o
If you are truly on 32-bit Linux you will be able to omit -m32
I found that error is from asm_io.asm. You should have to modify asm_io.asm or check define lines.
I am following a tutorial online made a while back and it says to use
ld -s -o testing test.o
to create an output file.
I'm getting the error of
ld: i386 architecture of input file 'test.o' is incompatible with i386:x86-64 output
when trying to run that line.
Test.o was created by nasm -f elf test.asm. It can't be created in 64-bit format sadly.
How should I go about combating this? Thanks so much for your time!!
You can't make a 64bit executable with 32bit code.
If you want to make a 32bit executable, you can use -m elf_i386:
$ ld -s -o test test.o
ld: i386 architecture of input file `test.o' is incompatible
with i386:x86-64 output
$ ld -s -o test test.o -m elf_i386
$
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.