Well... that didn't take long. I'm not sure what you did, Reid, with Path.cpp, but it broke VC++: Bytecode.lib(ReaderWrappers.obj) : error LNK2001: unresolved external symbol "public: __thiscall llvm::sys::Path::Path(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0Path at sys@llvm@@QAE at ABV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@@Z) System.lib(Signals.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall llvm::sys::Path::isDirectory(void)const " (?isDirectory at Path@sys at llvm@@QBE_NXZ) referenced in function "void __cdecl llvm::sys::RemoveDirectoryOnSignal(class llvm::sys::Path const &)" (?RemoveDirectoryOnSignal at sys@llvm@@YAXABVPath at 12@@Z) System.lib(Signals.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall llvm::sys::Path::destroyDirectory(bool)const " (?destroyDirectory at Path@sys at llvm@@QBE_N_N at Z) referenced in function __catch$?Cleanup@@YAXXZ$0 System.lib(Signals.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall llvm::sys::Path::destroyFile(void)const " (?destroyFile at Path@sys at llvm@@QBE_NXZ) referenced in function "void __cdecl Cleanup(void)" (?Cleanup@@YAXXZ)
Hi Jeff, Typically, I've found out that these missing functions are placed beneath lib/System/Unix in some of *.cpp files. These function can be copied to their respectively lib/System/Win32 *.cpp files. Henrik. ----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: [LLVMdev] win32 broken again Date: Fri, 24 Dec 2004 00:08:24 -0800 Well... that didn't take long. I'm not sure what you did, Reid, with Path.cpp, but it broke VC++: Bytecode.lib(ReaderWrappers.obj) : error LNK2001: unresolved external symbol "public: __thiscall llvm::sys::Path::Path(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0Path at sys@llvm@@QAE at ABV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@@Z) System.lib(Signals.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall llvm::sys::Path::isDirectory(void)const " (?isDirectory at Path@sys at llvm@@QBE_NXZ) referenced in function "void __cdecl llvm::sys::RemoveDirectoryOnSignal(class llvm::sys::Path const &)" (?RemoveDirectoryOnSignal at sys@llvm@@YAXABVPath at 12@@Z) System.lib(Signals.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall llvm::sys::Path::destroyDirectory(bool)const " (?destroyDirectory at Path@sys at llvm@@QBE_N_N at Z) referenced in function __catch$?Cleanup@@YAXXZ$0 System.lib(Signals.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall llvm::sys::Path::destroyFile(void)const " (?destroyFile at Path@sys at llvm@@QBE_NXZ) referenced in function "void __cdecl Cleanup(void)" (?Cleanup@@YAXXZ) _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev _________________________________________________________________ Log p� MSN Messenger direkte fra nettet http://webmessenger.msn.com/
Jeff, I'm slowly migrating lib/System away from the use of the "platform" symbolic link and consolidating the implementation into just the Unix and Win32 directories. The operating system differences amongst Unixes are not significant enough to warrant separate directories and files for all of them. Most of those files are empty. Last night I did the merge for Path.cpp. The new #include strategy replaces: #include "platform/Path.cpp" with #if defined(LLVM_ON_UNIX) #include "Unix/Path.cpp" #endif #if defined(LLVM_ON_WIN32) #include "Win32/Path.cpp" #endif One Unix systems the LLVM_ON_UNIX #define will be automatically set by the configure script. For Win32, I suggest that you pass -DLLVM_ON_WIN32=1 to the compiler for all lib/System compilations. The missing symbols you have shown below are a result of LLVM_ON_WIN32 not being set. Reid. On Fri, 2004-12-24 at 00:08, Jeff Cohen wrote:> Well... that didn't take long. I'm not sure what you did, Reid, with > Path.cpp, but it broke VC++: > > Bytecode.lib(ReaderWrappers.obj) : error LNK2001: unresolved external > symbol "public: __thiscall llvm::sys::Path::Path(class > std::basic_string<char,struct std::char_traits<char>,class > std::allocator<char> > const &)" > (??0Path at sys@llvm@@QAE at ABV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@@Z) > System.lib(Signals.obj) : error LNK2019: unresolved external symbol > "public: bool __thiscall llvm::sys::Path::isDirectory(void)const " > (?isDirectory at Path@sys at llvm@@QBE_NXZ) referenced in function "void > __cdecl llvm::sys::RemoveDirectoryOnSignal(class llvm::sys::Path const > &)" (?RemoveDirectoryOnSignal at sys@llvm@@YAXABVPath at 12@@Z) > System.lib(Signals.obj) : error LNK2019: unresolved external symbol > "public: bool __thiscall llvm::sys::Path::destroyDirectory(bool)const " > (?destroyDirectory at Path@sys at llvm@@QBE_N_N at Z) referenced in function > __catch$?Cleanup@@YAXXZ$0 > System.lib(Signals.obj) : error LNK2019: unresolved external symbol > "public: bool __thiscall llvm::sys::Path::destroyFile(void)const " > (?destroyFile at Path@sys at llvm@@QBE_NXZ) referenced in function "void > __cdecl Cleanup(void)" (?Cleanup@@YAXXZ) > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- 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/20041224/6cfd70e7/attachment.sig>
No need to cpoy functions, they are already there. The problem was that Win32/Path.cpp was not being included into Path.cpp because LLVM_ON_WIN32 was not set. Reid. On Fri, 2004-12-24 at 03:03, Henrik Bach wrote:> Hi Jeff, > > Typically, I've found out that these missing functions are placed beneath > lib/System/Unix in some of *.cpp files. These function can be copied to > their respectively lib/System/Win32 *.cpp files. > > > Henrik. > > > ----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: [LLVMdev] win32 broken again > Date: Fri, 24 Dec 2004 00:08:24 -0800 > > Well... that didn't take long. I'm not sure what you did, Reid, with > Path.cpp, but it broke VC++: > > Bytecode.lib(ReaderWrappers.obj) : error LNK2001: unresolved external symbol > "public: __thiscall llvm::sys::Path::Path(class > std::basic_string<char,struct std::char_traits<char>,class > std::allocator<char> > const &)" > (??0Path at sys@llvm@@QAE at ABV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@@Z) > System.lib(Signals.obj) : error LNK2019: unresolved external symbol "public: > bool __thiscall llvm::sys::Path::isDirectory(void)const " > (?isDirectory at Path@sys at llvm@@QBE_NXZ) referenced in function "void __cdecl > llvm::sys::RemoveDirectoryOnSignal(class llvm::sys::Path const &)" > (?RemoveDirectoryOnSignal at sys@llvm@@YAXABVPath at 12@@Z) > System.lib(Signals.obj) : error LNK2019: unresolved external symbol "public: > bool __thiscall llvm::sys::Path::destroyDirectory(bool)const " > (?destroyDirectory at Path@sys at llvm@@QBE_N_N at Z) referenced in function > __catch$?Cleanup@@YAXXZ$0 > System.lib(Signals.obj) : error LNK2019: unresolved external symbol "public: > bool __thiscall llvm::sys::Path::destroyFile(void)const " > (?destroyFile at Path@sys at llvm@@QBE_NXZ) referenced in function "void __cdecl > Cleanup(void)" (?Cleanup@@YAXXZ) > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev > > _________________________________________________________________ > Log på MSN Messenger direkte fra nettet http://webmessenger.msn.com/ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- 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/20041224/773eeb9c/attachment.sig>