Linux nanomsg static link error and warning

[363568233]

[root@49 nanomsg_test]# g++ 1.c -static -lnanomsg -lpthread
//usr/local/lib64/libnanomsg.a(dns.c.o): In function nn_dns_start': dns.c:(.text+0x4e7): undefined reference to getaddrinfo_a'
//usr/local/lib64/libnanomsg.a(dns.c.o): In function nn_dns_notify': dns.c:(.text+0x5b3): undefined reference to gai_error'
//usr/local/lib64/libnanomsg.a(dns.c.o): In function nn_dns_shutdown': dns.c:(.text+0x76b): undefined reference to gai_cancel'

so g++ 1.c -static -lnanomsg -lpthread -lanl
/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/libanl.a(gai_misc.o): In function `handle_requests':
(.text+0x3d): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

Is this warning negligible?? I don't know how to deal with it.

[363568233]

I want to compile my exe link static library all. Because I would run it in different versions of GCC

[363568233]

I find a explanation:
glibc uses libnss to support a number of different providers for address resolution services. Unfortunately, you cannot statically link libnss, as exactly what providers it loads depends on the local system's configuration.

[gdamore]

I think we should find a way configure without asynch resolver. Pretty sure that is a cmake variable but its been a while since I have looked at it.

…

On Wed, Nov 14, 2018, 1:56 AM Eric ***@***.***> wrote: I find a explanation: glibc uses libnss to support a number of different providers for address resolution services. Unfortunately, you cannot statically link libnss, as exactly what providers it loads depends on the local system's configuration. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1004 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPDfdlFsxAwKFgRNQNm31n_ZSUEhVqEks5uu-jqgaJpZM4YdWXn> .

[gdamore]

Try building with cmake -DNN_ENABLE_GETADDRINFO_A=OFF

That should fix it for you.

Note that NNG does not have this issue.

[gdamore]

"Long term", a good fix would probably be to disable this function if NN_STATIC_LIB is set.

This can be done with just changes to the top-level CMakeLists.txt I think. Basically we can make enabling this capability conditional upon that. If you want to submit a PR for this I'd be happy to review it. It's not particularly high priority for me at this point (to do myself).

[gdamore]

Actually, review this, the warning is correct. If you're building static, you need to be aware that you still have a dynamic dependency due to libnss. There's really nothing else I can do about it. You can ignore the warning if you're going to run your program on the target system.

Alternatively, if you want to be pure static without this dependency, use that cmake flag to disable the use of the asynchronous resolver. (It would be a mistake for me to automatically do this I think. You need to just pay attention to the warning.)