[LLVMdev] Bytecode Library Names

Reid Spencer reid at x10sys.com
Thu Oct 28 00:48:13 PDT 2004


Some issues about bytecode libraries, their names, and where they get installed 
need to be discussed.

Currently the bytecode libraries are installed to two different places:

$(libdir)
$(bytecode_libdir)

libdir is $(prefix)/lib
bytecode_libdir is $(LLVMGCCDIR)/bytecode-libs

The things that go into $(libdir) are built from the "runtime" directory but 
aren't bytecode libraries, they are .so, .a or .o files (native builds)

The things that go into $(bytecode_libdir) are bytecode libraries, mostly *.bc 
but also libcrtend.a (which contains bytecode)

This creates a certain amount of confusion. When one does an install, 
everything that gets installed should be under the $(prefix) variable 
somewhere. This is almost true today, except for the things that are installed 
into $(bytecode_libdir).

So, to clear up the inconsistency, I would like to redefine:

$(bytecode_libdir) = $(libdir)/llvmbc

This would put bytecode libraries into a separate directory under the normal 
(native) "lib" directory during install. Note that the bytecode libraries MUST 
be located in a separate directory to eliminate confusion with the regular 
system librarys.

For example, say we configure with --prefix=/usr/local (the default) and we 
build an install that puts all the libraries into /usr/local/lib (native and 
bytecode). That would mean that /usr/local/lib/ would contain libcrtend.a

If someone tried a link of a normal (llvm or otherwise) program, it would fail 
horribly if /usr/local/lib was in the library search path because libcrtend.a 
would contain bytecode not native code (linker says "unrecognized file type").

Another way around this is to ensure that we never use the same library name as 
the system counterpart. However, that doesn't help LLVM become a replacement 
for existing compilers and their runtime libraries.

Before I commit changes that move the location of installed bytecode, I thought 
I'd open this topic up for discussion.

Reid.





More information about the llvm-dev mailing list