HI everybody I am a beginner for both openMP and makefile. Here is my problem.
I usually compile simple openMP code via terminale using:
g++-10 -o file.exe -fopenmp file.cxx
Now I want to modify a code, which consists in many file linked together, adding openMP libraries. Indeed I have to change the already existing makefile and I have no idea how to do it. The openMP libraries are used only in the file "esercizio1.1.cxx".
Here the makefile:
esercizio1.1 : esercizio1.1.o random.o
g++ -o esercizio1.1 esercizio1.1.o random.o
esercizio1.1.o : esercizio1.1.cxx funzioni.h random.h
g++ -c -o esercizio1.1.o esercizio1.1.cxx
random.o : random.cxx random.h
g++ -c -o random.o random.cxx
clean:
rm esercizio1.1
Here an example of how I tried to modify my makefile. I renamed my file and I added
g++-10 -fopenmp
to all the line at the same time, to all the line one per time. but still does not work. Here an example:
esercizio : esercizio.o random.o
g++-10 -fopenmp esercizio.o random.o -o esercizio
esercizio.o : esercizio.cc funzioni.h random.h
g++-10 -fopenmp esercizio.cc -o esercizio.o
random.o : random.cc random.h
g++ random.cc -o random.o
clean:
rm esercizio
Here is the error:
Undefined symbols for architecture x86_64:
"__ZN6Random6RannyuEv", referenced from:
_main._omp_fn.0 in ccA635Wn.o
"__ZN6Random8SaveSeedEv", referenced from:
_main in ccA635Wn.o
"__ZN6Random9SetRandomEPiii", referenced from:
_main in ccA635Wn.o
"__ZN6RandomC1Ev", referenced from:
_main in ccA635Wn.o
"__ZN6RandomD1Ev", referenced from:
_main in ccA635Wn.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make: *** [esercizio.o] Error 1
Does it exist a guide for makefile beginner?
Anyway I would appreciate if someone helped me. Thanks in advance.
"C++ compilers are picky and may come with different ABIs, thus mixing different C++ compilers in the same project isn't advised. You are compiling random.cc with g++, which on macOS is a symlink to Apple's clang++. Use g++-10 instead. Also, g++ -o random.o random.cc produces an executable file, not an object file. Leave it as g++-10 -c -o random.o random.cc."
credits to Hristo Iliev. Thank you.
Related
I am trying to install the emzed python package for LC/MS analysis. This package is dependent on PyQt4 and PyQWT. I have installed everything but have not been able to build PyQWT. I have jumped through so many errors and I have been stuck on this linking error for a while.
I have tried modifying the makefile (Qwt_version_info.mak) to pass it include directories. I do not know how to specify the appropriate linking library to get his too compile (the QTextStream, etc)
$ make -f qwt_version_info.mak
Are we linking yet?1
Are we linking yet?2
Are we linking yet?3
Are we linking yet?4
Are we linking yet?5
g++ -v -headerpad_max_install_names -o qwt_version_info.app/Contents/MacOS/qwt_version_info qwt_version_info.o
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
"/Library/Developer/CommandLineTools/usr/bin/ld" -demangle -lto_library /Library/Developer/CommandLineTools/usr/lib/libLTO.dylib -dynamic -arch x86_64 -headerpad_max_install_names -macosx_version_min 10.9.0 -o qwt_version_info.app/Contents/MacOS/qwt_version_info qwt_version_info.o -lc++ -lSystem /Library/Developer/CommandLineTools/usr/lib/clang/10.0.1/lib/darwin/libclang_rt.osx.a
Undefined symbols for architecture x86_64:
"hex(QTextStream&)", referenced from:
_main in qwt_version_info.o
"QArrayData::deallocate(QArrayData*, unsigned long, unsigned long)", referenced from:
QTypedArrayData<unsigned short>::deallocate(QArrayData*) in qwt_version_info.o
"QTextStream::QTextStream(QIODevice*)", referenced from:
_main in qwt_version_info.o
"QTextStream::~QTextStream()", referenced from:
_main in qwt_version_info.o
"QTextStream::operator<<(char const*)", referenced from:
_main in qwt_version_info.o
"QTextStream::operator<<(int)", referenced from:
_main in qwt_version_info.o
"QFile::open(QFlags<QIODevice::OpenModeFlag>)", referenced from:
_main in qwt_version_info.o
"QFile::QFile(QString const&)", referenced from:
_main in qwt_version_info.o
"QFile::~QFile()", referenced from:
_main in qwt_version_info.o
"QString::fromAscii_helper(char const*, int)", referenced from:
QString::QString(char const*) in qwt_version_info.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [qwt_version_info.app/Contents/MacOS/qwt_version_info] Error 1
This is the makefile.
1591 $ cat qwt_version_info.mak
#############################################################################
# Makefile for building: qwt_version_info.app/Contents/MacOS/qwt_version_info
# Generated by qmake (2.01a) (Qt 4.8.7) on: Tue Aug 13 11:31:21 2019
# Project: qwt_version_info.pro
# Template: app
# Command: /usr/local/opt/qt#4/bin/qmake -spec /usr/local/etc/qt4/mkspecs/macx-g++ -o qwt_version_info.mak qwt_version_info.pro
#############################################################################
####### Compiler, tools and options
CC = gcc
CXX = g++
DEFINES =
CFLAGS = -pipe $(DEFINES)
CXXFLAGS = -pipe -std=c++11 $(DEFINES)
INCPATH = -I/usr/local/etc/qt4/mkspecs/macx-g++ -I. -I../qwt-5.2/src -I/usr/local/Cellar/qt#4/4.8.7_5/lib/QtCore.framework/Versions/4/Headers -I/usr/local/Cellar/sip/4.19.8_12/include -I/Users/Danny/.virtualenvs/emzed2.7/lib/python2.7/site-packages/numpy/core/include
LINK = g++
LFLAGS = -headerpad_max_install_names
LIBS = $(SUBLIBS)
AR = ar cq
RANLIB = ranlib -s
QMAKE = /usr/local/opt/qt#4/bin/qmake
TAR = tar -cf
COMPRESS = gzip -9f
COPY = cp -f
SED = sed
COPY_FILE = cp -f
COPY_DIR = cp -f -R
STRIP =
INSTALL_FILE = $(COPY_FILE)
INSTALL_DIR = $(COPY_DIR)
INSTALL_PROGRAM = $(COPY_FILE)
DEL_FILE = rm -f
SYMLINK = ln -f -s
DEL_DIR = rmdir
MOVE = mv -f
CHK_DIR_EXISTS= test -d
MKDIR = mkdir -p
export MACOSX_DEPLOYMENT_TARGET = 10.9
####### Output directory
OBJECTS_DIR = ./
####### Files
SOURCES = qwt_version_info.cpp
OBJECTS = qwt_version_info.o
DIST = /usr/local/Cellar/qt#4/4.8.7_5/etc/qt4/mkspecs/common/unix.conf \
/usr/local/Cellar/qt#4/4.8.7_5/etc/qt4/mkspecs/common/mac.conf \
/usr/local/Cellar/qt#4/4.8.7_5/etc/qt4/mkspecs/common/gcc-base.conf \
/usr/local/Cellar/qt#4/4.8.7_5/etc/qt4/mkspecs/common/gcc-base-macx.conf \
/usr/local/Cellar/qt#4/4.8.7_5/etc/qt4/mkspecs/common/g++-base.conf \
/usr/local/Cellar/qt#4/4.8.7_5/etc/qt4/mkspecs/common/g++-macx.conf \
qwt_version_info.pro
QMAKE_TARGET = qwt_version_info
DESTDIR =
TARGET = qwt_version_info.app/Contents/MacOS/qwt_version_info
first: all
####### Implicit rules
.SUFFIXES: .o .c .cpp .cc .cxx .C
.cpp.o:
$(CXX) -c $(CXXFLAGS) $(INCPATH) -o "$#" "$<"
.cc.o:
$(CXX) -c $(CXXFLAGS) $(INCPATH) -o "$#" "$<"
.cxx.o:
$(CXX) -c $(CXXFLAGS) $(INCPATH) -o "$#" "$<"
.C.o:
$(CXX) -c $(CXXFLAGS) $(INCPATH) -o "$#" "$<"
.c.o:
$(CC) -c $(CFLAGS) $(INCPATH) -o "$#" "$<"
####### Build rules
all: qwt_version_info.mak qwt_version_info.app/Contents/PkgInfo qwt_version_info.app/Contents/Resources/empty.lproj $(TARGET)
$(TARGET): $(OBJECTS)
#$(CHK_DIR_EXISTS) qwt_version_info.app/Contents/MacOS/ || $(MKDIR) qwt_version_info.app/Contents/MacOS/
$(LINK) -v $(LFLAGS) -o $(TARGET) $(OBJECTS) $(OBJCOMP) $(LIBS)
$(info Are we linking yet?1)
qwt_version_info.mak: qwt_version_info.pro /usr/local/etc/qt4/mkspecs/macx-g++/qmake.conf /usr/local/Cellar/qt#4/4.8.7_5/etc/qt4/mkspecs/common/unix.conf \
/usr/local/etc/qt4/mkspecs/common/mac.conf \
/usr/local/Cellar/qt#4/4.8.7_5/etc/qt4/mkspecs/common/gcc-base.conf \
/usr/local/etc/qt4/mkspecs/common/gcc-base-macx.conf \
/usr/local/Cellar/qt#4/4.8.7_5/etc/qt4/mkspecs/common/g++-base.conf \
/usr/local/etc/qt4/mkspecs/common/g++-macx.conf
$(QMAKE) -spec /usr/local/etc/qt4/mkspecs/macx-g++ -o qwt_version_info.mak qwt_version_info.pro
/usr/local/Cellar/qt#4/4.8.7_5/etc/qt4/mkspecs/common/unix.conf:
/usr/local/etc/qt4/mkspecs/common/mac.conf:
/usr/local/Cellar/qt#4/4.8.7_5/etc/qt4/mkspecs/common/gcc-base.conf:
/usr/local/etc/qt4/mkspecs/common/gcc-base-macx.conf:
/usr/local/Cellar/qt#4/4.8.7_5/etc/qt4/mkspecs/common/g++-base.conf:
/usr/local/etc/qt4/mkspecs/common/g++-macx.conf:
qmake: FORCE
#$(QMAKE) -spec /usr/local/etc/qt4/mkspecs/macx-g++ -o qwt_version_info.mak qwt_version_info.pro
$(info Are we linking yet?2)
qwt_version_info.app/Contents/PkgInfo:
#$(CHK_DIR_EXISTS) qwt_version_info.app/Contents || $(MKDIR) qwt_version_info.app/Contents
#$(DEL_FILE) qwt_version_info.app/Contents/PkgInfo
#echo "APPL????" >qwt_version_info.app/Contents/PkgInfo
qwt_version_info.app/Contents/Resources/empty.lproj:
#$(CHK_DIR_EXISTS) qwt_version_info.app/Contents/Resources || $(MKDIR) qwt_version_info.app/Contents/Resources
#touch qwt_version_info.app/Contents/Resources/empty.lproj
:
#$(DEL_FILE)
#sed -e "s,#SHORT_VERSION#,1.0,g" -e "s,#TYPEINFO#,????,g" -e "s,#ICON#,,g" -e "s,#EXECUTABLE#,qwt_version_info,g" -e "s,#TYPEINFO#,????,g" >
dist:
#$(CHK_DIR_EXISTS) .tmp/qwt_version_info1.0.0 || $(MKDIR) .tmp/qwt_version_info1.0.0
$(COPY_FILE) --parents $(SOURCES) $(DIST) .tmp/qwt_version_info1.0.0/ && (cd `dirname .tmp/qwt_version_info1.0.0` && $(TAR) qwt_version_info1.0.0.tar qwt_version_info1.0.0 && $(COMPRESS) qwt_version_info1.0.0.tar) && $(MOVE) `dirname .tmp/qwt_version_info1.0.0`/qwt_version_info1.0.0.tar.gz . && $(DEL_FILE) -r .tmp/qwt_version_info1.0.0
$(info Are we linking yet?3)
clean:compiler_clean
-$(DEL_FILE) $(OBJECTS)
-$(DEL_FILE) *~ core *.core
####### Sub-libraries
distclean: clean
-$(DEL_FILE) -r qwt_version_info.app
-$(DEL_FILE) qwt_version_info.mak
compiler_clean:
####### Compile
$(info Are we linking yet?4)
qwt_version_info.o: qwt_version_info.cpp
$(CXX) -c $(CXXFLAGS) $(INCPATH) -o qwt_version_info.o qwt_version_info.cpp
$(info Are we linking yet?5)
####### Install
install: FORCE
uninstall: FORCE
FORCE:
Any help is much appreciated.
Update:
under
/usr/local/Cellar/qt#4/4.8.7_5/lib/QtCore.framework I found a binary called QtCore. I renamed it libQtCore.so and when I linked it with this binary this is my new error message:
$ g++ -v -headerpad_max_install_names -o qwt_version_info.app/Contents/MacOS/qwt_version_info qwt_version_info.o -L/usr/local/Cellar/qt#4/4.8.7_5/lib/QtCore.framework -lQtCore
"/Library/Developer/CommandLineTools/usr/bin/ld" -demangle -lto_library /Library/Developer/CommandLineTools/usr/lib/libLTO.dylib -dynamic -arch x86_64 -headerpad_max_install_names -macosx_version_min 10.14.0 -o qwt_version_info.app/Contents/MacOS/qwt_version_info -L/usr/local/Cellar/qt#4/4.8.7_5/lib/QtCore.framework qwt_version_info.o -lQtCore -lc++ -lSystem /Library/Developer/CommandLineTools/usr/lib/clang/10.0.1/lib/darwin/libclang_rt.osx.a
Undefined symbols for architecture x86_64:
"QArrayData::deallocate(QArrayData*, unsigned long, unsigned long)", referenced from:
QTypedArrayData<unsigned short>::deallocate(QArrayData*) in qwt_version_info.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Now I just need help finding where the library binary for theQArrayData symbols is found. I have not been able to find anything helpful on google.
This may not be the complete answer yet, but its too large to put into a comment.
So lets focus on the single line here:
g++ -v -headerpad_max_install_names -o qwt_version_info.app/Contents/MacOS/qwt_version_info qwt_version_info.o
Now you are getting undefined references to things like: QByteArray and QTextStream. These all live in the library (IIRC) qtxcore or qtxcored (debug) where the x is the qt version. So I imagine for you it is libqt4core.so or libqt4cored.so.
So we need two bits of information, we need to know where this is install and which type (debug or release) you have.
The libraries are usually somewhere in /usr/lib/... and you will find libqt5core[d].so somewhere in there (IIRC /usr/lib/qt4/ - but that is a bit of a guess).
Lets assume you have the debug libraries - but both may well be there, then we can link that library in to your linker line:
Note: just run this line manually to start with and then we will add it to your makefile.
g++ -v -headerpad_max_install_names -o qwt_version_info.app/Contents/MacOS/qwt_version_info qwt_version_info.o -L/usr/lib/qt4 -lqt4cored
Here you can see that we have added a path to where the library is (-L...) and the library itself (-l...).
Now this will enable your linker to find QByteArray etc... but then you will probably have a few more things you are missing depending what bits of Qt you are using. Here is a list of other possible libs you may need to add:
libQt4Gui.so
libQt4Core.so
libQt4DBus.so
libQt4PrintSupport.so
libQt4Widgets.so
libQt4Network.so
libQt4XcbQpa.so
libQt4Svg.so
libicui18n.so
libicuuc.so
libicudata.so
Note: I got this list from another question I was answering a long while back so it may need editing and you may or may-not want to use the debug version (e.g. libQt5Gui.so -> libQt5Guid.so). The list is in no particular order.
So you could end up with:
g++ -v -headerpad_max_install_names -o qwt_version_info.app/Contents/MacOS/qwt_version_info qwt_version_info.o -L/usr/lib/qt4 -lqt4cored -licudata -licuuc ... etc...
Get this line working and then we can see about adding it to your makefile - adding the libs/paths is trivial.
I'm trying to get my head around how the linking process works when producing an executable. To do that I'm reading Ian Taylor's blog series about it, but a lot of it is beyond me at the moment - so I'd like to see how it works in practice.
At the moment I produce some object files and link them via gcc with:
gcc -m32 -o test.o -c test.c
gcc -m32 -o main.o -c main.c
gcc -m32 -o test main.o test.o
How do I replicate the gcc -m32 -o test main.o test.o stage using ld?
I've tried a very naive: ld -A i386 ./test.o ./main.o
But that returns me these errors:
ld: i386 architecture of input file `./test.o' is incompatible with i386:x86-64 output
ld: i386 architecture of input file `./main.o' is incompatible with i386:x86-64 output
ld: warning: cannot find entry symbol _start; defaulting to 00000000004000b0
./test.o: In function `print_hello':
test.c:(.text+0xd): undefined reference to `_GLOBAL_OFFSET_TABLE_'
test.c:(.text+0x1e): undefined reference to `puts'
./main.o: In function `main':
main.c:(.text+0x15): undefined reference to `_GLOBAL_OFFSET_TABLE_
I'm most confused by _start and _GLOBAL_OFFSET_TABLE_ being missing - what additional info does gcc give to ld to add them?
Here are the files:
main.c
#include "test.h"
void main()
{
print_hello();
}
test.h
void print_hello();
test.c
#include <stdio.h>
void print_hello()
{
puts("Hello, world");
}
#sam : I am not the best people to answer your question because I am a beginner in compilation. I know how to compile programs but I do not really understand all the details (https://en.wikipedia.org/wiki/Compilers:_Principles,_Techniques,_and_Tools)
So, I decided this year to try to understand how compilation works and I tried to do, more or less, the same things as you tried a few days ago. As nobody has answered, I am going to expose what I have done but I hope an expert will supplement my answer.
Short answer : It is recommended to not use ld directly but to use gcc directly instead. Nevertheless, it is, as you write, interesting to know how the linking process works. This command works on my computer :
ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test test.o main.o /usr/lib/crt1.o /usr/lib/libc.so /usr/lib/crti.o /usr/lib/crtn.o
Very Long answer :
How did I find the command above ?
As n.m suggested, run gcc with -v option.
gcc -v -m32 -o test main.o test.o
... /usr/libexec/gcc/x86_64-redhat-linux/4.8.5/collect2 ... (many
options and parameters)....
If you run ld with these options and parameters (copy and paste), it should work.
Try your command with -m elf_i386 (cf. collect2 parameters)
ld -m elf_i386 test.o main.o
ld: warning: cannot find entry symbol _start; ....
Look for symbol _start in object files used in the full ld command.
readelf -s /usr/lib/crt1.o (or objdump -t)
Symbol table '.symtab' contains 18 entries: Num: Value Size
Type Bind Vis Ndx Name... 11: 00000000 0 FUNC
GLOBAL DEFAULT 2 _start
Add this object to your ld command :ld -m elf_i386 test.o main.o /usr/lib/crt1.o
... undefined reference to `__libc_csu_fini'...
Look for this new reference in object files. It is not so obvious to know which library/object files are used because of -L, -l options and some .so include other libraries. For example, cat /usr/lib/libc.so. But, ld with --trace option helps. Try this commandld --trace ... (collect2 parameters)At the end, you should findld -m elf_i386 -o test test.o main.o /usr/lib/crt1.o /usr/lib/libc_nonshared.a /lib/libc.so.6 /usr/lib/crti.oor shorter (cf. cat /usr/lib/libc.so) ld -m elf_i386 -o test test.o main.o /usr/lib/crt1.o /usr/lib/libc.so /usr/lib/crti.o
It compiles but it does not run (Try to run ./test). It needs the right -dynamic-linker option because it is a dynamically linked ELF executable. (cf collect2 parameters to find it) ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test test.o main.o /usr/lib/crt1.o /usr/lib/libc.so /usr/lib/crti.o But, it does not run (Segmentation fault (core dumped)) because you need the epilogue of the _init and _fini functions (https://gcc.gnu.org/onlinedocs/gccint/Initialization.html). Add the ctrn.o object. ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test test.o main.o /usr/lib/crt1.o /usr/lib/libc.so /usr/lib/crti.o /usr/lib/crtn.o./test
Hello, world
I have a library defined in libadd.asm, it exposes one "function" _add. I have a .c source file that refers to add and I'm trying to get the two object files to link, but am encountering this error regardless of the order in which I link the object files:
Undefined symbols for architecture x86_64:
"_add", referenced from:
_main in prog.o
Here's the code:
// prog.c
#include <stdio.h>
int add();
int main() {
printf("%d\n", add(4, 5));
return 0;
}
And here's the assembly file. It almost certainly doesn't respect the appropriate calling convention. I don't really understand what I should be doing to shuffle the values between registers. (That's what I was trying to figure out originally.)
; libadd.asm
_add:
add eax, edx
ret
Here's what I'm using to the tiny project. I'm intentionally shadowing the implicit .c.o rule with one that does as little as possible and ignores *FLAGS. I'm using cc to drive the linker because that's the simplest way I know to link in the c runtime/standard library/whatever it's called. I've always tried linking with prog.o and libadd.o in the other order.
all: prog
prog: prog.o libadd.o
$(CC) -o prog $^
%.o: %.asm
nasm -f macho64 -o $# $<
%.o: %.c
$(CC) -c -o $# $<
clean:
$(RM) $(wildcard *.o)
running make produces the following output
cc -c -o prog.o prog.c
nasm -f macho64 -o libadd.o libadd.asm
cc -o prog prog.o libadd.o
Undefined symbols for architecture x86_64:
"_add", referenced from:
_main in prog.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [prog] Error 1
Exit 2
libadd.o gets assembled successfully and appears to have the right symbol in it.
% nm libadd.o
0000000000000000 t _add
Why is ld complaining that it can't find the symbol?
I want to create static library and something goes wrong. I have makefile:
static: main.c tree.c
gcc -c -Wall tree.c -o tree.o
ar crs libtree.a tree.o
gcc -Wall -static main.c -L. -ltree -o main
./main
When I write "make static", it shows me:
gcc -c -Wall tree.c -o tree.o
ar crs libtree.a tree.o
gcc -Wall -static main.c -L. -ltree -o main
ld: library not found for -lcrt0.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [static] Error 1
It created files: tree.o and libtree.a. I don't know why it doesn't want to find a library. Do you know how to solve it?
Most probably, your system is not set up for static linking. Most newer Linux distributions aren't as static linking is highly discouraged.
Look for a package named glibc-static or similar and install.
In case your system is not Linux (could be MacOS X as well, you didn't state that) - You're doomed. Static linking is not supported on that platform at all.
I got a problem with link objective files on a Mac OS X. Tracing back the problem is,
here is my C hello world program
#include <stdio.h>
int main(){
printf("Hello, world!\n");
return 0;
}
//Compile with gcc (clang LLVM compiler on mac)
$ gcc -c hello.c
The output file is hello.o
link with gcc and run the executable is
$ gcc hello.o -o hello
$ ./hello
Now, I have to use the mac linker program ld or Ld to link the the objective files instead of gcc. In this case, what arguments should I pass into the ld program in order to get the program run? A simple pass in the object file name, i.e.
$ ld hello.o
resulting in
ld: warning: -macosx_version_min not specified, assuming 10.6
Undefined symbols for architecture x86_64:
"_printf", referenced from:
_main in hello.o
"start", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for inferred architecture x86_64
So what other files that i need to include to link or architecture information that I need to specify? Thanks.
For a reference, my complete linker options are
ld -demangle -dynamic -arch x86_64
-macosx_version_min 10.9.0
-o hello
-lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.0/lib/darwin/libclang_rt.osx.a
Okay, I had this question before too. Yes, the reason for the linker errors is because you need to feed it all the magic arguments that gcc does. And the easy way to discover those is to invoke the -v option on gcc to reveal all the commands executed in the compilation stages. In your case, run:
gcc hello.o -o hello -v
...the output of which, on my system, ends with the line:
/usr/libexec/gcc/i686-apple-darwin9/4.2.1/collect2 -dynamic -arch i386 -macosx_version_min 10.5.8 -weak_reference_mismatches non-weak -o test -lcrt1.10.5.o -L/usr/lib/i686-apple-darwin9/4.2.1 -L/usr/lib/gcc/i686-apple-darwin9/4.2.1 -L/usr/lib/gcc/i686-apple-darwin9/4.2.1 -L/usr/lib/gcc/i686-apple-darwin9/4.2.1/../../../i686-apple-darwin9/4.2.1 -L/usr/lib/gcc/i686-apple-darwin9/4.2.1/../../.. test.o -lgcc_s.10.5 -lgcc -lSystem
I don't know what the collect2 program is, but if you feed all those arguments to ld it should work just the same (at least it does on my system).