Morten Ofstad
2004-Oct-18 16:03 UTC
[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.
Chris Lattner
2004-Oct-18 16:50 UTC
[LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
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/
Reid Spencer
2004-Oct-18 16:54 UTC
[LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
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>
Morten Ofstad
2004-Oct-18 16:58 UTC
[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.
Maybe Matching Threads
- [LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
- [LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
- [LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
- [LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
- [LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code