I need to build httpd with mod_authnz_ldap. Having looked into it, it is apparent that in order to do so, I also need apr-util to have been built with ldap support.
/hab/cache/src/apr-util-1.6.1/include/apr_ldap.h:79:18: fatal error: lber.h: No such file or directory
What library within core will provide this, or do I need to build this too?
Furthermore, once I’ve managed to build these libraries (apr-util with ldap, and whatever it depends on) what’s the best way to ensure my plan uses these packages rather than the ones from core?
Ok there are few things here worth talking through.
Furthermore, once I’ve managed to build these libraries (apr-util with ldap, and whatever it depends on) what’s the best way to ensure my plan uses these packages rather than the ones from core?
So the first thing (the thing easiest to clear up) is that you can always build/upload packages for your personal origin which means you can always include those packages as deps in your own packages. So say your origin was called foo you would create foo/apr-util that included the appropriate flag and in the package that needed the updated apr-util you would modify your deps to look like pkg_deps=(foo/apr-util). In order to test this locally, you'll want to enter your interactive studio from a directory one step above ALL the directories for the interdependent bits of code you're planning to build.
What this looks like in practice is perhaps you have a plans dir and inside that directory each of your package definitions have their own directories, like so:
$ cd plans
$ ls plans
apr-util httpd openldap
Solving the issue of libraries not being appropriately linked might take a little more effort. Give me some time and I'll see if I can't figure out why core/openldap isn't providing the libraries to be appropriately linked.
I should get a chance to look at this this afternoon, but for starters, having looked into the openldap source code, that header file is certainly provided in the distribution used by core/openldap.
The broader question is why it’s not being found. Check the output of ./configure --with-ldap and post it here.
If you could show the plan.sh as well, that would help others to try to reproduce your issue.
EDIT: The differences in my plan vs upstream, for reproduction:
checking for ldap_init in -lldap50... no
checking for ldap_init in -lldapssl41... no
checking for ldap_init in -lldapssl40... no
checking for ldap_init in -lldapssl30... no
checking for ldap_init in -lldapssl20... no
checking for ldap_init in -lldapsdk... no
checking for ldap_init in -lldapsdk... no
checking for ldap_init in -lldap... yes
checking for ldapssl_client_init in -lldap... no
checking for ldapssl_client_deinit in -lldap... no
checking for ldapssl_add_trusted_cert in -lldap... no
checking for ldap_start_tls_s in -lldap... yes
checking for ldap_sslinit in -lldap... no
checking for ldapssl_init in -lldap... no
checking for ldapssl_install_routines in -lldap... no
setting LDADD_ldap to "-lldap -llber"
checking for ber_init in -llber... yes
checking lber.h usability... yes
checking lber.h presence... yes
checking for lber.h... yes
checking for ldap.h... yes
checking ldap_ssl.h usability... no
checking ldap_ssl.h presence... no
checking for ldap_ssl.h... no
checking for LDAP toolkit... OpenLDAP
checking style of ldap_set_rebind_proc routine... three```
I haven’t had a chance to dig into this yet. But typically when you see an underlying library that is not getting linked appropriately by a consuming package (e.g. foo/bar needs lib_baz which should be provided by foo/baz) its more often than not an issue with the build of the package being consumed (in our example foo/baz). The easiest thing it could be (and in this case i’d almost guarantee it isn’t) is that pkg_lib_dirs didn’t get set in the package being consumed.
After that, it’s an issue of making sure the linker knows those libraries exist and sometimes that means having to add some custom configuration to the build to force it to bubble those libraries up to the linker.
I’m not sure how helpful any of this is, I will also hopefully get to take a look at this later today and we can track effort here!
So looking into the generated Makefile, I could see that openldap wasn’t included. This is fixed by adding a build dependency on core/pkg-config, which seems to tie it together properly.
A make --dry-run now shows the openldap include directory on all the compile operations and all but one link operations.
I think -lldap and -llber are added to LDADD_ldap. Not sure if this is needed, as my recollection of LDADD is that it’s used in the case where you wish to link against libraries not found my ./configure. If I delete this from the makefile manually, and run make, the build completes… but make test fails, as the -lldap -llber arguments seem to reappear.
I think if I were doing this plan I’d go with option 3. However, if the intention is to contribute this back to core we should probably have a larger discussion around why the makefile isn’t working for us and look for additional underlying issues.
I think it’s a problem worth chasing down. This should definitely ‘just work’ and anyone else using this plan, and wanting to add LDAP support will expect it to ‘just work’.