Thank you for the patch!

It looks good, but when was testing it I found out that due to syslog appender calling gibc's getaddrinfo() inside getHostname() -> get_host_by_name() this cannot be fully static, are you aware of this problem?

When using syslog appender the program ends up with the below shared libraries loaded:

(gdb) i sharedlibrary 
From                To                  Syms Read   Shared Object Library
0x00007ffff5fcecd0  0x00007ffff5fddd30  Yes (*)     /lib64/libnss_myhostname.so.2
0x00007ffff5fac670  0x00007ffff5fc2c05  Yes (*)     /lib64/libgcc_s.so.1
0x00007ffff5df0700  0x00007ffff5f4655d  Yes (*)     /lib64/libc.so.6
0x00007ffff5d9a0a0  0x00007ffff5dbff25  Yes         /lib64/ld-linux-x86-64.so.2
(*): Shared library is missing debugging information.
(gdb)

The compiler complains about that:

# g++ test.cpp -llog4cplus -static -g
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/liblog4cplus.a(liblog4cplus_la-socket-unix.o): in function `log4cplus::helpers::getHostname[abi:cxx11](bool)':
(.text+0x615): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
#

Thanks for the feedback!

Indeed I'm aware that doing a full static build (full meaning: also glibc) is often problematic. Cases like you mention, but also others (ie. big overheads in system time clock readings), always point to keep at least glibc as non-static in the general community. But this applies not only to log4cplus but basically all static libs which use certain glibc calls (and some are pretty much unavoidable if you do some networking, like the case you mention).

This is actually what we do in our "semi-embedded" project (so link everything except glibc statically, while having to take care that a suitable glibc, ie with compatible set of GLIBC symbols, is on the running system) , which minimizes dependency of the runtime to glibc only. (which requires on the build step a little more handling, ie. with -Wl,-Bstatic' / -Wl,-Bdynamic' chunks)

Of course if you feel that packaging also the static part may bring you hassles, I understand if you'd prefer not to proceed in case with the merge, but I'd consider the availability of this as static to be "problem wise" on par with most other -static packages in Fedora.

Many thanks!
Federico

No hassles at all, you are right. Thank you for sharing the background info and again for the patch! Merging.

Only for reference, the follow-up fix is needed for this merge request. F36, F37, and Rawhide don't complain about anything. Only f35 revealed bash doesn't support one element inside {}:

https://src.fedoraproject.org/rpms/log4cplus/c/7194dd9446d04e0836b22f54bceef2fb72a6ebf6?branch=rawhide

Many thanks for the heads up, good to keep in mind :)

Many thanks again also for the merge!