[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