Created attachment 377678 [details, diff] ipv6calc-0.97.2.ebuild.patch I compared installed files for my ebuild and ebuild from tree, version from tree installed binary files with bigger sizes and they were not linked to libcrypto.so.1.0.0. Then i compared build logs, version from tree has this in linking command for every bin: ../getopt/getopt.o ../getopt/getopt1.o ../md5/md5.o Version from tree adds internal copy of md5 and getopt to every ebuild, attached patch fixes it. P.S. Why ebuild from tree has --disable-db-ipv6? Isn't it 'IPV6calc' package?
Created attachment 377680 [details, diff] installed_files.diff
Created attachment 377682 [details, diff] build_logs.diff
Actually, things are both more simple and more complicated. It's an ebuild bug..in a way. Upstream configure.in adds option *only* to disable builtin md5/getopt. If those options are not given, script goes the autodetection route. That's a bit ugly, but seems to be sufficient in this case. So, what really mattered here was not adding '--enable-shared', but removing '--disable-bundled-getopt --disable-bundled-md5'. I wonder though both about '--disable-shared' in the ebuild and upstream making that the default.
...typo: ...adds option *only* to enable builtin
(In reply to Rafał Mużyło from comment #3) > Actually, things are both more simple and more complicated. > > It's an ebuild bug..in a way. > > Upstream configure.in adds option *only* to disable builtin md5/getopt. > If those options are not given, script goes the autodetection route. The syntax should be AC_ARG_ENABLE (feature, help-string, [action-if-given], [action-if-not-given]) but ipv6calc is using AC_ARG_ENABLE( [bundled-getopt], <help-string>, [ AC_MSG_RESULT([*** use of bundled getopt library forced]) ENABLE_BUNDLED_GETOPT=1 ], <action-if-not-given>) So if --enable or --disable is given, then ENABLE_BUNDLED_GETOPT=1 is set. This mistaken logic is repeated throughout. This is a bug in ipv6calc, not the ebuild. The ebuild just triggers the bug. However, even the <action-if-not-given> is unsatisfactory from gentoo's point of view. It should crap out, not default to ENABLE_BUNDLED_GETOPT=1.
Not quite. It's more of this being an upstream choice, cause the use *is* valid, if bit atypical. By design, for AC_ARG_ENABLE, '--enable-foo' is equivalent to '--enable-foo=yes', which translates to $enable_foo==yes, while '--disable-foo' is equivalent to '--enable-foo=no'/$enable_foo==no respectively. Most common use of this is to have a test in the third argument of this macro for the value given, here, however, upstream simply decided to *not* test and simply assume, that if the argument was passed it was to enable builtins. There's really nothing invalid about that, it's only different from the usual use.
(In reply to Rafał Mużyło from comment #6) > Not quite. > > It's more of this being an upstream choice, cause the use *is* valid, if bit > atypical. No, this code is wrong: # ./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 Then in Makefile.in, the ifeq (@ENABLE_BUNDLED_GETOPT@, 1) GETOPT_MAKE = getopt-make GETOPT_DIR = getopt endif and later many lines like ipv6logconv: $(GETOPT_MAKE) lib-make ipv6logconv-make > > By design, for AC_ARG_ENABLE, '--enable-foo' is equivalent to > '--enable-foo=yes', which translates to $enable_foo==yes, while > '--disable-foo' is equivalent to '--enable-foo=no'/$enable_foo==no > respectively. > > Most common use of this is to have a test in the third argument of this > macro for the value given, here, however, upstream simply decided to *not* > test and simply assume, that if the argument was passed it was to enable > builtins. True but irrelavent. If someone passes --disable-bundled-getopt you expect the bundled-getop to be disabled, not the opposite. The reason this happens is as per my analysis. > > There's really nothing invalid about that, it's only different from the > usual use. This code is misleading and should be changed upstream.
Please test 0.97.2-r1 and reopen this if it is still of issue.
r1 ebuild works fine, installed files are now same as when using my ebuild from local overlay. Thank you :)
