Created attachment 192569 [details] kronosnet.shar Kronosnet, often referred to as knet, is a network abstraction layer designed for High Availability use cases, where redundancy, security, fault tolerance and fast fail-over are the core requirements.
Hi: according kronosnet's release page (https://github.com/kronosnet/kronosnet/releases) v1.90 is a very strange version, how about upgrade to v1.3, it's a latest version of kronosnet thanks.
Created attachment 193123 [details] kronosnet-1.3.shar Not sure why but they went backwards with their tags. 1.2 and 1.3 were tagged after 1.90.
A commit references this bug: Author: vanilla Date: Mon May 7 04:26:21 UTC 2018 New revision: 469262 URL: https://svnweb.freebsd.org/changeset/ports/469262 Log: Add kronosnet 1.3, network abstraction layer designed for high availability. PR: 227564 Submitted by: David Shane Holden <dpejesh@yahoo.com> Changes: head/devel/Makefile head/devel/kronosnet/ head/devel/kronosnet/Makefile head/devel/kronosnet/distinfo head/devel/kronosnet/files/ head/devel/kronosnet/files/extra-patch-ssl-base-configure.ac head/devel/kronosnet/files/extra-patch-ssl-libressl-configure.ac head/devel/kronosnet/files/patch-Makefile.am head/devel/kronosnet/files/patch-man_Makefile.am head/devel/kronosnet/pkg-descr head/devel/kronosnet/pkg-message head/devel/kronosnet/pkg-plist
The libqb dependency should be on libqb.so.0 with the update patch in 227563, which is why I set this bug to depend on it. libqb.so was changed to a linker script so the ports build system will not correctly recognize it as a library after the libqb update to 1.0.3. For a more detailed explanation refer to https://github.com/ClusterLabs/libqb/commit/20246f544f74866885f4d9491f74152bd95e7786.
I try to build pacemaker with libqb 1.0.2, and upgrade libqp 1.0.3, everything seems fine on my box, is is really necessary?
If you've applied the libqb-1.0.3 patch in its entirety then corosync/pacemaker will build just fine because the patch updates the ports accordingly. But if you apply the libqb-1.0.3 patch and try to build kronosnet again it will fail with... ===> kronosnet-1.3 depends on shared library: libqb.so - not found If you look at the libqb.so file you'll see that it's not a typical shared object but instead a linker script which the ports build system fails to recognize and why it needs to depend on libqb.so.0. # cat /usr/local/lib/libqb.so INPUT(libqb.so.0) /* GNU ld script This atypical arrangement enforces global visibility of boundary symbols (QB_ATTR_SECTION_START, QB_ATTR_SECTION_STOP) for the custom section QB_ATTR_SECTION used for compile-time offloading of the logging call sites tracking. While libqb relies on these being global, default linker from binutils change the visibility as of version 2.29, making the logging unusable without artificial stimulus: https://bugzilla.redhat.com/1477354 NOTE: If -lqb not usable for linking (e.g. linker not compatible with linker scripts ad-hoc modifying output sections), try recent ld.bfd/binutils linker first when available, otherwise you can try "-l:libqb.so.0" link switch that bypasses said linker script -- but beware, logging may be less efficient and may lack possible future optimizations and extra features. Consequently, logging issues (typically bound to QB_LOG_INIT_DATA macro) can be mitigated with QB_KILL_ATTRIBUTE_SECTION macro defined for a build. NOTE: When concerned about a warning coming from the build process like warning: [...]libqb.so contains output sections; did you forget -T? while it finishes OK, consider it merely a harmless side-effect. */ SECTIONS { __verbose : { __start___verbose = .; *(__verbose); __stop___verbose = .; } }
Hmm. Can we just make libgb.so as symbolic link? If it's a symbolic link, everything seems fine.
Short answer: no. Long answer: it's all described in the github commit link in great detail. The gist of it is libqb was depending on behavior of the binutils linker that was changed in 2.29 and to work around it they've changed libqb.so to a linker script. Changing it back to a soft-link does nothing but break the solution they've put in place to work around a regression in binutils. USES=ncurses does exactly the same thing with its dependencies, I'm assuming for the same reason. The ports build system doesn't correctly recognize linker scripts. $ grep -e ^BUILD_DEPENDS /usr/ports/Mk/Uses/ncurses.mk BUILD_DEPENDS+= ${LOCALBASE}/lib/libncurses.so.${NCURSES_SHLIBVER}:${NCURSES_PORT} $ cat /usr/local/lib/libncurses.so INPUT(libncurses.so.6.0 AS_NEEDED(-ltinfo))
ok, it make sense to me, I will commit devel/libqb soon. thanks.
A commit references this bug: Author: vanilla Date: Sat May 12 03:26:59 UTC 2018 New revision: 469705 URL: https://svnweb.freebsd.org/changeset/ports/469705 Log: Add libqb.so's version number, and bump version. PR: 227564 Submitted by: maintainer Changes: head/devel/kronosnet/Makefile
Hi David, I am Fabio, kronosnet upstream developer. First I´d like to thanks you for packaging knet in FreeBSD. We really care a lot about portability and we try our best to support FBSD. Please reach out to me at any time if you need any help or you discover any issue. As for the v1.90 tag referenced in one comment here, 1.90 is on the master branch and v1.x (< 1.90) are on the stable1 branch. It is an artifact that allows to continue building rpm´s from master branch with a higher version of stable1 branch. See also https://ci.kronosnet.org for those jobs. I would also strongly recommend to update to the latest stable release of knet 1.7. Not sure about the FBSD processes on this matter, perhaps a new bug is required? Thanks Fabio