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...

   RegisterTarget<X86TargetMachine> X("x86", "  IA-32
(Pentium and above)");

I've tried some other ways to resolve it, but so far I've had no luck ..
   any suggestions are appreciated, as this is a problem in other places 
as well - and I'm not happy with the IncludeFile hack, I can well 
understand why you didn't want to apply it.

m.

On Mon, 18 Oct 2004, Morten Ofstad wrote:
> 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?
>    RegisterTarget<X86TargetMachine> X("x86", "  IA-32
(Pentium and above)");
>
> I've tried some other ways to resolve it, but so far I've had no
luck ..
>    any suggestions are appreciated, as this is a problem in other places
> as well - and I'm not happy with the IncludeFile hack, I can well
> understand why you didn't want to apply it.
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.

-Chris

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

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>

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.