OpenTTD

Tasklist

FS#3076 - configure makes improper assumptions on /bin/sh

Attached to Project: OpenTTD
Opened by Nixx (Nixx) - Saturday, 01 August 2009, 13:16 GMT
Last edited by Remko Bijker (Rubidium) - Saturday, 01 August 2009, 16:57 GMT
Type Bug
Category Build system
Status Closed
Assigned To No-one
Operating System UNIX
Severity Medium
Priority Normal
Reported Version 0.7.2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

The configure script coming with openttd-0.7.2 starts with "#!/bin/sh", but is assuming that shell supports bash-syntax (first time in multi line string starting in :88). On linux that assumptions seems to hold more often than not, on unix (open solaris in this case) however, that makes configure fail:

--
configure[88]: : cannot execute [Is a directory]
gawk: cmd. line:5: gsub("
gawk: cmd. line:5: ^ unterminated string
configure[88]: , , configure);
gsub(^#if: not found [No such file or directory]
configure[135]: : cannot execute [Is a directory]
gawk: { ORS = "
gawk: ^ unterminated string
configure[135]: } /\.c$/ { gsub(.c, .o, configure); print configure; }': not found [No such file or directory]
configure[136]: : cannot execute [Is a directory]
gawk: { ORS = "
gawk: ^ unterminated string
configure[136]: } /\.cpp$/ { gsub(.cpp, .o, configure); print configure; }': not found [No such file or directory]
configure[137]: : cannot execute [Is a directory]
gawk: { ORS = "
gawk: ^ unterminated string
configure[137]: } /\.mm$/ { gsub(.mm, .o, configure); print configure; }': not found [No such file or directory]
configure[138]: : cannot execute [Is a directory]
gawk: { ORS = "
gawk: ^ unterminated string
configure[138]: } /\.rc$/ { gsub(.rc, .o, configure); print configure; }': not found [No such file or directory]
configure[139]: : cannot execute [Is a directory]
gawk: { ORS = "
gawk: ^ unterminated string
configure[139]: } { print configure; }': not found [No such file or directory]
--

At least, it determines the right awk (gawk in open solaris!) correctly, so when replacing the first line of configure to use /bin/bash, configure is fine.

Please make sure the syntax fits with the specified shell - one way or another.
This task depends upon

Closed by  Remko Bijker (Rubidium)
Saturday, 01 August 2009, 16:57 GMT
Reason for closing:  Fixed
Additional comments about closing:  In r17026
Comment by Remko Bijker (Rubidium) - Saturday, 01 August 2009, 13:45 GMT
The script is not a bash script per-se; it also runs with e.g. dash. I've got NO idea what kind of flavour of sh you are using.

My interpretation of the specifications for 'sh' in "The Single UNIX ® Specification, Version 2" (http://www.opengroup.org/onlinepubs/007908799/xcu/sh.html / http://www.opengroup.org/onlinepubs/007908799/xcu/chap2.html#tag_001) is that multiline " (double quoted) strings are allowed as well as multiline ` (backquoted) strings.
Comment by Nixx (Nixx) - Saturday, 01 August 2009, 14:16 GMT
Right you are. The bit with "multi line strings" is nonsense. Guessed to quickly, sorry.

The shell in opensolaris turns out to be actually ksh - whoops. That is different in Sol10 (and earlier), where /bin/sh is a traditional Bourne-Shell.

So, something there is incompatible with ksh. It might be related to some kind of escaping, as it is gawk that's complaining about an unterminated string that starts with a tab character (0x09).

Suggestion: If the shebang line named /bin/bash (or even dash), there are only two scenarios: shell is there - you can configure, or the shell isn't there - you immediately recognize where the problem is. I first blamed the awk chosen and tried to replace it, as it is gawk that throws the error. The problem with /bin/sh always is that you cannot rely on it supporting bash, dash, ksh or traditional Bourne-Shell syntax.
Comment by Remko Bijker (Rubidium) - Saturday, 01 August 2009, 14:36 GMT
Does the attached patch (for trunk though it applies to 0.7.2 with some offsets and fuzziness) solve the issue?
Comment by Nixx (Nixx) - Saturday, 01 August 2009, 16:50 GMT
Yes, though there is no $enable_builtin_depend in the 0.7.2 release and the line numbers differ. Your patch modified to apply without warnings against 0.7.2 is attached.

Thank you!

Loading...