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.-------------- 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/20041223/6bd7ac58/attachment.sig>
Another and cheaper option could be to buy an used vc++ 7.1 development package. Henrik. ----Original Message Follows---- From: Reid Spencer <reid at x10sys.com> Reply-To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] A first! Date: Thu, 23 Dec 2004 07:33:13 -0800 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. << signature.asc >> _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev _________________________________________________________________ F� alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk/
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. >> >>
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. > >
On Thu, 2004-12-23 at 19:44, 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.Okay, this is *supposed* to be happening automatically. The same issue will happen on unix with shared objects loaded dynamically. So, either DynamicLibrary.cpp is using ltdl wrong or there's a win-specific bug in ltdl.cpp (doubt it, this code's been around for a while).> 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.Yeah, that was the original implementation. I just deleted them all. Sorry for the confusion, I haven't gotten to cleanning up lib/System yet. That will probably happen next week.> I still don't know why these files exist.They shouldn't :)> 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.DynamicLibrary.cpp is "supposed" to be platform agnostic, but we make an exception in its special case. It already has Darwin specific hacks in it for certain symbols. We need to figure out why the DDLs aren't getting searched and (hopefully) fix our use of ltdl in DynamicLibrary so that they are searched. If you want to take a crack at it, feel free, I have some other issues to work on. If you'd rather me do it, let me know so I don't wait for you :) 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/20041223/7f132793/attachment.sig>