"Lars J. Aas" <[EMAIL PROTECTED]> writes: > Is it possible that this is a local problem for the given MKS user I > am working with and that he may have a somewhat faulty MKS > installation or something?
Possibly. It'd be nice if we could have another MKS user report what happens. Or perhaps you or your user can consult the MKS bug database (I can't; it's private). > When porting our autoconf/automake/libtool setup for Coin > (www.coin3d.org) to work on MKS, I found that I had to apply the > following patch to Autoconf 2.57 to get the generated config.status > script to behave: Hmm, that looks pretty ad-hoc. Why did you need to change just these case statements, and not all the case statements in Autoconf and Libtool? What were the symptoms of the failure? Do you have a small shell script that illustrates the problem? Unless we understand the bug I'm a little leery of trying to insert "true"s seemingly at random. For example, if it's an internal buffer-boundary bug, a small change earlier in the script will cause the bug to reappear, the "true"s notwithstanding. That being said, does it fix things if you make one of the following changes instead? >From this: for ac_file in : $CONFIG_HEADERS; do test "x$ac_file" = x: && continue ... done to this: case $CONFIG_HEADERS in ?*) for ac_file in $CONFIG_HEADERS; do ... done;; esac or to this: for ac_file in : $CONFIG_HEADERS; do case $ac_file in :) ...;; esac done or to this: for ac_file in : $CONFIG_HEADERS; do test "x$ac_file" = x: && continue ... done or to this: for ac_file in : $CONFIG_HEADERS; do if "x$ac_file" != x:; then ... fi done (Whew! You get the idea.) Also, you might try changing the "; do" to a newline-do, e.g.: for ac_file in : $CONFIG_HEADERS do case $ac_file in :) ...;; esac done in any of the above solutions, as we know of shells that screw up "; do" in some cases. _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool