While I was trying to build OpenLDAP 2.6 on Fedora Rawhide I've got the error message: /usr/bin/ld: ./.libs/libldap.so: undefined reference to `ber_sockbuf_io_udp' I've checked commits from https://bugs.openldap.org/show_bug.cgi?id=9673 and found that 'ber_sockbuf_io_udp' was not added to https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblber/lber.map I've asked on the project's mailing list and got a reply: "That symbol only exists if OpenLDAP is built with LDAP_CONNECTIONLESS defined, which is not a supported feature. Feel free to file a bug report at https://bugs.openldap.org/" https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/thread/2CLWO4DN5N73FUWHTHUWY2D6RED6VUX3/ Hence, creating the bug.
Need to decide how to handle this case in general as there may be other features hidden behind defines. Should the map file simply declare every possible symbol regardless of whether it is available?
We have a number of public symbols that are present depending on whether a macro is set, there seem to be three main types to consider: 1. those that depend on what we (don't) build with - tls seems to be fine and sasl probably too, so long as noone inspects _pvt.h headers. But our own tools do just that 2. LDAP_CONNECTIONLESS which is set at build time by us (and potentially LDAP_DEPRECATED if we decide to remove them) 3. features (ppolicy, paged results, ...) which we should expose once (updating our library version) and never hide again 3. is easy to manage, 1. we should be able to pull off since we're also in good place for that. We have broken ABI from our historical libldap.so.2 by removing some of the LDAP_CONNECTIONLESS symbols (ldap_is_ldapc_url is gone) and we might need to expose them again or bump our ABI to libldap/liblber.so.3.
Since the symbol in question is part of an unsupported feature, only built when the unsupported LDAP_CONNECTIONLESS flag is defined, we will not be adding it to the officially released library map files. If you want to add unsupported features to your builds, then you'll be responsible for tweaking your map files appropriately to make those unsupported features visible in your builds. Thanks for bringing this to our attention and giving us the opportunity to clarify the Project policy on the matter. This ticket will now be closed.
*** Issue 9771 has been marked as a duplicate of this issue. ***