Cannot build c-ares 1.24 on OpenBSD

[brad0]

Building c-ares 1.24.0 fails to build on OpenBSD.

Our current port is at 1.19.1.

I can build 1.20.1, 1.21.0, 1.22.1, and 1.23.0 just fine.

/usr/bin/libtool  --tag=CXX    --mode=link c++ -std=c++14 -I/usr/local/include -DGTEST_HAS_PTHREAD=1  -O2 -pipe -pthread -Wall -pthread   -o arestest arestest-ares-test-main.o  arestest-ares-test-init.o arestest-ares-test.o  arestest-ares-test-ns.o  arestest-ares-test-parse.o  arestest-ares-test-parse-a.o  arestest-ares-test-parse-aaaa.o  arestest-ares-test-parse-caa.o  arestest-ares-test-parse-mx.o  arestest-ares-test-parse-naptr.o  arestest-ares-test-parse-ns.o  arestest-ares-test-parse-ptr.o  arestest-ares-test-parse-soa.o  arestest-ares-test-parse-soa-any.o  arestest-ares-test-parse-srv.o  arestest-ares-test-parse-txt.o  arestest-ares-test-parse-uri.o  arestest-ares-test-misc.o  arestest-ares-test-live.o  arestest-ares-test-mock.o  arestest-ares-test-mock-ai.o  arestest-ares-test-internal.o  arestest-dns-proto.o arestest-dns-proto-test.o  -L/usr/local/lib -lgmock -lgtest -lpthread ./../src/lib/libcares.la -lpthread  -lpthread
libtool: link: c++ -o .libs/arestest -pthread -std=c++14 -I/usr/local/include -DGTEST_HAS_PTHREAD=1 -O2 -pipe -Wall arestest-ares-test-main.o arestest-ares-test-init.o arestest-ares-test.o arestest-ares-test-ns.o arestest-ares-test-parse.o arestest-ares-test-parse-a.o arestest-ares-test-parse-aaaa.o arestest-ares-test-parse-caa.o arestest-ares-test-parse-mx.o arestest-ares-test-parse-naptr.o arestest-ares-test-parse-ns.o arestest-ares-test-parse-ptr.o arestest-ares-test-parse-soa.o arestest-ares-test-parse-soa-any.o arestest-ares-test-parse-srv.o arestest-ares-test-parse-txt.o arestest-ares-test-parse-uri.o arestest-ares-test-misc.o arestest-ares-test-live.o arestest-ares-test-mock.o arestest-ares-test-mock-ai.o arestest-ares-test-internal.o arestest-dns-proto.o arestest-dns-proto-test.o -L.libs -lgmock -lgtest -lpthread -lc++ -lc++abi -lm -lcares -Wl,-rpath-link,/usr/local/lib
ares-test.cc(arestest-ares-test.o:(ares::test::TempNam(char const*, char const*))): warning: tempnam() possibly used unsafely; consider using mkstemp()
ld: error: undefined symbol: ares__tvnow
>>> referenced by ares-test.cc
>>>               arestest-ares-test.o:(ares::test::ProcessWork(ares_channeldata*, std::__1::function<std::__1::set<int, std::__1::less<int>, std::__1::allocator<int>> ()>, std::__1::function<void (int)>, unsigned int))
>>> referenced by ares-test.cc
>>>               arestest-ares-test.o:(ares::test::ProcessWork(ares_channeldata*, std::__1::function<std::__1::set<int, std::__1::less<int>, std::__1::allocator<int>> ()>, std::__1::function<void (int)>, unsigned int))
>>> referenced by ares-test.cc
>>>               arestest-ares-test.o:(ares::test::ProcessWork(ares_channeldata*, std::__1::function<std::__1::set<int, std::__1::less<int>, std::__1::allocator<int>> ()>, std::__1::function<void (int)>, unsigned int))

ld: error: undefined symbol: ares__timeval_remaining
>>> referenced by ares-test.cc
>>>               arestest-ares-test.o:(ares::test::ProcessWork(ares_channeldata*, std::__1::function<std::__1::set<int, std::__1::less<int>, std::__1::allocator<int>> ()>, std::__1::function<void (int)>, unsigned int))
c++: error: linker command failed with exit code 1 (use -v to see invocation)

[bradh352]

I'm assuming your library is being built with symbol hiding, and a new test case wasn't protected by ifdefs. Please try commit 7dd384a and see if it resolves your issue.

[bradh352]

I just added some ci builds to hide symbol visibility and run tests so issues like this won't crop up in the future. I also confirmed what you saw with hidden symbols so I'm closing this as resolved.

[brad0]

I'm assuming your library is being built with symbol hiding, and a new test case wasn't protected by ifdefs. Please try commit 7dd384a and see if it resolves your issue.

According to autoconf output that is the case. I mean we're not doing anything special, just ./configure. The diff commited does resolve the build issue. Thank you.

Why would there be a difference between autoconf and CMake for the default behavior? Not that this is the first time I have ever seen any such differences between multiple build systems.

[bradh352]

I think both autotools and cmake would have the same issue. However, if you built both the shared and static library its likely the issue wouldn't present itself as the tests would then be linked to the static library (or at least that's the case on cmake, possibly autotools always uses the shared library, I haven't actually checked).

That said, I would recommend cmake these days in general.

[brad0]

I think both autotools and cmake would have the same issue. However, if you built both the shared and static library its likely the issue wouldn't present itself as the tests would then be linked to the static library (or at least that's the case on cmake, possibly autotools always uses the shared library, I haven't actually checked).

That said, I would recommend cmake these days in general.

I would expect both would have the same issue if built with the same setting being it was in the C++ code itself. It was more about the default being different between the two.

Ah, I enabled the static library just now to match up with our autotools build.

Yes, I decided to convert the port over to CMake, which I do most of the time if the CMake bits are not buggy.

Although I notice the name changes.

-@static-lib lib/libcares.a
+@static-lib lib/libcares_static.a