[LLVMdev] A first!
jeffc at jolt-lang.org
Fri Dec 24 00:00:02 PST 2004
I have committed a change so that ltdl is no longer used for VC++ builds.
Morten, you can start breathing again :-)
As a side effect, the JIT can now resolve "printf" on Windows (and
presumably anything else to be found in a DLL).
Jeff Cohen wrote:
> 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, when built with Visual Studio, libtool is not used.
> Therefore the LGPL exception does not apply, thereby infecting all of
> LLVM with the LGPL.
> Jeff Cohen wrote:
>> 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.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev