[libc runtime lib] libc.bc is not a .a file

[llvmbot]

Bugzilla Link	466
Resolution	FIXED
Resolved on	Mar 06, 2010 14:00
Version	1.0
OS	All
Reporter	LLVM Bugzilla Contributor
CC	@lattner

Extended Description

If the same library is passed to LinkLibraries twice in the Libraries parameter,
and that library is not strictly a library (archive), but a bytecode module,
then the function fails with a "duplicate symbol definition" error. This
happens with libraries like libc.bc which really isn't a library.

This doesn't affect anything right now because all the tools ensure that the
list of libraries does not contain duplicates (like -lc -lc). However, the
Linker interface shouldn't depend on that. Where it does become a problem is if
someone puts a -lc on the command line and we enable dependent libraries support
in the linker. We then get an attempt to link -lc twice, once from the command
line use of -lc and once because the linked module specifies that it depends on
-lc.

Two things need to be done to resolve this:

1. Make sure LinkLibraries filters out duplicates.
2. Turn libc.bc into libc.a (and similarly for all other runtime "libs") so that
   if its linked multiple times, its harmless.

[lattner]

LinkLibraries is fine, and this is expected behavior. The problem is that
libc.bc is not an archive.

In particular, it should be fine to do this:

llvmgcc x.c -lfoo -lfoo -lfoo

s/foo/c/ as appropriate.

This is important because you can have stuff like this:

llvmgcc x.c -lfoo -lbar -lfoo

and it should work.

Note that this is somewhat related to Bug 139.

-Chris

[llvmbot]

I think LinkLibraries does need to be fixed. It shouldn't link object files.
Even if it finds a file named libxyz.a in the LibPath, if that file is not a
library, it should emit a warning that the "library" is being skipped. Tools
that use the lib/Linker interface should use LinkFiles to link in object module
files, and LinkLibraries should enforce that. Similarly, LinkFiles shouldn't
link in a library.

While making libc.gc into libc.a will definitely help the immediate situation, I
don't think only fixing that is sufficient.

[lattner]

Even if it finds a file named libxyz.a in the LibPath, if that file is not a
library, it should emit a warning that the "library" is being skipped.

OIC. I wasn't aware that LinkLibraries would accept a bytecode file named
libfoo.a when asked to link -lfoo. I definitely think that's a bug also.

-Chris

[llvmbot]

Yeah, it does. And it doesn't get "-lfoo", just "foo". when it searches the
paths for the libraries it tries both libfoo.a and libfoo.bc. It shouldn't even
try the latter. And, it should use the file type, regardless of its name, to
determine if its a library to link in or an object to emit a warning for.

[lattner]

Totally agreed. We have to get libc into a libc.a first though.

-Chris

[llvmbot]

This has been implemented:

1. Bytecode archives should now have the suffix .bca instead of .a. This avoids
   the gcc compiler from attempting to read our bytecode archives as if it was
   a native archive.
2. The llvm/runtime makefiles and Makefile.rules have been revised to always
   build a lib*.bca file when BYTECODE_LIBRARY=1 is specified in the Makefile.
   In this case the * in lib*.bca will be $(LIBRARYNAME)
3. Made the LinkLibraries function look for lib*.bca instead of lib*.a
4. Made the LinkLibraries produce a warning if it find a lib*.bca that is not an
   archive file. The file is skipped, even if it contains valid bytecode that
   could be linked.
5. Fixed a problem with llvm-ar that thwarted construction of the symbol table
   the first time the archive was built. This means our runtime libraries now
   get symbol tables by default without running llvm-ranlib.

Bug Resolved.