Re: [ipv6calc] ipv6calc: use shared libipv6calc.so and databases
Hi Nikoli, Am 31.01.2014 06:59, schrieb Nikoli:
Hello, thanks for ipv6calc, have suggestion about build system: use shared libipv6calc.so and databases instead of duplicating them in every bin.
$ equery s ipv6calc * net-misc/ipv6calc-0.95.0 Total files : 20 Total size : 11.38 MiB
Size is huge, because every bin has internal copy of databases/ lib/ md5/ $ du -sh /usr/bin/ipv6* 2,9M /usr/bin/ipv6calc 2,8M /usr/bin/ipv6loganon 2,8M /usr/bin/ipv6logconv 2,8M /usr/bin/ipv6logstats
Please avoid duplication and move shared databases and shared code to '/usr/lib64/libipv6calc.so'.
Your right, I have this already in mind since longer, also having extra database binary files (easy to update them extra afterwards)...and have plans since longer to create a shared library by default and also replace the md5 code inside by external one (if available)...let see when I can find time to improve the project. BTW: if you are able to contribute, you're very welcome! Regards, Peter
Hi, shared library support added, please try latest CVS trunk using: add support for building with shared libraries: configure: --enalbe-shared-library autogen.sh: -S Note: spec file for RPM is still not tested, coming next Regards, Peter Am 31.01.2014 07:39, schrieb Peter Bieringer:
Hi Nikoli,
Am 31.01.2014 06:59, schrieb Nikoli:
Hello, thanks for ipv6calc, have suggestion about build system: use shared libipv6calc.so and databases instead of duplicating them in every bin.
$ equery s ipv6calc * net-misc/ipv6calc-0.95.0 Total files : 20 Total size : 11.38 MiB
Size is huge, because every bin has internal copy of databases/ lib/ md5/ $ du -sh /usr/bin/ipv6* 2,9M /usr/bin/ipv6calc 2,8M /usr/bin/ipv6loganon 2,8M /usr/bin/ipv6logconv 2,8M /usr/bin/ipv6logstats
Please avoid duplication and move shared databases and shared code to '/usr/lib64/libipv6calc.so'.
Your right, I have this already in mind since longer, also having extra database binary files (easy to update them extra afterwards)...and have plans since longer to create a shared library by default and also replace the md5 code inside by external one (if available)...let see when I can find time to improve the project.
BTW: if you are able to contribute, you're very welcome!
Regards, Peter
_______________________________________________ ipv6calc mailing list ipv6calc@lists.deepspace6.net https://lists.deepspace6.net/listinfo/ipv6calc ipv6calc homepage: http://www.deepspace6.net/projects/ipv6calc.html ipv6calc cvs: http://cvs.deepspace6.net/view/ipv6calc/
Hello, tried building it, fails for me, attached log. My distro is amd64 hardened Gentoo Linux. Compared current cvs and 0.95.0 sources, bugs and suggestions: 1) These commands do not respect CC CFLAGS LDFLAGS: gcc -shared -Wl,-soname,libipv6calc_db_wrapper.so.@PACKAGE_VERSION@ -o libipv6calc_db_wrapper.so.@PACKAGE_VERSION@ $(OBJS) gcc -shared -Wl,-soname,libipv6calc.so.@PACKAGE_VERSION@ -o libipv6calc.so.@PACKAGE_VERSION@ $(OBJS) 2) Most autotools based packages use --enable-shared option, also there is typo in configure: --enaLBe-shared-library Enable shared library build (default: disabled) В сообщении от 1 февраля 2014 18:57:30 автор Peter Bieringer написал:
Hi,
shared library support added, please try latest CVS trunk using:
add support for building with shared libraries: configure: --enalbe-shared-library autogen.sh: -S
Note: spec file for RPM is still not tested, coming next
Regards, Peter
Am 31.01.2014 07:39, schrieb Peter Bieringer:
Hi Nikoli,
Am 31.01.2014 06:59, schrieb Nikoli:
Hello, thanks for ipv6calc, have suggestion about build system: use shared libipv6calc.so and databases instead of duplicating them in every bin.
$ equery s ipv6calc
* net-misc/ipv6calc-0.95.0
Total files : 20 Total size : 11.38 MiB
Size is huge, because every bin has internal copy of databases/ lib/ md5/ $ du -sh /usr/bin/ipv6* 2,9M /usr/bin/ipv6calc 2,8M /usr/bin/ipv6loganon 2,8M /usr/bin/ipv6logconv 2,8M /usr/bin/ipv6logstats
Please avoid duplication and move shared databases and shared code to '/usr/lib64/libipv6calc.so'.
Your right, I have this already in mind since longer, also having extra database binary files (easy to update them extra afterwards)...and have plans since longer to create a shared library by default and also replace the md5 code inside by external one (if available)...let see when I can find time to improve the project.
BTW: if you are able to contribute, you're very welcome!
Regards,
Peter
_______________________________________________ ipv6calc mailing list ipv6calc@lists.deepspace6.net https://lists.deepspace6.net/listinfo/ipv6calc ipv6calc homepage: http://www.deepspace6.net/projects/ipv6calc.html ipv6calc cvs: http://cvs.deepspace6.net/view/ipv6calc/
Hi Nikoli, Am 01.02.2014 17:37, schrieb Nikoli:
Hello, tried building it, fails for me, attached log. My distro is amd64 hardened Gentoo Linux.
Compared current cvs and 0.95.0 sources, bugs and suggestions: 1) These commands do not respect CC CFLAGS LDFLAGS: gcc -shared -Wl,-soname,libipv6calc_db_wrapper.so.@PACKAGE_VERSION@ -o libipv6calc_db_wrapper.so.@PACKAGE_VERSION@ $(OBJS) gcc -shared -Wl,-soname,libipv6calc.so.@PACKAGE_VERSION@ -o libipv6calc.so.@PACKAGE_VERSION@ $(OBJS)
Hopefully fixed now (it is my first time to create shared library support, so I copy&pasted from howto...).
2) Most autotools based packages use --enable-shared option, also there is typo in configure: --enaLBe-shared-library Enable shared library build (default: disabled)
Fixed.
gnu/bin/ld: libipv6calc_db_wrapper.o: relocation R_X86_64_PC32 against symbol `wrapper_features' can not be used when making a shared object; recompile with -fPIC
Please try again, if it still breaks like before, I have to doublecheck and run some tests on other systems (my primary developing box is currently Fedora 20). Please try latest trunk - thank you for support! Regards, Peter
В сообщении от 2 февраля 2014 01:17:26 автор Peter Bieringer написал:
Hi Nikoli,
Am 01.02.2014 17:37, schrieb Nikoli:
Hello, tried building it, fails for me, attached log. My distro is amd64 hardened Gentoo Linux.
Compared current cvs and 0.95.0 sources, bugs and suggestions: 1) These commands do not respect CC CFLAGS LDFLAGS: gcc -shared -Wl,-soname,libipv6calc_db_wrapper.so.@PACKAGE_VERSION@ -o libipv6calc_db_wrapper.so.@PACKAGE_VERSION@ $(OBJS) gcc -shared -Wl,-soname,libipv6calc.so.@PACKAGE_VERSION@ -o libipv6calc.so.@PACKAGE_VERSION@ $(OBJS)
Hopefully fixed now (it is my first time to create shared library support, so I copy&pasted from howto...).
2) Most autotools based packages use --enable-shared option, also there is
typo in configure: --enaLBe-shared-library Enable shared library build (default: disabled)
Fixed.
gnu/bin/ld: libipv6calc_db_wrapper.o: relocation R_X86_64_PC32 against
symbol `wrapper_features' can not be used when making a shared object; recompile with -fPIC
Please try again, if it still breaks like before, I have to doublecheck and run some tests on other systems (my primary developing box is currently Fedora 20).
Please try latest trunk - thank you for support!
Regards, Peter
Hi, You did not add -fPIC, build still fails with same error, attached ipv6calc- fpic.patch fixes this problem, see also: http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3#doc_chap6 Building with LDFLAGS="-Wl,-O1 -Wl,--as-needed" fails, attached build.log --as-needed is enabled by default in many distros including Gentoo, Debian and opensuse: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/As-needed https://wiki.debian.org/ToolChain/DSOLinking Attached ipv6calc-as-needed.patch fixes build with --as-needed by changing order of arguments in CC commands. libipv6calc.so.0.96.0 is installed to / instead of /usr/lib64, libipv6calc_db_wrapper.so.0.96.0 was not installed at all, ipv6calc-as- needed.patch fixes these bugs too. "make install" rebuilds ipv6calc ipv6logconv ipv6logstats ipv6loganon, it is wrong, ipv6calc-no-rebuild.patch fixes this bug. Typo is still around: $ grep -i enalbe -R ChangeLog: configure: --enalbe-shared P.S. Why you are still using cvs instead of git? Providing patches and reviewing sources would be much simpler and faster with git and github.com or cgit.deepspace6.net webui.
Hi Nikoli, thank you for all the patches, applied. Also for others, RPM spec file is now also working. # rpm -qvl ipv6calc |egrep '/(bin|lib)' -rwxr-xr-x 1 root root 87744 Feb 2 13:35 /usr/bin/ipv6calc -rwxr-xr-x 1 root root 24216 Feb 2 13:35 /usr/bin/ipv6loganon -rwxr-xr-x 1 root root 28216 Feb 2 13:35 /usr/bin/ipv6logconv -rwxr-xr-x 1 root root 29368 Feb 2 13:35 /usr/bin/ipv6logstats -rwxr-xr-x 1 root root 410488 Feb 2 13:35 /usr/lib64/libipv6calc.so.0.96.0 -rwxr-xr-x 1 root root 2588192 Feb 2 13:35 /usr/lib64/libipv6calc_db_wrapper.so.0.96.0 => size of binaries reduced, database information is now mostly in libipv6calc_db_wrapper.so (leftovers in libipv6calc.so will be moved next) BTW1: install was not tested so far, sorry! BTW2: switch from CVS to GIT is planned, but not on top priority at the moment unfortunately because lack of time. Hope this helps! Regards, Peter Am 02.02.2014 12:27, schrieb Nikoli:
В сообщении от 2 февраля 2014 01:17:26 автор Peter Bieringer написал:
Hi Nikoli,
Am 01.02.2014 17:37, schrieb Nikoli:
Hello, tried building it, fails for me, attached log. My distro is amd64 hardened Gentoo Linux.
Compared current cvs and 0.95.0 sources, bugs and suggestions: 1) These commands do not respect CC CFLAGS LDFLAGS: gcc -shared -Wl,-soname,libipv6calc_db_wrapper.so.@PACKAGE_VERSION@ -o libipv6calc_db_wrapper.so.@PACKAGE_VERSION@ $(OBJS) gcc -shared -Wl,-soname,libipv6calc.so.@PACKAGE_VERSION@ -o libipv6calc.so.@PACKAGE_VERSION@ $(OBJS)
Hopefully fixed now (it is my first time to create shared library support, so I copy&pasted from howto...).
2) Most autotools based packages use --enable-shared option, also there is
typo in configure: --enaLBe-shared-library Enable shared library build (default: disabled)
Fixed.
gnu/bin/ld: libipv6calc_db_wrapper.o: relocation R_X86_64_PC32 against
symbol `wrapper_features' can not be used when making a shared object; recompile with -fPIC
Please try again, if it still breaks like before, I have to doublecheck and run some tests on other systems (my primary developing box is currently Fedora 20).
Please try latest trunk - thank you for support!
Regards, Peter
Hi,
You did not add -fPIC, build still fails with same error, attached ipv6calc- fpic.patch fixes this problem, see also: http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3#doc_chap6
Building with LDFLAGS="-Wl,-O1 -Wl,--as-needed" fails, attached build.log --as-needed is enabled by default in many distros including Gentoo, Debian and opensuse: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/As-needed https://wiki.debian.org/ToolChain/DSOLinking Attached ipv6calc-as-needed.patch fixes build with --as-needed by changing order of arguments in CC commands.
libipv6calc.so.0.96.0 is installed to / instead of /usr/lib64, libipv6calc_db_wrapper.so.0.96.0 was not installed at all, ipv6calc-as- needed.patch fixes these bugs too.
"make install" rebuilds ipv6calc ipv6logconv ipv6logstats ipv6loganon, it is wrong, ipv6calc-no-rebuild.patch fixes this bug.
Typo is still around: $ grep -i enalbe -R ChangeLog: configure: --enalbe-shared
P.S. Why you are still using cvs instead of git? Providing patches and reviewing sources would be much simpler and faster with git and github.com or cgit.deepspace6.net webui.
Current cvs works fine for me, so when do you plan to make new release? :) В сообщении от 2 февраля 2014 16:47:57 автор Peter Bieringer написал:
Hi Nikoli,
thank you for all the patches, applied. Also for others, RPM spec file is now also working.
# rpm -qvl ipv6calc |egrep '/(bin|lib)' -rwxr-xr-x 1 root root 87744 Feb 2 13:35 /usr/bin/ipv6calc -rwxr-xr-x 1 root root 24216 Feb 2 13:35 /usr/bin/ipv6loganon -rwxr-xr-x 1 root root 28216 Feb 2 13:35 /usr/bin/ipv6logconv -rwxr-xr-x 1 root root 29368 Feb 2 13:35 /usr/bin/ipv6logstats -rwxr-xr-x 1 root root 410488 Feb 2 13:35 /usr/lib64/libipv6calc.so.0.96.0 -rwxr-xr-x 1 root root 2588192 Feb 2 13:35 /usr/lib64/libipv6calc_db_wrapper.so.0.96.0
=> size of binaries reduced, database information is now mostly in libipv6calc_db_wrapper.so (leftovers in libipv6calc.so will be moved next)
BTW1: install was not tested so far, sorry!
BTW2: switch from CVS to GIT is planned, but not on top priority at the moment unfortunately because lack of time.
Hope this helps!
Regards, Peter
Am 02.02.2014 12:27, schrieb Nikoli:
В сообщении от 2 февраля 2014 01:17:26 автор Peter Bieringer написал:
Hi Nikoli,
Am 01.02.2014 17:37, schrieb Nikoli:
Hello, tried building it, fails for me, attached log. My distro is amd64 hardened Gentoo Linux.
Compared current cvs and 0.95.0 sources, bugs and suggestions: 1) These commands do not respect CC CFLAGS LDFLAGS: gcc -shared -Wl,-soname,libipv6calc_db_wrapper.so.@PACKAGE_VERSION@ -o libipv6calc_db_wrapper.so.@PACKAGE_VERSION@ $(OBJS) gcc -shared -Wl,-soname,libipv6calc.so.@PACKAGE_VERSION@ -o libipv6calc.so.@PACKAGE_VERSION@ $(OBJS)
Hopefully fixed now (it is my first time to create shared library support, so I copy&pasted from howto...).
2) Most autotools based packages use --enable-shared option, also there is
typo in configure: --enaLBe-shared-library Enable shared library build (default: disabled)
Fixed.
gnu/bin/ld: libipv6calc_db_wrapper.o: relocation R_X86_64_PC32 against
symbol `wrapper_features' can not be used when making a shared object; recompile with -fPIC
Please try again, if it still breaks like before, I have to doublecheck and run some tests on other systems (my primary developing box is currently Fedora 20).
Please try latest trunk - thank you for support!
Regards,
Peter
Hi,
You did not add -fPIC, build still fails with same error, attached ipv6calc- fpic.patch fixes this problem, see also: http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3#d oc_chap6
Building with LDFLAGS="-Wl,-O1 -Wl,--as-needed" fails, attached build.log --as-needed is enabled by default in many distros including Gentoo, Debian and opensuse: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/As-needed https://wiki.debian.org/ToolChain/DSOLinking Attached ipv6calc-as-needed.patch fixes build with --as-needed by changing order of arguments in CC commands.
libipv6calc.so.0.96.0 is installed to / instead of /usr/lib64, libipv6calc_db_wrapper.so.0.96.0 was not installed at all, ipv6calc-as- needed.patch fixes these bugs too.
"make install" rebuilds ipv6calc ipv6logconv ipv6logstats ipv6loganon, it is wrong, ipv6calc-no-rebuild.patch fixes this bug.
Typo is still around: $ grep -i enalbe -R ChangeLog: configure: --enalbe-shared
P.S. Why you are still using cvs instead of git? Providing patches and reviewing sources would be much simpler and faster with git and github.com or cgit.deepspace6.net webui.
Hi Nikoli, Am 02.02.2014 20:31, schrieb Nikoli:
Current cvs works fine for me, so when do you plan to make new release? :)
soon, but your 2nd requested feature must be tested first on other systems. I've extended configure.in to check for md5 function in libcrypto, but I assume current handling will only work for RedHat/CentOS/Fedora. Can you please check on your system whether the autodetection and build also works. btw: configure options were added to force switching to bundled versions: configure: --enable-bundled-md5 --enable-bundled-getopt Thank you very much! Regards, Peter
Now cvs fails to install, attached log. В сообщении от 3 февраля 2014 00:15:16 автор Peter Bieringer написал:
Hi Nikoli,
Am 02.02.2014 20:31, schrieb Nikoli:
Current cvs works fine for me, so when do you plan to make new release? :)
soon, but your 2nd requested feature must be tested first on other systems.
I've extended configure.in to check for md5 function in libcrypto, but I assume current handling will only work for RedHat/CentOS/Fedora.
Can you please check on your system whether the autodetection and build also works.
btw: configure options were added to force switching to bundled versions:
configure: --enable-bundled-md5 --enable-bundled-getopt
Thank you very much!
Regards, Peter
Hi Nikoli, Am 02.02.2014 21:28, schrieb Nikoli:
Now cvs fails to install, attached log.
This had a different reason make[1]: Entering directory `/var/package-manager/tmp/portage/net-misc/ipv6calc-0.96.0_pre/work/ipv6calc/ipv6calcweb' make[1]: *** No rule to make target `install'. Stop. make[1]: Leaving directory `/var/package-manager/tmp/portage/net-misc/ipv6calc-0.96.0_pre/work/ipv6calc/ipv6calcweb' Result: 2 proper error catching on main Makefile detect now missing "install:" in Makefile of ipv6calcweb...Fixed in CVS now. but the following is not expected: checking for MD5_Init in -lcrypto... yes checking for MD5_Init... no checking for MD5_Update... no checking for MD5_Final... no checking for MD5_Transform... no on my Fedora system this part of configure.in works: LDFLAGS="$LDFLAGS -lcrypto" AC_CHECK_FUNCS(MD5_Init MD5_Update MD5_Final MD5_Transform, [ ], [ ENABLE_BUNDLED_MD5=1 ]) checking for MD5_Init in -lcrypto... yes checking for MD5_Init... yes checking for MD5_Update... yes checking for MD5_Final... yes checking for MD5_Transform... yes disabling: LDFLAGS="$LDFLAGS -lcrypto" would show same result as yours...looks like the LDFLAGS on your systems must be set different...would be great if you can support me here. Regards, Peter
В сообщении от 3 февраля 2014 00:41:24 автор Peter Bieringer написал:
Hi Nikoli,
Am 02.02.2014 21:28, schrieb Nikoli:
Now cvs fails to install, attached log.
This had a different reason
make[1]: Entering directory `/var/package-manager/tmp/portage/net-misc/ipv6calc-0.96.0_pre/work/ipv6cal c/ipv6calcweb' make[1]: *** No rule to make target `install'. Stop. make[1]: Leaving directory `/var/package-manager/tmp/portage/net-misc/ipv6calc-0.96.0_pre/work/ipv6cal c/ipv6calcweb' Result: 2
proper error catching on main Makefile detect now missing "install:" in Makefile of ipv6calcweb...Fixed in CVS now.
Confirm, it works fine now.
but the following is not expected:
checking for MD5_Init in -lcrypto... yes checking for MD5_Init... no checking for MD5_Update... no checking for MD5_Final... no checking for MD5_Transform... no
on my Fedora system this part of configure.in works:
LDFLAGS="$LDFLAGS -lcrypto" AC_CHECK_FUNCS(MD5_Init MD5_Update MD5_Final MD5_Transform, [ ], [ ENABLE_BUNDLED_MD5=1 ])
checking for MD5_Init in -lcrypto... yes checking for MD5_Init... yes checking for MD5_Update... yes checking for MD5_Final... yes checking for MD5_Transform... yes
disabling: LDFLAGS="$LDFLAGS -lcrypto"
would show same result as yours...looks like the LDFLAGS on your systems must be set different...would be great if you can support me here.
Same CC argument order problem: it does not support --as-needed, without it configure detects md5 fine. Attached config.log without and with LDFLAGS="-Wl,-- hash-style=gnu -Wl,-O1 -Wl,--as-needed"
Hi Nikoli, thank you again for testing. Am 03.02.2014 20:22, schrieb Nikoli:
but the following is not expected:
checking for MD5_Init in -lcrypto... yes checking for MD5_Init... no checking for MD5_Update... no checking for MD5_Final... no checking for MD5_Transform... no
on my Fedora system this part of configure.in works:
LDFLAGS="$LDFLAGS -lcrypto" AC_CHECK_FUNCS(MD5_Init MD5_Update MD5_Final MD5_Transform, [ ], [ ENABLE_BUNDLED_MD5=1 ])
checking for MD5_Init in -lcrypto... yes checking for MD5_Init... yes checking for MD5_Update... yes checking for MD5_Final... yes checking for MD5_Transform... yes
disabling: LDFLAGS="$LDFLAGS -lcrypto"
would show same result as yours...looks like the LDFLAGS on your systems must be set different...would be great if you can support me here.
Same CC argument order problem: it does not support --as-needed, without it configure detects md5 fine. Attached config.log without and with LDFLAGS="-Wl,-- hash-style=gnu -Wl,-O1 -Wl,--as-needed"
reproduced, configure.in fixed, please try again - also I've prepended now in autogen.sh the call of configure with LDFLAGS="$LDFLAGS -Wl,--as-needed" to detect such issues earlier. Don't wonder about the patches applied to lib, I've all the old debug code leftovers in lib with new style macros. Regards, Peter
В сообщении от 4 февраля 2014 01:02:47 автор Peter Bieringer написал:
Hi Nikoli,
thank you again for testing.
Am 03.02.2014 20:22, schrieb Nikoli:
but the following is not expected:
checking for MD5_Init in -lcrypto... yes checking for MD5_Init... no checking for MD5_Update... no checking for MD5_Final... no checking for MD5_Transform... no
on my Fedora system this part of configure.in works: LDFLAGS="$LDFLAGS -lcrypto" AC_CHECK_FUNCS(MD5_Init MD5_Update MD5_Final
MD5_Transform,
[ ], [
ENABLE_BUNDLED_MD5=1
])
checking for MD5_Init in -lcrypto... yes checking for MD5_Init... yes checking for MD5_Update... yes checking for MD5_Final... yes checking for MD5_Transform... yes
disabling: LDFLAGS="$LDFLAGS -lcrypto"
would show same result as yours...looks like the LDFLAGS on your systems must be set different...would be great if you can support me here.
Same CC argument order problem: it does not support --as-needed, without it configure detects md5 fine. Attached config.log without and with LDFLAGS="-Wl,-- hash-style=gnu -Wl,-O1 -Wl,--as-needed"
reproduced, configure.in fixed, please try again - also I've prepended now in autogen.sh the call of configure with
LDFLAGS="$LDFLAGS -Wl,--as-needed"
to detect such issues earlier.
Don't wonder about the patches applied to lib, I've all the old debug code leftovers in lib with new style macros.
Regards, Peter
It links to libcrypto.so.1.0.0 now :)
participants (2)
-
Nikoli
-
Peter Bieringer