Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote: > On Wed, 5 Sep 2012, Joerg Schilling wrote: > > > > Given the fact that GNU autoconf has been more or less destroyed after > > release > > 2.13, so I personally base my work on an extremely enhanced gnu autoconf > > 2.13. > > The timing tests I did run, have been run with my enhanced autoconf-2.13 > > It was temporarily "destroyed" but then it was "undestroyed" so things > are ok again (while you were sleeping). However, work is required in > order to catch up.
Maybe, but this does not help me. My software compiles on more platforms than the ones that are supported by GNU autoconf. In order to achieve this, I was forced to add massive enhancements into config.guess and config.sub. Unfortunately GNU autoconf did enhance their versions of these files in a way that does not allow a code review, so I am not able to verify whether the new GNU versions support every platform I support. My conclusion is that a recent GNU autoconf is worth less than my version and the FSF slept while I was working. > Try invoking like it like > > CONFIG_SHELL=/usr/bin/dash /usr/bin/dash ./configure > > If the starting shell and the official configure shell are the same, > then it should avoid the paranoid behavior that you describe. I know that this works as expected for my autoconf. I did never check with recent GNU autoconf and to me it does not make sense to switch to a less usable system from the FSF - I stay with my enhanced version. > This is totally off topic for this discussion thread. A new > discussion thread should be started for the possibility of replacing > /bin/sh with your Schily shell. This is a new proposal from you. I will definitely replace /sbin/sh back to the Bourne Shell in order to permit again to split root and /usr. I am not shure whether I will do more later. Given the fact that POSIX intentionally does not deal with path names like /bin/sh and the fact that even ksh93 is not fully POSIX compliant, see e.g. the output from the "times" command, there is no need to have /bin/sh == ksh93. We had a really POSIX compliant shell on Solaris, which was the enhanced ksh88 but that was closed source and cannot be used in the future. Note e.g. that we (the POSIX commitee) recently changed the POSIX standard to match users expectations for an orthogonal behavior and now require that "for i; do ...." works. David Korn changed this for ksh93 and I changed this for the Bourne Shell, but for the closed source ksh88, we have no chance to get it to the current standard requirements. POSIX requires that you get a POSIX compliant shell after you call: PATH=`getconf PATH` sh This PATH is /usr/xpg4/bin:/usr/ccs/bin:/usr/bin:/opt/SUNWspro/bin on Solaris, so we just _need_ to have a POSIX shell in /usr/xpg4/bin/sh. As I mentioned before, there are 6 scripts in ONNV that have become non-portable after Sun switched /bin/sh to ksh93. Therse scripts are easy to fix. I however cannot speak for other scripts that are part of additional software. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de (uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily _______________________________________________ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev