Apache OpenOffice (AOO) Bugzilla – Issue 15957
W32-tcsh doesn't build boost, icu
Last modified: 2003-06-26 13:23:20 UTC
in branch cws_srx645_ooo11rc. Hi ause, this one is really strange! boost and icu have the following lines in their makefile.mk: .IF "$(GUI)"=="UNX" .IF "$(COMNAME)"=="sunpro5" .IF "$(BUILD_TOOLS)$/cc"=="$(shell +which cc)" CC:=$(COMPATH)$/bin$/cc CXX:=$(COMPATH)$/bin$/CC .ENDIF # "$(BUILD_TOOLS)$/cc"=="$(shell +which cc)" .ENDIF # "$(COMNAME)"=="sunpro5" And the build dies with: ============= Building project boost ============= /w1/cws_srx645_ooo11rccyg/boost mkout -- version: 1.3 dmake: Error code 1, while making 'Shell escape' echo: No match. ERROR: Error 65280 occurred while making /w1/cws_srx645_ooo11rccyg/boost dmake: Error code 1, while making 'build_all' echo: No match. The problem is the .IF "$(BUILD_TOOLS)$/cc"=="$(shell +which cc)" line, which should never be executed in my windows environment, but it is! (at least evaluated) The underlying problem is the + in $(shell +which cc), if it is there dmake uses the current shell (the cygwin tcsh) and the tcsh uses its own which command, doesn't find cc and gives an error. ?? Without the + it opens a new shell, uses the which from /bin/which (I made some tests ;-) ) and everything is fine. Hä??? I assigned the issue to you in case there was a hidden plan behind the +, if not just reassign the issue back to me and I'll remove the pluses.
retargeted.
it was quite suprising to me too that this line is evaluated on windows at all. the hidden plan behind the "+" is that it forces execution in a shell rather than doing an exec on the binary itself. this was needed as "which" is an internal command in 4nt 4.xx which requires a shell to be found at all. since in case of an error the if statement isn't true anyway, i replaced "+which" with "+-" in at least "icu" and "python". the same workaround should dop in "boost". so please add the "-" rather than removing the "+".
-
Also noted on AIX.
Error message is coming from dmake/function.c The issue is that cc is not a valid command in my system so therefore the command `which cc` returns a CC=1 and it fails the command. The base problem may be a buffer overflow there is 318 characters in my value returned. To fail on systems that works simply use a dummy as a command and see what happens. Work around for me is to code gcc in the short term.
not all "cc" are a link to a "gcc". doing a "which gcc" would render this statement useless...
Committed the '+' -> '+-' change to icu/makefile.mk and boost/makefile.mk. Works for me now. Ken, can you verify for AIX?
Verified on AIX as well. NOTE: Do not confuse a work around by a patch by the way. The issue is in AIX there is NO cc command at all (unless you install xlc)
Closed.
Yes, but the bug is in dmake, the .IF "$(BUILD_TOOLS)$/cc"=="$(shell +which cc)" line should only be evaluated for "$(COMNAME)"=="sunpro5", neither AIX, nor W32-something has a cc. We could raise an issue for that or keep the workaround.