I did not report this first error earlier as I thought it trivial. Basically it looks like something odd is happening with the configuration and 'include/llvm/config/config.h' Getting this error on building the tools on a fresh Cygwin install and update :- $ make tools-only make[1]: Entering directory `/usr/build/llvm/lib/System' llvm[1]: Compiling Path.cpp for Debug build In file included from /usr/src/llvm/lib/System/Path.cpp:104: /usr/src/llvm/lib/System/Unix/Path.inc: In static member function `static llvm:: sys::Path llvm::sys::Path::GetTemporaryDirectory()': /usr/src/llvm/lib/System/Unix/Path.inc:93: error: `mkdtemp' undeclared (first us e this function) /usr/src/llvm/lib/System/Unix/Path.inc:93: error: (Each undeclared identifier is reported only once for each function it appears in.) make[1]: *** [/usr/build/llvm/lib/System/Debug/Path.o] Error 1 make[1]: Leaving directory `/usr/build/llvm/lib/System' make: *** [all] Error 1 On commenting out the "#define HAVE_MKDTEMP 1" this error is bypassed, but what is leading to this error ? This happens on a new fresh install of Cygwin, GCC 3.4.3, binutils 2.15, and fresh llvm from CVS ! And it is repeatable. Either I am doing something basic wrong or there is an issue here, what I do not understand is why I did not run into it when we (Reid Spencer and myself) did the previous Cygwin debugging session. It looks like the configure script is failing drastically, I am confused. Still getting the previous error :- llvm[2]: Linking Debug executable llc /usr/build/llvm/Debug/lib/LLVMX86.o(.text+0x30506): In function `_GLOBAL__D__ZN7 6_GLOBAL__N__usr_src_llvm_lib_Target_X86_X86ISelPattern.cpp_9D2164D3_CFE6F8F217X 86TargetLowering14LowerArgumentsERN4llvm8FunctionERNS1_12SelectionDAGE': /usr/src/llvm/lib/Target/X86/X86ISelPattern.cpp:73: undefined reference to `X86C ompilationCallback2' /usr/build/llvm/Debug/lib/LLVMX86.o(.text+0x305f2):/usr/src/llvm/lib/Target/X86/ X86ISelPattern.cpp:73: undefined reference to `_X86CompilationCallback' /usr/build/llvm/Debug/lib/LLVMX86.o(.text+0x30601):/usr/src/llvm/lib/Target/X86/ X86ISelPattern.cpp:73: undefined reference to `_X86CompilationCallback' collect2: ld returned 1 exit status make[2]: *** [/usr/build/llvm/Debug/bin/llc.exe] Error 1 make[2]: Leaving directory `/usr/build/llvm/tools/llc' make[1]: *** [llc/.makeall] Error 2 make[1]: Leaving directory `/usr/build/llvm/tools' make: *** [all] Error 1 Doing 'make tools-only ENABLE_OPTIMIZED=1 gives a simular but different error :- llvm[2]: Linking Release executable llc (without symbols) collect2: ld terminated with signal 11 [Segmentation fault], core dumped /usr/build/llvm-2/Release/lib/LLVMX86.o(.text+0x51d76):X86InstrInfo.cpp: undefined reference to `X86CompilationCallback2' /usr/build/llvm-2/Release/lib/LLVMX86.o(.text+0x51e0a):X86JITInfo.cpp: undefined reference to `_X86CompilationCallback' /usr/build/llvm-2/Release/lib/LLVMX86.o(.text+0x51e1f):X86JITInfo.cpp: undefined reference to `_X86CompilationCallback' /usr/binutils-2.15/bin/ld: BFD 2.15 assertion fail ../../../src/binutils-2.15/bfd/cofflink.c:1930 make[2]: *** [/usr/build/llvm-2/Release/bin/llc.exe] Error 1 make[2]: Leaving directory `/usr/build/llvm-2/tools/llc' make[1]: *** [llc/.makeall] Error 2 make[1]: Leaving directory `/usr/build/llvm-2/tools' make: *** [all] Error 1 I have gone back to the older Cygwin environment that worked before but am now getting the same results as with the newer Cygwin installation. Why it worked before but not now I do not know. The first error in this mail does not occur with the older Cygwin installation. The only thing I can think is it is my instillation proceedure but I cannot find anything wrong with it. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050531/f143c4c8/attachment.html>
Reid Spencer
2005-May-31 22:00 UTC
[LLVMdev] [Cygwin] 'make tools-only' configuration error
Aaron, Comments inline ... On Tue, 2005-05-31 at 21:15 +0100, Aaron Gray wrote:> I did not report this first error earlier as I thought it trivial. > > Basically it looks like something odd is happening with the > configuration and 'include/llvm/config/config.h' > > Getting this error on building the tools on a fresh Cygwin install and > update :- > > $ make tools-only > make[1]: Entering directory `/usr/build/llvm/lib/System' > llvm[1]: Compiling Path.cpp for Debug build > In file included from /usr/src/llvm/lib/System/Path.cpp:104: > /usr/src/llvm/lib/System/Unix/Path.inc: In static member function > `static llvm:: > sys::Path llvm::sys::Path::GetTemporaryDirectory()': > /usr/src/llvm/lib/System/Unix/Path.inc:93: error: `mkdtemp' undeclared > (first us > e this function)This is definitely a configure problem. If mkdtemp function was found (and it was because HAVE_MKDTEMP was set to 1) then it should find mkdtemp in the headers.> /usr/src/llvm/lib/System/Unix/Path.inc:93: error: (Each undeclared > identifier is > reported only once for each function it appears in.) > make[1]: *** [/usr/build/llvm/lib/System/Debug/Path.o] Error 1 > make[1]: Leaving directory `/usr/build/llvm/lib/System' > make: *** [all] Error 1 > > On commenting out the "#define HAVE_MKDTEMP 1" this error is bypassed, > but what is leading to this error ?I don't know, possibly they moved the header file in which mkdtemp is defined in your new version of Cygwin.> > This happens on a new fresh install of Cygwin, GCC 3.4.3, binutils > 2.15, and fresh llvm from CVS !That all sounds right to me. Must be the "new" version of Cygwin. Go to /usr/include and do this: find . -name '*.h' -exec grep mkdtemp {} \; -print and let me know if you get any output. The output will tell you which header file mkdtemp is defined in. Make sure that is the header that is included in lib/System/Unix/Path.inc (it might be a few #includes removed).> > And it is repeatable. Either I am doing something basic wrong or there > is an issue here, what I do not understand is why I did not run into > it when we (Reid Spencer and myself) did the previous Cygwin debugging > session. > > It looks like the configure script is failing drastically, I am > confused.That would be bad for this entire process. How is it failing? Any output from it?> > Still getting the previous error :- > > llvm[2]: Linking Debug executable llc > /usr/build/llvm/Debug/lib/LLVMX86.o(.text+0x30506): In function > `_GLOBAL__D__ZN7 > 6_GLOBAL__N__usr_src_llvm_lib_Target_X86_X86ISelPattern.cpp_9D2164D3_CFE6F8F217X > 86TargetLowering14LowerArgumentsERN4llvm8FunctionERNS1_12SelectionDAGE': > /usr/src/llvm/lib/Target/X86/X86ISelPattern.cpp:73: undefined > reference to `X86C > ompilationCallback2' > /usr/build/llvm/Debug/lib/LLVMX86.o(.text > +0x305f2):/usr/src/llvm/lib/Target/X86/ > X86ISelPattern.cpp:73: undefined reference to > `_X86CompilationCallback' > /usr/build/llvm/Debug/lib/LLVMX86.o(.text > +0x30601):/usr/src/llvm/lib/Target/X86/ > X86ISelPattern.cpp:73: undefined reference to > `_X86CompilationCallback' > collect2: ld returned 1 exit status > make[2]: *** [/usr/build/llvm/Debug/bin/llc.exe] Error 1 > make[2]: Leaving directory `/usr/build/llvm/tools/llc' > make[1]: *** [llc/.makeall] Error 2 > make[1]: Leaving directory `/usr/build/llvm/tools' > make: *** [all] Error 1 > > Doing 'make tools-only ENABLE_OPTIMIZED=1 gives a simular but > different error :- > > llvm[2]: Linking Release executable llc (without symbols) > collect2: ld terminated with signal 11 [Segmentation fault], core > dumped > /usr/build/llvm-2/Release/lib/LLVMX86.o(.text > +0x51d76):X86InstrInfo.cpp: undefined reference to > `X86CompilationCallback2' > /usr/build/llvm-2/Release/lib/LLVMX86.o(.text+0x51e0a):X86JITInfo.cpp: > undefined reference to `_X86CompilationCallback' > /usr/build/llvm-2/Release/lib/LLVMX86.o(.text+0x51e1f):X86JITInfo.cpp: > undefined reference to `_X86CompilationCallback' > /usr/binutils-2.15/bin/ld: BFD 2.15 assertion > fail ../../../src/binutils-2.15/bfd/cofflink.c:1930 > make[2]: *** [/usr/build/llvm-2/Release/bin/llc.exe] Error 1 > make[2]: Leaving directory `/usr/build/llvm-2/tools/llc' > make[1]: *** [llc/.makeall] Error 2 > make[1]: Leaving directory `/usr/build/llvm-2/tools' > make: *** [all] Error 1 >That's all just bizarre but its possible that it is related to a more fundamental error, especially a configure script problem.> I have gone back to the older Cygwin environment that worked before > but am now getting the same results as with the newer Cygwin > installation. Why it worked before but not now I do not know.Hrm. That's not good. Can you build with "TOOL_VERBOSE=1" and capture the output and send it to me. Something like: make TOOL_VERBOSE=1 2>&1 >make.out Send that to me (not the list) and I'll take a look. Please also do this: make reconfigure and send me the "configure.out" file that gets generated as well as "config.log".> > The first error in this mail does not occur with the older Cygwin > installation.Yeah, as I suspected, its probably related to the new version of Cygwin.> > The only thing I can think is it is my instillation proceedure but I > cannot find anything wrong with it.There's something fishier than just your inst >>>A<<< ll :) procedure at work here. 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/20050531/6afbcadd/attachment.sig>
Reid Spencer
2005-Jun-01 01:44 UTC
[LLVMdev] [Cygwin] 'make tools-only' configuration error
On Tue, 2005-05-31 at 23:56 +0100, Aaron Gray wrote:> Reid, > > I did look on eBay for you for replacement 2.5" harddisks but they > were expensive and in short supply :(LOL.> > >That all sounds right to me. Must be the "new" version of Cygwin. Go > >to /usr/include and do this: > > > >find . -name '*.h' -exec grep mkdtemp {} \; -print > > Its giving me zilch.Okay, so Cygwin doesn't have a mkdtemp. Perhaps it never did. So why is configure "finding" one?> > >and let me know if you get any output. The output will tell you which > >header file mkdtemp is defined in. Make sure that is the header that is > >included in lib/System/Unix/Path.inc (it might be a few #includes > >removed). > > I tried on the older version of Cygwin and it looks like it was never there.Maybe it has never had mkdtemp. Either way, configure shouldn't find it if it doesn't have it.> > >That's all just bizarre but its possible that it is related to a more > >fundamental error, especially a configure script problem. > > Yes that is the conclusion I came to. > > >> I have gone back to the older Cygwin environment that worked before > >> but am now getting the same results as with the newer Cygwin > >> installation. Why it worked before but not now I do not know. > > > >Hrm. That's not good. > > > >Can you build with "TOOL_VERBOSE=1" and capture the output and send it > >to me. Something like: > > > >make TOOL_VERBOSE=1 2>&1 >make.out > > Okay, that was quicker than I thought.This didn't really show much. You built the X86 target and linked llc. All worked fine.> > >Send that to me (not the list) and I'll take a look. Please also do > >this: > > > >make reconfigure > > > >and send me the "configure.out" file that gets generated as well as > >"config.log". >Okay, the configure script did *not* find mkdtemp therefore HAVE_MKDTEMP should not have been set. That is confirmed by your config.log. I think you might just be dealing with a stale or corrupt build directory? Have you tried starting from scratch (do "make spotless")?> Okay. > > These are from the older Cygwin installation that used to work. I can do the > same from the newer installation too if need be. > > >> The first error in this mail does not occur with the older Cygwin > >> installation. > > > >Yeah, as I suspected, its probably related to the new version of Cygwin. > > It does look like it is reporting a nonexistant function and has broken > LLVM.Just make sure that HAVE_MKDTEMP is *not* defined in your config.h (after running configure) and you should be good, at least on this point. The lib/System/Unix/Path.inc file will handle the situation even if it has to resort to creating a temporary directory manually without using a library function.> > >> The only thing I can think is it is my instillation proceedure but I > >> cannot find anything wrong with it. > > > >There's something fishier than just your inst >>>A<<< ll :) procedure at > >work here. > > Yes, there does seem to be something odd. Quite unsettling after the amount > of work we have put in to it. Thought we had it sussed. I do find Cygwin a > bit brittle at times.Yup. I don't really see anything wrong with your ocnfiguration files. Can you try just building it again from scratch without the HAVE_MKDTEMP #define set and see what you get?> > Aaron >-------------- 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/20050531/c7b2bf01/attachment.sig>
>Just an aside .. are you putting these Cygwin installs on the same box? >Can you do that? I didn't think it was allowed.Ahh, we have ways of renaming directories :) I do have a second machine but I have to juggle the disk partitions to make enough room so I have not been able to use that. Besides for some reason it did not want to build binutils-2.15 :( Okay it looks like the newer "uptodate" Cygwin has a problem with mkdtemp(). It looks like mkdtemp() exists in a library and is linkable, but there is no function prototype for it in the headers. The configuration system compiles a function :- /* Override any gcc2 internal prototype to avoid an error. */ | #ifdef __cplusplus | extern "C" | { | #endif | /* We use char because int might match the return type of a gcc2 | builtin and then its argument prototype would still apply. */ | char mkdtemp (); | /* The GNU C library defines this for functions which it implements | to always fail with ENOSYS. Some functions are actually named | something starting with __ and the normal name is an alias. */ | #if defined (__stub_mkdtemp) || defined (__stub___mkdtemp) | choke me | #else | char (*f) () = mkdtemp; | #endif | #ifdef __cplusplus | } | #endif | | int | main () | { | return f != mkdtemp; | ; | return 0; | } It defines 'char mkdtemp()' and links it as it is defined in a library but not in a header ! Well, thats thats the easy but annoying one. Have to either hand edit the config.h or do a patch on it for now until the Cygwin crew get it together to correct this half implemented function. Do you think it is worth reporting it to the Cygwin mailing list ? As for LLVM I will have to rerun the tests as I have confused myself to what is going on now. It is strange that the old configuration did not work again, very strange. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050601/563dde4e/attachment.html>
>> >Just an aside .. are you putting these Cygwin installs on the same >> box? >> >Can you do that? I didn't think it was allowed. >> >> Ahh, we have ways of renaming directories :) > >Yes, but do you have ways of renaming the registry which contains >references to the DLL's installed by Cygwin. Personally, I think you're >playing with fire.I have just checked again and AFAICT there is nothing in the registry that would cause any problems. Aaron
Reid, Just done a proper check and there are no cygwin DLL references in the registry. Aaron
Reid, Getting the same error again :-( /usr/gcc/gcc-3.4.3/libexec/gcc/i686-pc-cygwin/3.4.3/collect2.exe -Bdynamic --dl l-search-prefix=cyg -o /usr/build/llvm-2/Debug/bin/llc.exe /lib/crt0.o -L/usr/bu ild/llvm-2/Debug/lib -L/usr/build/llvm-2/Debug/bin -L/usr/gcc/gcc-3.4.3/lib/gcc/ i686-pc-cygwin/3.4.3 -L/usr/gcc/gcc-3.4.3/lib/gcc/i686-pc-cygwin/3.4.3/../../.. /usr/build/llvm-2/tools/llc/Debug/llc.o /usr/build/llvm-2/Debug/lib/LLVMCBackend .o /usr/build/llvm-2/Debug/lib/LLVMSparcV9ModuloSched.o /usr/build/llvm-2/Debug/ lib/LLVMSparcV8.o /usr/build/llvm-2/Debug/lib/LLVMSparcV9.o /usr/build/llvm-2/De bug/lib/LLVMSparcV9RegAlloc.o /usr/build/llvm-2/Debug/lib/LLVMSparcV9InstrSched. o /usr/build/llvm-2/Debug/lib/LLVMSparcV9LiveVar.o /usr/build/llvm-2/Debug/lib/L LVMX86.o /usr/build/llvm-2/Debug/lib/LLVMPowerPC.o /usr/build/llvm-2/Debug/lib/L LVMAlpha.o /usr/build/llvm-2/Debug/lib/LLVMIA64.o /usr/build/llvm-2/Debug/lib/LL VMSelectionDAG.o /usr/build/llvm-2/Debug/lib/LLVMCodeGen.o /usr/build/llvm-2/Deb ug/lib/LLVMScalarOpts.o /usr/build/llvm-2/Debug/lib/LLVMBCReader.o /usr/build/ll vm-2/Debug/lib/LLVMBCWriter.o /usr/build/llvm-2/Debug/lib/LLVMCore.o /usr/build/ llvm-2/Debug/lib/LLVMbzip2.o --export-dynamic -lLLVMTarget -lLLVMipa -lLLVMTrans forms -lLLVMAnalysis -lLLVMTransformUtils -lLLVMSupport -lLLVMSystem -lstdc++ -l gcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc /usr/build/llvm-2/Debug/lib/LLVMX86.o(.text+0x30406): In function `_GLOBAL__D__Z N76_GLOBAL__N__usr_src_llvm_lib_Target_X86_X86ISelPattern.cpp_9D2164D3_A63131251 7X86TargetLowering14LowerArgumentsERN4llvm8FunctionERNS1_12SelectionDAGE': /usr/src/llvm/lib/Target/X86/X86ISelPattern.cpp:73: undefined reference to `X86C ompilationCallback2' /usr/build/llvm-2/Debug/lib/LLVMX86.o(.text+0x304f2):/usr/src/llvm/lib/Target/X8 6/X86ISelPattern.cpp:73: undefined reference to `_X86CompilationCallback' /usr/build/llvm-2/Debug/lib/LLVMX86.o(.text+0x30501):/usr/src/llvm/lib/Target/X8 6/X86ISelPattern.cpp:73: undefined reference to `_X86CompilationCallback' collect2: ld returned 1 exit status make[2]: *** [/usr/build/llvm-2/Debug/bin/llc.exe] Error 1 make[2]: Leaving directory `/usr/build/llvm-2/tools/llc' make[1]: *** [llc/.makeall] Error 2 make[1]: Leaving directory `/usr/build/llvm-2/tools' make: *** [all] Error 1 This error seems to be common to both the old Cygwin configuration which we originally had working and the newer configuration as well. Any clues ? Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050601/55f38d4c/attachment.html>
'collect2.exe' is an internal version of 'ld' called by GCC The GCC command line is :- g++ -I/usr/build/llvm-2/tools/llc -I/usr/src/llvm/tools/llc -I/usr/build/llvm-2/ include -I/usr/src/llvm/include -I/usr/build/llvm-2/include -I/usr/src/llvm/incl ude -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -Wall -W -Wwrite-strings -Wno-unused -g -D_DEBUG -v -o /usr/build/llvm-2/Debug/bin/llc.exe /usr/build/llvm-2/tools/llc/D ebug/llc.o /usr/build/llvm-2/Debug/lib/LLVMCBackend.o /usr/build/llvm-2/Debug/li b/LLVMSparcV9ModuloSched.o /usr/build/llvm-2/Debug/lib/LLVMSparcV8.o /usr/build/ llvm-2/Debug/lib/LLVMSparcV9.o /usr/build/llvm-2/Debug/lib/LLVMSparcV9RegAlloc.o /usr/build/llvm-2/Debug/lib/LLVMSparcV9InstrSched.o /usr/build/llvm-2/Debug/lib /LLVMSparcV9LiveVar.o /usr/build/llvm-2/Debug/lib/LLVMX86.o /usr/build/llvm-2/De bug/lib/LLVMPowerPC.o /usr/build/llvm-2/Debug/lib/LLVMAlpha.o /usr/build/llvm-2/ Debug/lib/LLVMIA64.o /usr/build/llvm-2/Debug/lib/LLVMSelectionDAG.o /usr/build/l lvm-2/Debug/lib/LLVMCodeGen.o /usr/build/llvm-2/Debug/lib/LLVMScalarOpts.o /usr/ build/llvm-2/Debug/lib/LLVMBCReader.o /usr/build/llvm-2/Debug/lib/LLVMBCWriter.o /usr/build/llvm-2/Debug/lib/LLVMCore.o /usr/build/llvm-2/Debug/lib/LLVMbzip2.o -Wl,--export-dynamic -L/usr/build/llvm-2/Debug/lib -lLLVMTarget -lLLVMipa -lLLV MTransforms -lLLVMAnalysis -lLLVMTransformUtils -lLLVMSupport -lLLVMSystem -L/us r/build/llvm-2/Debug/bin It looks like there is a reference to X86JITInfo but no object file for this is being linked into 'llc'. Does the X86 Linux version compile correctly ? I am a bit dumb founded by LLVM's make system still otherwise I would probably have fixed this by now. Aaron ----- Original Message ----- From: Aaron Gray To: LLVM Developers Mailing List ; Reid Spencer Sent: Wednesday, June 01, 2005 6:40 PM Subject: Re: [LLVMdev] [Cygwin] 'make tools-only' configuration error Reid, Getting the same error again :-( /usr/gcc/gcc-3.4.3/libexec/gcc/i686-pc-cygwin/3.4.3/collect2.exe -Bdynamic --dl l-search-prefix=cyg -o /usr/build/llvm-2/Debug/bin/llc.exe /lib/crt0.o -L/usr/bu ild/llvm-2/Debug/lib -L/usr/build/llvm-2/Debug/bin -L/usr/gcc/gcc-3.4.3/lib/gcc/ i686-pc-cygwin/3.4.3 -L/usr/gcc/gcc-3.4.3/lib/gcc/i686-pc-cygwin/3.4.3/../../.. /usr/build/llvm-2/tools/llc/Debug/llc.o /usr/build/llvm-2/Debug/lib/LLVMCBackend .o /usr/build/llvm-2/Debug/lib/LLVMSparcV9ModuloSched.o /usr/build/llvm-2/Debug/ lib/LLVMSparcV8.o /usr/build/llvm-2/Debug/lib/LLVMSparcV9.o /usr/build/llvm-2/De bug/lib/LLVMSparcV9RegAlloc.o /usr/build/llvm-2/Debug/lib/LLVMSparcV9InstrSched. o /usr/build/llvm-2/Debug/lib/LLVMSparcV9LiveVar.o /usr/build/llvm-2/Debug/lib/L LVMX86.o /usr/build/llvm-2/Debug/lib/LLVMPowerPC.o /usr/build/llvm-2/Debug/lib/L LVMAlpha.o /usr/build/llvm-2/Debug/lib/LLVMIA64.o /usr/build/llvm-2/Debug/lib/LL VMSelectionDAG.o /usr/build/llvm-2/Debug/lib/LLVMCodeGen.o /usr/build/llvm-2/Deb ug/lib/LLVMScalarOpts.o /usr/build/llvm-2/Debug/lib/LLVMBCReader.o /usr/build/ll vm-2/Debug/lib/LLVMBCWriter.o /usr/build/llvm-2/Debug/lib/LLVMCore.o /usr/build/ llvm-2/Debug/lib/LLVMbzip2.o --export-dynamic -lLLVMTarget -lLLVMipa -lLLVMTrans forms -lLLVMAnalysis -lLLVMTransformUtils -lLLVMSupport -lLLVMSystem -lstdc++ -l gcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc /usr/build/llvm-2/Debug/lib/LLVMX86.o(.text+0x30406): In function `_GLOBAL__D__Z N76_GLOBAL__N__usr_src_llvm_lib_Target_X86_X86ISelPattern.cpp_9D2164D3_A63131251 7X86TargetLowering14LowerArgumentsERN4llvm8FunctionERNS1_12SelectionDAGE': /usr/src/llvm/lib/Target/X86/X86ISelPattern.cpp:73: undefined reference to `X86C ompilationCallback2' /usr/build/llvm-2/Debug/lib/LLVMX86.o(.text+0x304f2):/usr/src/llvm/lib/Target/X8 6/X86ISelPattern.cpp:73: undefined reference to `_X86CompilationCallback' /usr/build/llvm-2/Debug/lib/LLVMX86.o(.text+0x30501):/usr/src/llvm/lib/Target/X8 6/X86ISelPattern.cpp:73: undefined reference to `_X86CompilationCallback' collect2: ld returned 1 exit status make[2]: *** [/usr/build/llvm-2/Debug/bin/llc.exe] Error 1 make[2]: Leaving directory `/usr/build/llvm-2/tools/llc' make[1]: *** [llc/.makeall] Error 2 make[1]: Leaving directory `/usr/build/llvm-2/tools' make: *** [all] Error 1 This error seems to be common to both the old Cygwin configuration which we originally had working and the newer configuration as well. Any clues ? Aaron ------------------------------------------------------------------------------ _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050601/7eb08f47/attachment.html>