similar to: [LLVMdev] VC++ linking issues, revisited

Jeff, There should be a way to do what we do with the Unix Makefiles and build re-linked object modules. That is, when we build an analysis or transform pass, we create two things: a .o file and a .a file. They contain the same code but the latter is searchable while the former is not. Can you not "pre-link" a bunch of .obj files together with VC++ to produce a new .obj file? And, when

No, VC++ has no way to combine multiple .obj files into one. Nor is there any way to force the entire contents of a .lib file into an executable. Believe me, I looked for a way. Morten couldn't find one either. Even Microsoft's command line tools can't do it. Advantage: GNU. DLLs aren't that slow any more. Windows is so dependent on DLLs (the Win32 API itself is

OK, there may be some light at the end of the tunnel. I *can* force an arbitrary .obj file to become part of the executable, one that is not part of the executable's project. This is sufficient to eliminate the global variable hack Morten introduced for the X86 target. But this still doesn't scale very well, as I'd have to manually enumerate all .objs that are transforms and

Hello, I've been away working on other things so I have not been able to respond to mails on this mailing list for a while. But today I got back and I got the latest version of LLVM from CVS and built it successfully (after I deleted my old config.h which was included instead of the one in the new location)... Jeff Cohen wrote: > OK, there may be some light at the end of the tunnel.

Jeff Cohen wrote: > OK, there may be some light at the end of the tunnel. I *can* force > an arbitrary .obj file to become part of the executable, one that is > not part of the executable's project. This is sufficient to eliminate > the global variable hack Morten introduced for the X86 target. > > But this still doesn't scale very well, as I'd have to manually

There's a problem with the license for ltdl.c when building with VC++. It is under the LGPL, with a special exception: As a special exception to the GNU Lesser General Public License, if you distribute this file as part of a program or library that is built using GNU libtool, you may include it under the same distribution terms that you use for the rest of that program. The problem is,

Hi Jeff and Morten Does anyone of you win32 guys have the guts to move the sed results from *.in files out of the llvm source folders and place them under llvm/win32 instead? Then, as I see it, I will be able to to build both vc++ and mingw versions from the same sources. And, that would be nice. Otherwise, the vc++ solution mess up with my mingw compilation. Henrik.

I'll take a look at it. VC++ projects shouldn't be modifying anything in the src tree, as it's set up in src != obj mode, with obj being win32. Not sure when I can get around to it though... I'm in FreeBSD mode right now :) > From llvmdev-bounces at cs.uiuc.edu Mon Dec 20 16:06:07 2004 > From: "Henrik Bach" <henrik_bach_llvm at hotmail.com> > To: llvmdev

Linking my VC++ application with the standalone Rmath library yields the following; ------ Build started: Project: Complex plugin, Configuration: Debug Win32 ------ Linking... Creating library .\../Debug/complex_plugin.lib and object .\../Debug/complex_plugin.exp libRmath.a(mlutils.o) : warning LNK4217: locally defined symbol __iob imported in function _REprintf libRmath.a(dbeta.o) :

Hi Jeff and Morten, I was just wondering if below wisdom is true, why not prefix every solution and project file with VC71 in front of the file name to signal the case that it is only designed for that specific IDE/tool? This gives us room for comming up with other solution and project files for another MS specific IDE/tool independt of each other. Henrik. ----Original Message Follows----

It's a possibility, though it would be better to create whole separate trees for different versions of VS. It's not just the project and solutions that need to be kept separate; the object files themselves cannot be mixed between different versions of VS. There's no rush though. Trust me, C/C++ programmers will not rush to adopt Whidbey once it's released. You'd be

I agree completely with you, Jeff. However, I think it somehow would be nice, if you guys could tell comming users that the win32 solution is geared toward VC++ 7.1 (and hence use of other tools are at their own risk). And, I think it also would be really cool, if you guys come up with a solution how to handle multiple VC++ x solutions/projects from the same source, possibly ranging from VC

----Original Message Follows---- From: Jeff Cohen <jeffc at jolt-lang.org> Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] VC++: Cannot open include file: 'windows.h': No suchfileor directory Date: Thu, 23 Dec 2004 08:05:39 -0800 >Yes, it

Misha, The "equivalent of dlsym" should be working just fine. Its called ltdl (libtool dynamic library) and is part of lib/System. Its interface is the DynamicLibrary class. The interpreter has already been modified to use this facility. So, if this is broken on windows, I'd like to know how, or why. Jeff, can you provide a test case that we can use to reproduce this problem?

Henrik Bach wrote: > ----Original Message Follows---- > From: Jeff Cohen <jeffc at jolt-lang.org> > Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List > <llvmdev at cs.uiuc.edu> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Subject: Re: [LLVMdev] VC++: Cannot open include file: 'windows.h': > No suchfileor

I'm not sure you understand the problem. Are you saying that a file compiled with mingw can catch an exception thrown by a file compiled with VC++ when the two are linked into a single program? That a program compiled with mingw can be linked against the VC++ runtime and *not* the mingw/gcc runtime? Linking against system DLLs is very different from what I'm talking about. Adam

The interpreter still resolves printf using a hack. It does try to use DynamicLibrary to find it, but fails. DynamicLibrary on Windows only searches the main program executable for symbols, lli.exe in this case. As the C/C++ runtime is in a DLL, it won't find printf in lli.exe. It ought to then search the runtime DLL, the name of which depends on how the binaries are built, but it

I'm afraid that still does not completely answer the question. I'll accept that it will work for C programs, given what you quote. It says nothing about C++ however. That's a different animal entirely. g++ mangles names in a completely different fashion than VC++. Does mingw use VC++ style mangling? g++ processes exceptions in a completely different fashion than VC++. I

On Friday 18 February 2005 11:40 am, Jeff Cohen wrote: > I'm not sure you understand the problem. I wouldn't be surprised :) > Are you saying that a file > compiled with mingw can catch an exception thrown by a file compiled > with VC++ when the two are linked into a single program? That a program > compiled with mingw can be linked against the VC++ runtime and *not*

I have some patches of my own: * An improvement on Morten's fix to Signals.cpp. * Undo the breakage to system.vcproj (Signals.cpp was being built twice as a result). * Fix a class/struct inconsistency. * Remove unneeded #includes from win32 fSystem files. I've also determined why VC++ complains about deprecated destructors when using hash_map. Because it's not ANSI (yet),