ld can't find lib to link

The following is an example to describe my problem:

ld -Lpath1 -Lpath2 -lA -lB -Xlinker -T -Xlinker \
    -W1,-rpath,/usr/local/lib -l-o target
ld: cannot find -lA
collect2: ld returned 2 exit status

Both path1 and path2 are relative paths, and I can find the library A according to the ld's pwd, so why did the ld output this error msg?

Could anyone give me some suggestion to debug this problem?

i miss some, there is a "-static" before a library called rt.

As your suggestion, i try to let gcc drive the ld to do linking process. gcc A.o B.o -mabi=64 -static -lrt -Xlinker -T -Xlinker ld.scrip开发者_Python百科t -W1,-rpath,/usr/local/lib -lmemdbg -o target it don't work.

and then i remove the "-static" option, and another dynamic lib after -lpthread(because rt depend on pthread which is found when i remove the "-static")

gcc A.o B.o -mabi=64 -lrt -lpthread -Xlinker -T -Xlinker ld.script -W1,-rpath,/usr/local/lib -lmemdbg -o target and this time, the objects is linked together successfully.

and then i try to figure out why the "-static" command don't work by passing a "-v" to gcc . some "-L" option appeared, and do find a lib called librt.a in the search list.

i really confused. the version of gcc is 4.3

---

There are various issues that could be factors:

• What name are you looking for? path1/libA.a? path1/libA.so?
• The -W1 option should probably be -Wl, but that would not account for the link error.
• The -l-o option should probably be two options with an argument for the -l option (unless you really have a library lib-o.a or lib-o.so).
• You normally specify at least one object file of your own devising; only the Lex/Yacc libraries (that I know of) provide a main() for you - and that only on classic Unix and not Linux systems.
• If the library files exist where you think they do, are they the correct type? That is, if you are building a 32-bit program, could they be 64-bit libraries - or vice versa? Are they for your hardware? (Normally, I'd expect the linker to say something more apposite than 'cannot find', but this can be an issue.)
• Have you checked permissions on the library files and the directories?
• Would you be better off not invoking the loader directly but using the compiler to invoke the loader for you? My experience is that the compiler knows more about invoking the loader correctly than I do - and I've seen more people come to grief building shared objects when they use ld directly than when using the compiler instead.