[LLVMdev] A first!

[Jeff Cohen]

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 doesn't.  It should probably enumerate 
and search all DLLs present in the process, including the system DLLs so 
that a program can use the Win32 API, but there's no code to do that in 
ltdl.c.

This code needs to be added, but I'm not sure where.  
win32/DynamicLibrary.cpp is not the place, as it is never compiled, just 
as none of */DynamicLibrary.cpp are compiled.  I still don't know why 
these files exist.  But ltdl.c doesn't feel right either, as it's GNU 
software.  The main DynamicLibrary.cpp is supposed to be platform 
independent, so that doesn't seem appropriate either, nonetheless seems 
to be the best bet.

Reid Spencer wrote:

>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?  Looks like I'm finally going to force myself into a windows
>build (i.e. cough up the money for VC++ 7.1).
>
>Reid.
>
>On Wed, 2004-12-22 at 23:12, Misha Brukman wrote:
>  
>
>>On Wed, Dec 22, 2004 at 11:01:37PM -0800, Jeff Cohen wrote:
>>    
>>
>>>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.
>>>      
>>>
>>The interpreter has some hacks for dealing with common functions like
>>"printf" :)  We need to get the Win32 equivalent of dlsym() going for
>>the JIT to work on Windows.
>>    
>>