llvm dev - Oct 2004 - [LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code

Chris Lattner wrote:
>>>Can you explain what goes wrong without the stub?  It's the only
part that
>>>I didn't apply.
>>
>>The X86 backend doesn't get registered since there are no references
to
>>symbols in X86TargetMachine the object file is never pulled in from the
>>library I create, and thus the static intializer for the RegisterTarget
>>is never called...
> 
> I'm not sure how your patch fixes it though.  The only references added
by
> your change would be within the X86 library.  How does this change the
> situation?
Because I'm including the X86TargetMachine header from the application 
(Fibonacci.cpp) .. I know, I know -- but really, I tried everything to 
get the linker to cooperate. I can only generate static libraries (.lib) 
and dynamic libraries (.dll) - there is an option to the linker to force 
symbol references, but it has to be put in the final link for the 
application and then the object X which registers the target has to be 
put in the global namespace with an 'extern "C"' in front to
know it's
name. It's even worse in my opinion.
> 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.
maybe it's possible to put many objects together into one with the 
visual studio compiler also, but I don't really know how to do it... 
especially not if you want to stick with the normal .sln/.vcproj build 
system...

m.

On Mon, 18 Oct 2004, Morten Ofstad wrote:
> > I'm not sure how your patch fixes it though.  The only references
added by
> > your change would be within the X86 library.  How does this change the
> > situation?
>
> Because I'm including the X86TargetMachine header from the application
> (Fibonacci.cpp) .. I know, I know -- but really, I tried everything to
> get the linker to cooperate.
Ugh!  I'm sure you can appreciate the fact that we can't do such a
thing.
The X86 backend isn't even linked into the JIT on hosts that are not X86,
and the JIT even allows for target support to be dynamically loaded:

lli -load yourchip.so foo.bc

Adding X86 specific stuff to clients is not going to work.
> I can only generate static libraries (.lib)
> and dynamic libraries (.dll) - there is an option to the linker to force
> symbol references, but it has to be put in the final link for the
> application and then the object X which registers the target has to be
> put in the global namespace with an 'extern "C"' in front
to know it's
> name. It's even worse in my opinion.
I think forcing a reference is ok.  If you need to add an extern "C"
symbol, that shouldn't be a problem.  Alternatively, compiling the X86
support as a dll would also work, have you tried that?

-Chris

-- 
http://llvm.org/
http://nondot.org/sabre/

> Alternatively, compiling the X86
> support as a dll would also work, have you tried that?
Why is it supposed to work? Linking with an import library will add all 
its symbols? I was not expecting a different behavior between linking 
against a static and a dynamic library...

---
Paolo Invernizzi