Nilmoni Deb <[EMAIL PROTECTED]> writes:
> > 1) It's traditional Unix behaviour, so changing it will break some
> >programs.
>
> Any example ?
I don't have any specific examples, no.
> > 2) It is more efficient, as the linker can just walk through an
> >archive's symbol table, include al
On Mon, 7 Mar 2005, Ian Lance Taylor wrote:
> Nilmoni Deb <[EMAIL PROTECTED]> writes:
>
> > > This is correct and documented behaviour. All Unix linkers behave
> > > this way.
> >
> > In other words, its a feature, not a bug. It seems that the ICC (intel
> > cc) on linux does not have this featu
Nilmoni Deb <[EMAIL PROTECTED]> writes:
> > This is correct and documented behaviour. All Unix linkers behave
> > this way.
>
> In other words, its a feature, not a bug. It seems that the ICC (intel
> cc) on linux does not have this feature.
Really? I haven't tried it myself.
> Just wondering
On Mon, 7 Mar 2005, Ian Lance Taylor wrote:
> Nilmoni Deb <[EMAIL PROTECTED]> writes:
>
> > Lets say I am running the following command
> >
> > gcc z.o -lX -lY -o z
> >
> > and libX.a depends on a function that is defined in libY.a then the order
> > of linking appears to be important. While
Nilmoni Deb <[EMAIL PROTECTED]> writes:
> Lets say I am running the following command
>
> gcc z.o -lX -lY -o z
>
> and libX.a depends on a function that is defined in libY.a then the order
> of linking appears to be important. While the previous command works, the
> next one (with order re
Lets say I am running the following command
gcc z.o -lX -lY -o z
and libX.a depends on a function that is defined in libY.a then the order
of linking appears to be important. While the previous command works, the
next one (with order reversed) will fail:
gcc z.o -lY -lX -o z
Th
