Hi Peter, There were several problems with the configure.in file. Before I send the patch, here's a list of issues: 1. The logic of AC_ARG_ENABLE is (feature, help-string, [action-if-given], [action-if-not-given]) not (feature, help-string, [action-if-yes], [action-if-no]) Similary with AC_ARG_WITH. So if you want to do different things depending on whether --enable or --disable was set, then you need to check for that in [action-if-given]. This was fixed in several places. 2. The use of $enableval and $withval is dangerous because those shell variables are not reset between tests. So, for AC_ARG_ENABLE(foo-foo, ...) its better to use $enable_foo_foo to test --en/disable-foo-foo. Also note that - in features become _ in the variables. I make this change throughout. 3. AC_ARG_WITH does not touch $enableval or any $enable_*. A couple of places there was AC_ARG_WITH(foo, ... $enableval ... ). 4. There was some whitespace damage here and there. 5. Consider renaming the file configure.ac. You can convince yourself of the above by playing with the following configure.ac. Put it in its own dir, and run autoreconf -i. Then try "./configure --enable-foo-foo" to convince yourself of the dangers of $enableval. AC_INIT AC_ARG_ENABLE( [foo-foo],[AS_HELP_STRING([--enable-foo-foo])], [ AC_MSG_RESULT(some foo-foo option given[]) dnl echo "foo-foo enable value =" $enable_foo_foo echo "foo-foo enable value =" $enableval ],[ AC_MSG_RESULT(no foo-foo option given[]) dnl echo "foo-foo enable value =" $enable_foo_foo echo "foo-foo enable value =" $enableval ] ) dnl echo $enable_foo_foo AC_ARG_ENABLE( [bar],[AS_HELP_STRING([--enable-bar])], [ AC_MSG_RESULT(some bar option given[]) dnl echo "bar enable value =" $enable_bar echo "bar enable value =" $enableval ],[ AC_MSG_RESULT(no bar option given[]) dnl echo "bar enable value =" $enable_bar echo "bar enable value =" $enableval ] ) dnl echo $enable_bar AC_ARG_WITH( [bas],[AS_HELP_STRING([--enable-bas=<value>])], [ AC_MSG_RESULT(some bas value given[]) echo "bas with value =" $with_bas echo "bas enable value =" $enable_bas ],[ AC_MSG_RESULT(no bas value given[]) echo "bas value value =" $with_bas echo "bas enable value =" $enable_bas ] ) On 05/31/14 03:29, Peter Bieringer wrote:
Hi,
thank you for reporting the issue.
I'm currently on holidays and unable to fix the issue before mid of June.
If one of you can meanwhile create a patch I would be very happy.
Thank you very much!
Best regards, Peter
Am 30.05.2014 14:33, schrieb Anthony G. Basile:
Hi Peter et al.
Can I ask you to look at Gentoo bug #511578. The url is
https://bugs.gentoo.org/show_bug.cgi?id=511578
While its easy enough to produce a patch here, it does depend on what upstream wants.
The issue in a nutshell can be seen by the following configure line (tested on 0.97.2).
# ./configure --disable-bundled-getopt | grep -C 3 forced checking for working memcmp... yes checking for strspn... yes checking for strstr... yes *** use of bundled getopt library forced checking openssl/md5.h usability... yes checking openssl/md5.h presence... yes checking for openssl/md5.h... yes
We ask to disable bundled-getopt and yet we get it. getopt is provided by glibc in this case and AC_CHECK_FUNC(getopt_long ...) does not fail. Rather, the logic wrt to how AC_ARG_ENABLE is used is incorrect. See
https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Generic...
with particular attention to the [action-if-found]. The problem is repeated in several places.
In my opinion, and if I were to produce a patch, it would work as follows:
./configure --enable-bundled-getopt <- Don't bother checking if getopt_long is provided, just used the bundled version.
./configure --disable-bundled-getopt <- Check if getopt_long is provided via AC_CHECK_FUNC. If it is, use it. If it is not, fail with an error message. Under no circumstances should you used the bundled getopt.
-- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197