[LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
Reid Spencer
reid at x10sys.com
Mon Oct 18 09:54:01 PDT 2004
On Mon, 2004-10-18 at 09:50, Chris Lattner wrote:
> One of the funny things about the LLVM Unix build is that we can build
> libraries in three different ways: as .a files, as .so files, and as .o
> files. The IncludeFile hack is used for libraries compmiled to .a files,
> to make sure that the library is actually linked in. The other two types
> of library (X86 is a .o file version) do not have this problem: they
> "library" either gets linked in as a unit or not.
>
> I'm not sure if VC has something like this, but I strongly suspect it
> does. The trick is getting libx86 to compile as a single unit that is
> forced to link in.
It depends on whether the linker can "relink" a set of object files into
another object file instead of an executable.
Morten, what you want to set up is the ability to do something like:
link a.obj b.obj c.obj /out abc.obj
(pardon my lack of knowledge on the MS linker)
note that the output file is .obj not .exe. If the linker can do that,
then you want to build every library this way. If the "Makefile" in a
lib directory says "BUILD_ARCHIVE = 1" then you also want to build a
regular library (.lib). If it says "SHARED_LIBRARY = 1" then you want to
build a DLL from it (might not be possible, DLLs have some code
requirements we don't support, I think .. e.g. export/import ).
Reid.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041018/c893e6f4/attachment.sig>
More information about the llvm-dev
mailing list