ibgnutls.so: undefined reference to `idn2_punycode_decode'

[aubi1kenobi]

_libgnutls.so: undefined reference to `idn2_punycode_decode'

Yum says: Package libidn-1.28-4.el7.x86_64 already installed and latest version Package libidn2-2.3.0-1.el7.x86_64 already installed and latest version

rpm -qa | grep gnutls gnutls-dane-3.3.29-9.el7_6.x86_64 gnutls-3.3.29-9.el7_6.x86_64 gnutls-c++-3.3.29-9.el7_6.x86_64 gnutls-devel-3.3.29-9.el7_6.x86_64

Need your help please. Going past 3.5 weeks, just trying to get this to build so I can finally get to develop my application using your platform.

[nyh]

What is "_libgnutls.so" with an underscore? Looking at "nm -D /usr/lib64/libidn2.so.0" (I have the saem version as you, libidn2-2.3.0), I see 0000000000004d50 T _idn2_punycode_decode 00000000000049f0 T _idn2_punycode_encode But not a version without an underscore. It looks like the problem is that you have an older version of gnutls, which needs a symbol which the newer libidn no longer provides. Did you try to update your system repositories? I see this same issue in el6, https://bugzilla.redhat.com/show_bug.cgi?id=1683812 - was solved by updating gnutls. el7 probably did the same?

[aubi1kenobi]

Thank you for your reply, I started to lose hope. The underscore was a typo, I believe.

What version of gnutils did you update to, and any chance of providing the link. However,

To move on I downloaded the latest gnutls source under the "ingredients" directory, same for boost and yaml-cpp. The Gang of 3 that always give me trouble. The configure went on to the end but with the following Errors.

_FAILED: _cooking/ingredient/yaml-cpp/stamp/ingredientyaml-cpp-build /usr/local/include/boost/mpl/next_prior.hpp:29:8: note: ‘boost::mpl::next’ struct next ^~~~ gmake[2]: [CMakeFiles/yaml-cpp.dir/src/convert.cpp.o] Error 1 gmake[1]: [CMakeFiles/yaml-cpp.dir/all] Error 2

And it could not build with these two errors

[nyh]

To move on I downloaded the latest gnutls source under the "ingredients" directory, same for boost and yaml-cpp. The Gang of 3 that always give me trouble. The configure went on to the end but with the following Errors.

_FAILED: _cooking/ingredient/yaml-cpp/stamp/ingredientyaml-cpp-build /usr/local/include/boost/mpl/next_prior.hpp:29:8: note: ‘boost::mpl::next’ struct next ^~~~ gmake[2]: [CMakeFiles/yaml-cpp.dir/src/convert.cpp.o] Error 1 gmake[1]: [CMakeFiles/yaml-cpp.dir/all] Error 2

And it could not build with these two errors

I have lost track of what versions of what you are using, and why, sorry. Why do you need to build your own yaml-cpp, but use boost from /usr/local/include and not cooking/? Is the random version of yaml-cpp chosen cooking_recipe.cmake really the one we want* to use? Note that nobody is really using "cooking", so if it has errors or out-of-date versions, I wouldn't be suprised.

Maybe instead of doing all this work which I can't really follow or use "cooking" (which I think you are the only one using), you can trying getting a modern Linux distribution, for example Fedora 32 (what I personally use) - but instead of replacing your OS which you probably don't want to do, just run Fedora 32 as a docker image. In that docker image run install-dependencies.sh which will just get all the dependencies from you from the Fedora 32 repository, and then you can build in that docker image, with no mess and no need to build your own tool.

I have to say I share your frustration. When I started developing on Unix and Linux many years ago, it was common for projects to support compilation on a large number of wildly-different Unix variants, and many years worth of compiler and library evolution - using various ifdefs, autoconf and a bunch of other nice tricks to get the same code to build on many different systems. This project clearly doesn't have this philosophy - for better and for worse.

[aubi1kenobi]

Thanks mate,

I appreciate your support. I have 3 servers. A production server, a UAT and Dev server. All running CentOS 7. That choice of OS is driven by our production application which uses 3rd party commercial apis. All productions servers, in the business that we are in, run RHEL/CentOS, no one runs anything else. Hence the reason why all vendors only support RHEL/CentOS. I have never come across any serious business (where high performance is required) running Ubuntu; so it beats the heck out of me why that will be chosen as the de-facto OS.

The idea is/was to use Seastar to improve our prod application performance. So, it can only be CentOS or nothing at all.

Re: Cooking. Frankly, every time I download and run the configure.py, I get different errors every time. Configure.py doesn't get me far at all. Cooking has been the only thing giving some sort of hope of getting somewhere, but it always ends with the same sort of disappointments and increasing frustrations.

The versions are all over the place, same with the "docs", which by the way never mention the version being referred to.

It has been an utterly waste of time. To add to injury, support has been scarce, to say the least (I'm being generous).

Cheers,

[nyh]

All productions servers, in the business that we are in, run RHEL/CentOS, no one runs anything else. Hence the reason why all vendors only support RHEL/CentOS. I have never come across any serious business (where high performance is required) running Ubuntu; so it beats the heck out of me why that will be chosen as the de-facto OS.

Most Seastar developers that I know don't use Ubuntu - we use Fedora, which is similar to CentOS just newer. I don't know if anyone has been building using CentOS. In any case, Seastar uses a lot of cutting-edge compiler features, and libraries, which for obvious don't exist on old distros, so if you insist on building on those you'll either need to install a lot of things manually (this what "cooking" aimed to automate) or, and this is what we in ScyllaDB usually do: Build on a recent distribution (e.g., Fedora 32), often just a docker image, and run on whatever the clients have (including old CentOS). Yes, you can build on one distro and run on a different one - if you copy the shared libraries together with the executable.

[aubi1kenobi]

I really appreciate your support.

I gave it it go, installed fedora32 in a docker container, installed Seastar, without a hick. Build the hello example, all smootha nd no complains.

Now the million dollar question, how do I bring that CentOS? I tried the following:

• Run the hello in centos: Got missing libsXXX.so (to be expected)

• I can painfully, build every missing lib in centos, but I have no idea where and when those missing deps might show their head again --> Risky and time consuming

• Thinking of copying the 'built' seastar files to centos --> Deps issues still more likely. But this is prefered, as I can now continue my dev on centos8. if, and only if, there is no blocking item lurking around the corner.

IS fedora (32) binary compatible with any of the centos 7 ore 8?

• Performance is not great (fedora32), but so is the case with centos7, which I'm currently using
• Can I copy my centos binaries to fedora(32 or 33 now)? Couldn't get any sense of binary compatibility from the net (too much blah blah, and beating around the bush). I know ther will be few (hoping) libs deps issues, but these can be fixed (up stream should be easier).

Any idea? This will dictate cost effective (time included) direction to chose for a Seastar solution in my project. I'm already getting a new prod server, so it might be good timing to switch to Fedora (32), unless binary compatibility isn't an issue OR good prod performance (bare metal). Good means (very good, relative to the most use-cases).

Again, cheers mate. Really appreciate. Obi