[Cygwin] 'make tools-only' configuration error

Project Infrastructure LLVM Dev List Archives
1

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

2

Aaron,

Comments inline ...

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 :slight_smile: procedure at
work here.

Reid

3

Reid,

I did look on eBay for you for replacement 2.5" harddisks but they
were expensive and in short supply :frowning:

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 :slight_smile: 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?

4

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 :slight_smile:

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 :frowning:

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

5

>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 :slight_smile:

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

6

Reid,

Just done a proper check and there are no cygwin DLL references in the registry.

Aaron

7

Reid,

Getting the same error again :frowning:

/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

8

‘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

9

X86 Linux compiles/links/runs just fine.

X86JITInfo is an object file that should be part of LLVMX86.o. To
validate that it is there do this:

cd <builddir>/lib/Target/X86/Debug
ls -l X86JITInfo.*

The two files (*.o and *.d) should have non zero size. Then do this:

nm X86JITInfo.o

and make a note of a few external symbols (with T attribute). Then
run nm on LLVMX86.o in the <builddir>/Debug/lib directory and see if you
can see that symbol (might want to pipe through grep for that). If the
symbol shows up then X86JITInfo.o was linked into LLVMX86.o

The LLVM Makefile system is pretty simple (to use). Its fully documented
here: http://llvm.cs.uiuc.edu/docs/MakefileGuide.html

Reid