similar to: [LLVMdev] VC++ patches

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

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, I'm just reviewing some old mail on my "to do" list. I was wondering if you managed to get ltdl.c to compile cleanly with VC++ or if you want me to look at these warnings. Reid. On Sun, 2004-12-05 at 09:08, Jeff Cohen wrote: > Well, then why does win32/DynamicLibrary.cpp exist, not to mention it's > *nix relatives? You have even been updating them, even though

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?

Well, then why does win32/DynamicLibrary.cpp exist, not to mention it's *nix relatives? You have even been updating them, even though they cannot be compiled as they aren't included by System/DynamicLibrary.cpp. Anyway, with Morten's patches I can almost build successfully. Minor patch attached to fix the residual problems. I don't know why he didn't hit these problems.

ltdl.h fully supports windows platforms (lots of them). That isn't the issue. The issue is setting up the #defines to reflect the windows system. e.g. HAVE_DLOPEN needs to be false Reid. On Fri, 2004-12-03 at 20:35, Chris Lattner wrote: > On Fri, 3 Dec 2004, Jeff Cohen wrote: > > > It will have to be Morten. I can't get ltdl.c to compile. But wasn't > > the

It will have to be Morten. I can't get ltdl.c to compile. But wasn't the whole point of doing platform-specific DynamicLibrary.cpps to get rid of ltdl.c? On Fri, 3 Dec 2004 10:40:53 -0600 (CST) Chris Lattner <sabre at nondot.org> wrote: > On Fri, 3 Dec 2004, Reid Spencer wrote: > > > Could someone please apply this patch to the Win32 support so that > > Morten

I've come across a couple errors when building LLVM 2.1 in VC++ 2005. 1) CodeGen/RegisterCoalescer.cpp is not included in the project 2) System/Win32/DynamicLibrary.inc - ELM_Callback is declared with a PSTR ModuleName argument. This causes a compile error - the callback typedef specifies PCSTR. Also, I'd like to suggest adding the following to config.h, to eliminate the spurious

On Fri, 3 Dec 2004, Jeff Cohen wrote: > It will have to be Morten. I can't get ltdl.c to compile. But wasn't > the whole point of doing platform-specific DynamicLibrary.cpps to get > rid of ltdl.c? ltdl.c is part of libtool that is supposed to BE the cross-platform dynamic linker interface. However, for platforms it doesn't really support, using custom code makes perfect

The DynamicLibrary.cpp code is written and I believe it to be complete, but it hasn't been tested much (at all). llvm-ld uses it to load its plug-in optimization module. The implementation will use ltdl library if its available, otherwise it tries to use dlopen/dlsym if they are available, otherwise you get a compile time warning and (void*)0 if you try to look up a symbol. I'm not sure

On Sun, 28 Nov 2004, Reid Spencer wrote: > FYI .. if you want to see how this works, check out > lib/System/DynamicLibrary.cpp and platform versions of it. Is it an option to use this interface now? How does libtool implement dlsym on darwin if not through the obvious interface? Can we just use whatever it uses? -Chris > On Sun, 2004-11-28 at 10:03, Reid Spencer wrote: > >

FYI .. if you want to see how this works, check out lib/System/DynamicLibrary.cpp and platform versions of it. Reid. On Sun, 2004-11-28 at 10:03, Reid Spencer wrote: > Well, one of these days we'll be using libltdl (libtool's dynamic > library support) to make the interface to dynamic libraries consistent, > somewhat portable, and to get rid of system specific differences like

Hi Chris, > Once you have that, you are hitting another problem. Specifically, > the JIT::getPointerToNamedFunction method in > lib/ExecutionEngine/JIT/Intercept.cpp just does a dlsym on missing > symbols. If dlsym returns null, you get the error message. > > The problem here is that .objc_class_name_* are special symbols that > are used by the objc linker support and they

Hi Ralph, On Fri, 2007-07-20 at 10:38 +0100, Ralph Corderoy wrote: > Hi Chris, > I could be missing something, but shouldn't the use of dlsym() be > > char *err; > void *p; > > if ((err = dlerror())) { > error("earlier undetected dlerror: %s\n", err); > } > p = dlsym(handle, sym); > if ((err = dlerror())) { >

Morten, I've applied these patches. Thanks for the updates! Reid. On Mon, 2004-11-15 at 01:26, Morten Ofstad wrote: > Hi, > > when I updated the sources today there were several small problems that > stopped the windows version from compiling, here are the patches > > m. > > > ______________________________________________________________________ > Index:

Hi Dmitri, For what version of VS did you update the project files? Ted On May 17, 2008, at 3:00 PM, Dmitri Makarov wrote: > attached is the diff of vcprojs that need to be changed to fix the VS > build as of revision: 51224. > > I don't know if this catches all the missing bits, but this does build > all the way through. > > > Index: win32/Analysis/Analysis.vcproj

On Sun, Sep 21, 2008 at 9:27 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > This is an updated version of the patch that fixes some issues on VC++ > builds. Hi, FYI I just tried this (from r56534). I get an "error" (below) from cmake (2.6.1) about Intrinsics.gen but it seems to write out sln/vcproj anyway. Project.sln opens and builds OK (modulo a build error in llvmc2

On Fri, 20 Jul 2007, Ralph Corderoy wrote: > I could be missing something, but shouldn't the use of dlsym() be > The authors of dlsym() realised the return value was overloaded AFAICS. Yep, patches welcome :) -Chris -- http://nondot.org/sabre/ http://llvm.org/

I verified the patch and it compiles all the targets, both in Debug and Release modes. If there is no someone else to keep the MSVC projects files updated, I will try from time to time to update them and to add the new targets. Maybe a note must be put in "docs/GettingStartedVS.html" at the Requirements section that llvm needs now MSVC (Express) 2008 to compile. Razvan -----

Turns out it wasn't using the JIT. It was running the interpreter. The X86 stuff wasn't being linked in. Alas, once I "fixed" that, it stopped working. The JIT couldn't resolve the symbol "printf" and failed. But the interpreter could resolve it. Misha Brukman wrote: >On Wed, Dec 22, 2004 at 08:48:19PM -0800, Jeff Cohen wrote: > > >>I