[Bug 207687] [patch] sysutils/am-utils LDAP + gdbm_compat

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207687

            Bug ID: 207687
           Summary: [patch] sysutils/am-utils LDAP + gdbm_compat
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Keywords: patch
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: freebsd-ports-bugs at FreeBSD.org
          Reporter: beastie at tardisi.com
          Keywords: patch

Created attachment 167699
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=167699&action=edit
patch

I ran into the same problem that was encountered in bug #201140.  Kind of
disappointing that it was just closed without a fix...

The original submitter started the change by switching to using
"OPENLDAP_CONFIGURE_WITH", but didn't know how to complete the conversion of
the other options.

My patch starts by completing this work.  After which I delved into why it was
a problem.

The issue comes from having installed 'databases/gdbm' with COMPAT (not
default) option set.  Where setting ldflags and cppflags so that configure can
find the openldap-client port, causes its ndbm check to stumble if gdbm/ndbm is
installed.  It doesn't correctly handle where it finds 'ndbm.h', in
/usr/local/include from gdbm, and the dbm_open function is in libc.  It has a
check to look for dbm_pagfno to see if ndbm.h came from gdbm, but this section
doesn't reference -lgdbm_compat.  And, its testing if the library is -lndbm. 
But, when its checking if 'dbm_open' is in 'libc', it doesn't check if
gdbm/ndbm is in play.

I added a patch to configure.ac to address this.

While the section in 'configure' that does check for '-lgdbm_compat' is based
on Debian and the header file being named 'gdbm-ndbm.h'.

Of course, the port builds fine in poudriere, because the build jail won't have
gdbm installed.  And, poudriere is how I would build the port if I had decided
to deploy it.

As it is, I'm not going to use this, since it doesn't do NFSv4 on FreeBSD (it
only does Linux, and after a couple of days I had enough of trying to figure
things out...I've decided I didn't need it anyways.  (only doing NFSv4 from
FreeBSD to OSX, can stay with NFSv3 for Linux to FreeBSD.   OSX runs its own
Dropbox, only FreeBSD needs to mount the share from Linux.)

-- 
You are receiving this mail because:
You are the assignee for the bug.