[cfe-dev] Three Issues with Building LLVM/CFE Under Cygwin

[Morey]

Hello

	I just successfully built, but not yet tested LLVM/CFE, revision 103915, under Cygwin/XP. This email reports three issues, one, possibly, in need of repair and two, for the record, so that fellow suffers may solve similar problems more quickly. Let me know if you would prefer not to clutter the cfe-dev list with the latter sorts of message.

=====[ISSUE #1]==========================================================================
Possible Problem with AC_LINK_EXPORT_DYNAMIC m4 macro in LLVM/autoconf/m4/link_options.m4
=========================================================================================

	A build was clean, but for one warning of note. It was generated by many, but not all invocations of ld(1). Here is the output from one example:

	llvm[2]: Linking Debug executable tblgen
	/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: warning:
	   --export-dynamic is not supported for PE targets, did you mean --export-all-symbols?
	llvm[2]: ======= Finished Linking Debug Executable tblgen

The Cygwin ld(1) I am using [GNU ld (GNU Binutils) 2.20.51.20100410] does not support --export-dynamic. Instead, it generates the above warning and, barring any other problems, terminates with an exit status of 0. You can see the discussion on how the Cygwin ld(1) should respond to this option at:

	http://sourceware.org/bugzilla/show_bug.cgi?id=6744

It is the AC_LINK_EXPORT_DYNAMIC m4 macro in LLVM/autoconf/m4/link_options.m4 that, when expanded within configure, is supposed to determine if this option is supported.

	I do not know enough to determine how to fix this. Minimally, this macro needs to be examined to determine why it fails for this version of ld(1). This might be all that is required. So far, I have seen no negative consequences of this failure. On the other hand, does the suggested alternative, --export-all-symbols, make sense? Is it necessary?


=====[ISSUE #2]===========================================
Possible Cygwin Resource Leak Required Reboot During Build
==========================================================

	A build terminated and left Cygwin and even XP in a state in which normally functioning programs, both Cygwin and XP programs, failed to run and failed in unusual ways. Here is an excerpt from the make.log:

	make[3]: Entering directory `/d/C/LLVM/lib/Target/SystemZ'
	llvm[3]: Building SystemZ.td register information header with tblgen
	llvm[3]: Building SystemZ.td register names with tblgen
	     10 [unknown (0x1F5D0)] cmp (128344) C:\Cygwin\bin\cmp.exe:
	     *** fatal error - CreateThread failed for sig - 0x0<0x0>, Win32 error 1450
	/bin/sh: /bin/cmp: Resource temporarily unavailable
	/bin/sh: /bin/cp: Resource temporarily unavailable
	make[3]: *** [SystemZGenRegisterNames.inc] Error 126
	make[3]: Leaving directory `/d/C/LLVM/lib/Target/SystemZ'
	make[2]: *** [SystemZ/.makeall] Error 2
	make[2]: Leaving directory `/d/C/LLVM/lib/Target'
	make[1]: *** [Target/.makeall] Error 2
	make[1]: Leaving directory `/d/C/LLVM/lib'
	make: *** [all] Error 1

To fix this problem it was necessary to reboot XP. Rerunning make, produced a successful build. I do not know if it would have done so if I did a clean first. I also do not know if Cygwin was corrupted during the make that failed or during prior build attempts with different tool versions. See Issue #3. Without any reason, I am also suspicious of Cygwin's ability to recover from an XP hibernation, which I do repeatedly without a fresh boot.


=====[ISSUE #3]==================================================
ld(1) Terminates on a (Presumably False) Claim of Heap Exhaustion
=================================================================

	A build terminated during the link of clang, claiming that ld(1) was unable to read symbols from libLLVMAnalysis.a because "cmalloc would have returned NULL". Here is an excerpt from the make.log:

	make[4]: Entering directory `/home/llvm/tools/clang/tools/driver'
	llvm[4]: Linking Debug executable clang
	collect2: ld terminated with signal 1 [Hangup]
	/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: warning:
	   --export-dynamic is not supported for PE targets, did you mean --export-all-symbols?
	/home/llvm/Debug/lib/libLLVMAnalysis.a: could not read symbols:
	   26113 [main] ld 74564 C:\Cygwin\bin\ld.exe:
	   *** fatal error - cmalloc would have returned NULL
	make[4]: *** [/home/llvm/Debug/bin/clang.exe] Error 1
	make[4]: Leaving directory `/home/llvm/tools/clang/tools/driver'
	make[3]: *** [all] Error 1
	make[3]: Leaving directory `/home/llvm/tools/clang/tools'
	make[2]: *** [all] Error 1
	make[2]: Leaving directory `/home/llvm/tools/clang'
	make[1]: *** [clang/.makeall] Error 2
	make[1]: Leaving directory `/home/llvm/tools'
	make: *** [all] Error 1

I tested Cygwin heap allocation. On my system, it supports allocations to nearly 2GB. If you can trust XP's Task Manager, total memory usage was not only not coming anywhere near that, it was dropping when this occurred. 

	I thought this might be related to the warning it generated, but after this issue was resolved, I am still getting these warnings, with no noticeably negative effects so far. See Issue #2. There are build notes for LLVM 1.8 at: 

	http://llvm.org/releases/1.8/docs/CFEBuildInstrs.html

that express concern about using version of binutils newer than 2.15. I am using [GNU ld (GNU Binutils) 2.20.51.20100410], but rather than go backwards, some message boards led me to upgrade gcc from 3.4.3 to [g++ (GCC) 4.3.4 20090804 (release) 1]. For unknown reasons, this is not available in the latest versions of the Cygwin gcc packages, but in an altogether separate set of packages, gcc4-*.

	This did not fix the problem immediately, but since there was no new binutils and the error was generated from ld(1), I suspected that the problem was with a bug in ld(1) that made it unable to properly handle something in the libLLVMAnalysis.a that had been generated from the older compiler. Sure enough, the problem vanished after a clean build.

	Regard,
	Morey.

--
Sometimes, life is what you make of it.
Sometimes, life is what it makes of you.