[an error occurred while processing this directive]

Isn't the linker different from what I am used to?

Yes. It is not at all like what you are used to:

- The order of objects and libraries is normally _not_ important. The
linker reads _all_ objects including those from libraries into memory
and does the actual linking in one go. Even if you need to put a
library of your own twice on the ld command line on other systems, it
is not needed on the RS/6000 - doing so will even make your linking slower.

- One of the features of the linker is that it will replace an object in
an executable with a new version of the same object:

$ cc -o prog prog1.o prog2.o prog3.o # make prog
$ cc -c prog2.c # recompile prog2.c
$ cc -o prog.new prog2.o prog # make prog.new from prog
# by replacing prog2.o

- The standard C library /lib/libc.a is linked shared, which means that
the actual code is not linked into your program, but is loaded only
once and linked dynamically during loading of your program.

- The ld program actually calls the binder in /usr/lib/bind, and you can
give ld special options to get details about the invocation of the
binder. These are found on the ld man page or in InfoExplorer.

- If your program normally links using a number of libraries (.a files),
you can 'prelink' each of these into an object, which will make your
final linking faster. E.g. do:

$ cc -c prog1.c prog2.c prog3.c
$ ar cv libprog.a prog1.o prog2.o prog3.o
$ ld -r -o libprog.o libprog.a
$ cc -o someprog someprog.c libprog.o

This will solve all internal references between prog1.o, prog2.o and
prog3.o and save this in libprog.o Then using libprog.o to link your
program instead of libprog.a will increase linking speed, and even if
someprog.c only uses, say prog1.o and prog2.o, only those two modules
will be in your final program. This is also due to the fact that the
binder can handle single objects inside one object module as noted above.

If you are using an -lprog option (for libprog.a) above, and still want
to be able to do so, you should name the prelinked object with a
standard library name, e.g. libprogP.a (P identifying a prelinked
object), that can be specified by -lprogP. You cannot use the archiver
(ar) on such an object.

You should also have a look at section 3.01 of this article, in
particular if you have mixed Fortran/C programs.

Dave Dennerline (d.dennerline@bull.com) claims that his experiences
in prelinking on AIX does not save much time since most people have
separate libraries which do not have many dependencies between them,
thus not many symbols to resolve.

[an error occurred while processing this directive]