#18794 [Fbk->Opn]: inappropriate if logic in configure --with-nsapi

ID: 18794 User updated by: vlb@gene.com Reported By: vlb@gene.com -Status: Feedback +Status: Open Bug Type: *Configuration Issues Operating System: Tru64 Unix (but n/a) PHP Version: 4.2.2 New Comment: When I downloaded and tried the php4-200208140000 archive from http://snaps.php.net, the configure script changes there didn't work. The include directory test succeeded; the version is incorrectly determined to be v3; the test for the header file fails (without any noticeable error message!): ... Configuring SAPI modules ... checking for NSAPI support... /usr/prop/netscape/server4/ checking for NSAPI include files... Netscape-Enterprise/3.x style checking for /usr/prop/netscape/server4//include/nsapi.h... no ... checking for chosen SAPI module... nsapi and the build fails cc: Severe: /vb/Ctech/vlbrown/.../nsapi/nsapi.c, line 50: Cannot find file "nsapi.h" specified in #include directive. (noinclfilef) #include "nsapi.h" -^ *** Exit 1 Stop. > There is a check for the header file nsapi.h in both sections. Yes, I realize this, although I do believe that a simple test -f would suffice over the cpp stuff I saw in the php4-200208140000 version. > Also my brief (albiet limited) understanding is > that nsapi v4 uses only the plugins/include/ > directory, nsapi v3 usrs just the includes > directory. Thus the OR between them. The problem is, you're half right. V4 _uses_ only the plugins/include/ directory but it _posesses_ both directories. The includes directory is empty _but it exists_. It's possible that it was installed this way; it's possible that an upgrade from v3 to v4 doesn't remove the includes directory. Whatever the reason, the fact remains that BOTH directories exist. The current if/elif/else logic never looks for plugins/include (let alone plugins/include/nsapi.h) becaause it finds include (although it fails to find include/nsapi.h). Judging from several of the other bug reports on this same issue, the includes directory (still?) exists for other users at other sites with other installations as well. > Anyways if you can test... > you'll need to run cvsclean and buildconf) We don't use your CVS, but looking at the patch you sent,this is a reasonable change. I applied the changes to the php 4.2.2 configure file; there are no problems finding the include files and the build succeeds as desired. If this change is committed, I would agreee the bug is fixed. Previous Comments: ------------------------------------------------------------------------ [2002-08-13 20:16:15] kalowsky@php.net There is a check for the header file nsapi.h in both sections. Also my brief (albiet limited) understanding is that nsapi v4 uses only the plugins/include/ directory, nsapi v3 usrs just the includes directory. Thus the OR between them. Anyways if you can test this patch to the config.m4 (you'll need to run cvsclean and buildconf) I'd appriciate it Index: config.m4 =================================================================== RCS file: /repository/php4/sapi/nsapi/config.m4,v retrieving revision 1.12 diff -u -u -r1.12 config.m4 --- config.m4 8 Aug 2002 05:52:15 -0000 1.12 +++ config.m4 14 Aug 2002 00:15:19 -0000 @@ -20,11 +20,13 @@ NSAPI_INCLUDE=$PHP_NSAPI/include AC_MSG_RESULT(Netscape-Enterprise/3.x style) AC_CHECK_HEADERS([$NSAPI_INCLUDE/nsapi.h]) - elif test -d $PHP_NSAPI/plugins/include ; then - NSAPI_INCLUDE=$PHP_NSAPI/plugins/include + fi + if test -d $PHP_NSAPI/plugins/include ; then + NSAPI_INCLUDE="$NSAPI_INCLUDE $PHP_NSAPI/plugins/include" AC_MSG_RESULT(iPlanet/4.x style) AC_CHECK_HEADERS([$NSAPI_INCLUDE/nsapi.h]) - else + fi + if test "$NSAPI_INCLUDE" = ""; then AC_MSG_ERROR(Please check you have nsapi.h in either $PHP_NSAPI/include or $PHP_NSAPI/plugins/include) fi PHP_ADD_INCLUDE($NSAPI_INCLUDE) ------------------------------------------------------------------------ [2002-08-13 13:04:19] vlb@gene.com The changed if logic still assumes that it should look for n $PHP_NSAPI/include and then for $PHP_NSAPI/plugins/include ONLY if $PHP_NSAPI/plugins/include did not exist. This is not appropriate logic. Both directories exist. Check for the existence of the file; don't do an if/else on the directories. If you feel you must do a directory check, look for $PHP_NSAPI/plugins/include first; it would be for the newer version of iPlanet. It's all very nice to test that including the .h works (or doesn't) but this is inconsequential if you don't first check for the existence of the file. ------------------------------------------------------------------------ [2002-08-08 01:52:59] kalowsky@php.net Changes made to the configure script. Can you please test this later in a little bit with a new snapshot from http://snaps.php.net Thank you. ------------------------------------------------------------------------ [2002-08-07 17:00:01] vlb@gene.com Configure options configure --with-nsapi=/usr/prop/netscape/server4/ configure succeeds; make exits with cc: Severe: nsapi.c, line 50: Cannot find file "nsapi.h" specified in #include directive. (noinclfilef) #include "nsapi.h" -^ Reason: Configure script contains this if block: if test -d $PHP_NSAPI/include ; then NSAPI_INCLUDE=$PHP_NSAPI/include echo "$ac_t""Netscape-Enterprise/3.x style" 1>&6 elif test -d $PHP_NSAPI/plugins/include ; then NSAPI_INCLUDE=$PHP_NSAPI/plugins/include echo "$ac_t""iPlanet/4.x style" 1>&6 else { echo "configure: error: Please check you have nsapi.h in either DIR/include DIR/plugins/include" 1>&2; exit 1; } fi There are two things wrong here: 1) it is inappropriate to check for $PHP_NSAPI/include; the appropriate test should be for the _file_ $PHP_NSAPI/include/nsapi.h In our case, both $PHP_NSAPI/include and $PHP_NSAPI/plugins/include exist (this has also been the case for at least one of the other bugs filed; see #5233). Configure should not assume a file exists simply because a directory it might be in happens to exist. 2) In the error message, `DIR' is meaningless. The error should use $PHP_NSAPI, not the literal string `DIR'. See also bug 11446 and several others, closed as "bogus" or "not a bug in PHP". While that is technically true, the bug is nonetheless in the PHP configuration script, and it should be addressed by the php team. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=18794&edit=1