[Pkg-openldap-devel] DEBIAN / UBUNTU OPENLDAP WILL NOT BUILD FROM SOURCE

GI Joe medic333333 at gmail.com
Sun May 22 22:18:14 UTC 2016 

pss... footnote....

The problem *may* go back to 12.04/Debian 6 or 7 or sooner ... but I don't
know for sure.  This is based on my analysis of the suspect changes
occurring since 2009.

I abandoned gnutls starting with 1404... cuz of the multitude of handshake
problems with between gnutls and non-gnutls systems with respect to TLS 1.2

I started building 'my own' non-gnutls with 14.04.

That's when I first discovered the source building problem(s)....

On Sun, May 22, 2016 at 4:04 PM, GI Joe <medic333333 at gmail.com> wrote:

> ps... I also change my dependencies in debian/control to abolish gnutls
> and enable openssl
>
> On Sun, May 22, 2016 at 4:02 PM, GI Joe <medic333333 at gmail.com> wrote:
>
>> Hello Ryan...
>>
>> To save a lot of explanation... and a "see for yourself"....
>>
>> If you can create a VM of ubuntu 14.04, 1604 OR Debian 8....
>>
>> 1) apt-get your build dependencies and build tools.
>>
>>
>> 2) apt-get source slapd.
>>
>> [edit your configure.options as you wish (FYI... I usually enable *all*
>> backends and overlays... and use tls=openssl)]
>>
>> 3) dh binary
>>
>> That SHOWS you everything you need to know.
>>
>> -----------------------------
>>
>> I've deleted out all of the overrides in debian/rules (virtually
>> everything special regarding anything in ./contrib/slapd-modules)
>>
>> I've also added blank var VERSION_OPTIONS= and GSSAPI_LIBS to
>> configure.in
>>
>> ----
>>
>> Doing all of that allows a complete compile and, as I type this msg to
>> you, it's running the tests.
>>
>>
>>
>>
>>
>> On Sun, May 22, 2016 at 2:40 PM, Ryan Tandy <ryan at nardis.ca> wrote:
>>
>>> Hi,
>>>
>>> On Sun, May 22, 2016 at 01:46:23PM -0500, GI Joe wrote:
>>>
>>>> OpenLdap will not build from source.
>>>>
>>>
>>> Well, it seems to build from source fairly reliably on both the Debian
>>> and Ubuntu build servers, but let's see if we can figure out what's
>>> different between those builders and your environment.
>>>
>>> BTW, which source version are you currently trying to build?
>>>
>>> I've had to massage it since Ubuntu 14.04.  Looks like changes were made
>>>> back in 2014 that are causing the problems.
>>>>
>>>> It's been a real PITA for the last ~3 years.
>>>>
>>>> I don't know what upstream was trying to accomplish but it APPEARS to be
>>>> somone wanted to support put gssapi stuff in for SAMBA.
>>>>
>>>> configure.in is buggered.
>>>> debian/rules is buggered.
>>>>
>>>> I have to comment out stuff.... and add new VARS to configure.in just
>>>> to
>>>> get it this far.  I usually just delete all the 'crap' out.
>>>>
>>>
>>> OK, if you're making modifications to the source (and not mentioning
>>> exactly what those modifications are), I probably won't be able to help,
>>> because I won't get the same results as you.
>>>
>>> Can you start again from an unmodified source package, show the exact
>>> commands you're running, and what happens?
>>>
>>> Regardless, compiling from source is worthless.
>>>>
>>>> Try it yourself from a 'fresh' install of 1404 or 1604 or Debian 8.
>>>> Makes
>>>> no difference.  Results are the same.
>>>>
>>>> grep these compile-time VAR culprits and search the version control
>>>> logs.
>>>> Looks like the suspect changes were made 2009.
>>>>
>>>> VERSION_OPTIONS
>>>> GSSAPI_LIBS
>>>>
>>>> ... SAMPLE CRAP...  from debian/rules...
>>>> override_dh_auto_clean:
>>>>        dh_auto_clean
>>>>        # Update translation templates for debconf
>>>>        debconf-updatepo
>>>> ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
>>>>        # Remove our stripped schema from the upstream source area.
>>>>        if [ -z "$(DFSG_NONFREE)" ]; then \
>>>>            set -e; for s in debian/schema/*.schema debian/schema/*.ldif;
>>>> do \
>>>>                rm -f servers/slapd/schema/`basename $$s`; \
>>>>            done; \
>>>>        fi
>>>>
>>>>        rm -f contrib/slapd-modules/nssov/nss-pam-ldapd/config.sub
>>>> contrib/slapd-modules/nssov/nss-pam-ldapd/config.guess
>>>>
>>>>        # Clean the contrib directory
>>>>        rm -rf contrib/slapd-modules/smbk5pwd/.libs \
>>>>                contrib/slapd-modules/smbk5pwd/smbk5pwd.lo \
>>>>                contrib/slapd-modules/smbk5pwd/smbk5pwd.la \
>>>>                contrib/slapd-modules/smbk5pwd/smbk5pwd.o
>>>>        rm -rf contrib/slapd-modules/autogroup/.libs \
>>>>                contrib/slapd-modules/autogroup/autogroup.lo \
>>>>                contrib/slapd-modules/autogroup/autogroup.la \
>>>>                contrib/slapd-modules/autogroup/autogroup.o
>>>>        rm -rf contrib/slapd-modules/lastbind/.libs \
>>>>                contrib/slapd-modules/lastbind/lastbind.lo \
>>>>                contrib/slapd-modules/lastbind/lastbind.la \
>>>>                contrib/slapd-modules/lastbind/lastbind.o
>>>>        rm -rf contrib/slapd-modules/passwd/sha2/.libs \
>>>>                contrib/slapd-modules/passwd/sha2/pw-sha2.lo \
>>>>                contrib/slapd-modules/passwd/sha2/pw-sha2.la \
>>>>                contrib/slapd-modules/passwd/sha2/pw-sha2.o
>>>> endif
>>>>
>>>
>>> OK, so your source is a reasonably recent Ubuntu package; let's assume
>>> you have 2.4.42+dfsg-2ubuntu3, or somewhere around there. And I'll assume
>>> from the shell prompt below that this is an Ubuntu 16.04 system.
>>>
>>> ONE OF MANY SAMPLES OF PROBLEMS...
>>>> -e 's%DATADIR%/usr/share/ldap%' \
>>>> -e 's%SBINDIR%/usr/sbin%' \
>>>> -e 's%BINDIR%/usr/bin%' \
>>>> -e 's%LIBDIR%/usr/lib/x86_64-linux-gnu%' \
>>>> -e 's%LIBEXECDIR%/usr/lib%' \
>>>> -e 's%MODULEDIR%/usr/lib/ldap%' \
>>>> -e 's%RELEASEDATE%2015/08/14%' \
>>>> ./$page \
>>>> | (cd .; soelim -) > $page.tmp; \
>>>> done
>>>> make[4]: Leaving directory
>>>> '/home/starnet/tmp/openldap-2.4.42+dfsg/doc/man/man8'
>>>>
>>>> make[3]: Leaving directory
>>>> '/home/starnet/tmp/openldap-2.4.42+dfsg/doc/man'
>>>>
>>>> make[2]: Leaving directory '/home/starnet/tmp/openldap-2.4.42+dfsg/doc'
>>>>
>>>> make[1]: Leaving directory '/home/starnet/tmp/openldap-2.4.42+dfsg'
>>>> /usr/bin/make -C contrib/slapd-modules/smbk5pwd
>>>> make[1]: Entering directory
>>>> '/home/starnet/tmp/openldap-2.4.42+dfsg/contrib/slapd-modules/smbk5pwd'
>>>> ../../../debian/build/libtool --mode=compile gcc -g -O2 -Wall -g -O2
>>>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
>>>> -D_FORTIFY_SOURCE=2 -DDO_KRB5 -DDO_SAMBA -DDO_SHADOW
>>>> -I../../../debian/build/include -I../../../debian/build/servers/slapd
>>>> -I../../../include -I../../../include -I../../../servers/slapd
>>>> -I/usr/include/heimdal  -c smbk5pwd.c
>>>> make[1]: ../../../debian/build/libtool: Command not found
>>>>
>>>
>>> This doesn't make a lot of sense to me, because to get through the main
>>> openldap compilation you'd have to have had debian/build/libtool. Was one
>>> of the changes you made perhaps related to the location of the build tree?
>>>
>>> Makefile:54: recipe for target 'smbk5pwd.lo' failed
>>>> make[1]: *** [smbk5pwd.lo] Error 127
>>>> make[1]: Leaving directory
>>>> '/home/starnet/tmp/openldap-2.4.42+dfsg/contrib/slapd-modules/smbk5pwd'
>>>> debian/rules:81: recipe for target 'override_dh_auto_build' failed
>>>> make: *** [override_dh_auto_build] Error 2
>>>> root at u1604svr:/home/starnet/tmp/openldap-2.4.42+dfsg# !vi
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/attachments/20160522/e4ae5515/attachment-0001.html>

More information about the Pkg-openldap-devel mailing list