In fact, most/all linkers work this way. For example, libXm
the motif library contains symbols that duplicate symbols in
libXt (i.e. 'overload' them). Thus linking -lXm -lXt will
produce correct libraries, whereas -lXt -lXm will create apps with
weird coredumps/bad behaviour.
--linas
It's been rumoured that The Chazman said:
>
> > I've created two libraries (static ones)
> > and the second one uses a function from
> > the first one.
> >
> > I normally link them like this
> >
> > ar r lib1.a lib1.o
> > ranlib r lib1.a
> >
> > ar r lib2.a lib2.o
> > ranlib r lib2.a
> >
> > then I try to link my program like this
> >
> > gcc -o program program.o -l1 -l2
> >
> > The linker keeps telling me that it's
> > impossible to find the function called
> > in the second library which is normally
> > present in the first one. Everything starts
> > to work when I call this function in program.c.
> >
> > Does anybody know how to solve this ?
>
> Reverse the order in which the libraries are linked:
>
> gcc -o program program.o -l2 -l1
>
> GNU ld (the linker called by gcc) will link in only what is needed
> up until the current point. If program.o doesn't call anything in
> lib1, then lib1 will be ignored in your original comand line. The
> linker then moves on to lib2, which is needed because program.o
> references something in it. If this generates a dependency on a
> symbol in lib1, that will go unresolved, because the linker does not
> go back and try lib1 again. Each library is linked once, in the order
> given on the command line. If you want the linker to try a library
> multiple times, you must list it multiple times on the command line,
> as in:
>
> gcc -o program program.o -l1 -l2 -l1
>
> This is perfectly legal, and in fact, used all the time by gcc for
> its own internal and standard libraries.
>
> ------Carl
>
