In both trunk and 1.2.32: $ svn checkout https://svn.apache.org/repos/asf/tomcat/jk/tags/JK_1_2_32 $ cd JK_1_2_32/native $ ./buildconf.sh (you don't need to do this if you didn't use svn) $ which apxs2 /usr/bin/apxs2 $ ./configure --with-apxs=/usr/bin/apxs2 ... config.status: creating common/config.h config.status: executing depfiles commands config.status: executing libtool commands /bin/rm: cannot remove `libtoolT': No such file or directory Running "make" at this point for me results in a complete build, so it doesn't look like anything truly important is being skipped. For complete details see http://markmail.org/message/rofubigkpw73bi4a
'libtoolT' is created and removed by config.status. config.status removes previous 'libtoolT' prior to creating new file. If you create the configure script using buildconf.sh on your system, for example CentOS6, the generated script creates following script.(CentOS6 contains aclocal-1.11.1.) -----snippet of config.status 1487 1488 cfgfile="${ofile}T" 1489 trap "$RM \"$cfgfile\"; exit 1" 1 2 15 1490 $RM "$cfgfile" 1491 1492 cat <<_LT_EOF >> "$cfgfile" 1493 #! $SHELL 1494 --- You get the following message because the rm command has no option. rm: libtoolT: No such file or directory If you use aclocal-1.10, the configure script creates following script. ----- 1323 1324 cfgfile="${ofile}T" 1325 trap "$RM -f \"$cfgfile\"; exit 1" 1 2 15 1326 $RM -f "$cfgfile" 1327 1328 cat <<_LT_EOF >> "$cfgfile" 1329 #! $SHELL 1330 --- You don't get the above message because the rm command has the -f option. regards. Eiji
Eiji, does this mean there is a problem with aclocal (I have Debian Squeeze, with aclocal 1.11.1), then? Or is is a problem with the use of that tool?
(In reply to comment #2) > Eiji, does this mean there is a problem with aclocal (I have Debian Squeeze, > with aclocal 1.11.1), then? Or is is a problem with the use of that tool? I think there is no problem. Usually, the config.status script renames the file 'libtoolT' to 'libtool'(line 2106). Or it deletes 'libtoolT'(line 2107). Therefore, the file named 'libtoolT' doesn't remain after executing the configure script. -----snippet of config.status 2106 mv -f "$cfgfile" "$ofile" || 2107 (rm -f "$ofile" && cp "$cfgfile" "$ofile" && rm -f "$cfgfile") 2108 chmod +x "$ofile" --- I think that there is any problem if the configure(config.status) doesn't report that message. > -----snippet of config.status > 1487 > 1488 cfgfile="${ofile}T" > 1489 trap "$RM \"$cfgfile\"; exit 1" 1 2 15 > 1490 $RM "$cfgfile" > 1491 > 1492 cat <<_LT_EOF >> "$cfgfile" > 1493 #! $SHELL > 1494 > --- > regards.
As Eiji said, it is just an annoyance. I think the cited script snippet comes from libtool.m4. For libtool 1 I can see consistently "rm -f" being used. For libtool 2 there is simply $RM, and in libtool.m4 RM seems to get set to "rm -f". So it might be intersting to check, which part overwrites the "RM" setting with plain "rm". Regards, Rainer
Okay, I agree that it's "merely" an annoyance, but it's nice if these things can build without any errors or warnings. This isn't CPAN :) Is there anything /we/ can do about making our build work without this error message?
Option '-f' causes command 'rm' to remove file quietly, i.e. without checking if file exists (see Linux manual page http://man7.org/linux/man-pages/man1/rm.1.html for details). The bug remains in either of the version quoted above: config script is trying to remove file that does not exist. I encountered this bug while running script 'configure' in package 'apr-1.5.2' downloaded from 'http://apr.apache.org/'. As suggested by Christopher, I ignored it and installed APR successfully using 'make' and 'make install'.