<div dir="ltr">Something of note: On your last comment about VERSION_OPTION.<div><br></div><div>VERSION_OPTION is defined in <a href="http://top.mk">top.mk</a>. However, in the libraries tree straight from umich.edu... they don't include the Debian build <a href="http://top.mk">top.mk</a>.</div><div><br></div><div>Hence, I think that's the main issue with the {VARS} in the Debian tradition.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 22, 2016 at 10:19 PM, GI Joe <span dir="ltr"><<a href="mailto:medic333333@gmail.com" target="_blank">medic333333@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">:)<div><br></div><div>Noted your above and will let you know how it comes out or if I find anything else.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 22, 2016 at 10:11 PM, Ryan Tandy <span dir="ltr"><<a href="mailto:ryan@nardis.ca" target="_blank">ryan@nardis.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, May 22, 2016 at 09:14:16PM -0500, GI Joe wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
---->>>[OK. Why? Is this to work around the contrib modules (specifically<br>
smbk5pwd) being set up to build with gnutls, while you're building with<br>
openssl?]<br>
<br>
Just testing... as I was saying... it appears that the problems originate<br>
around all of that gssapi/samba stuff inserted circa 2009. IMHO, It<br>
should still be able to compile, test, install properly no matter what<br>
libraries are finally linked. (Try Redhat/Centos)<br>
</blockquote>
<br>
It does, for the components that are integrated in the autoconf build system, but the contrib modules are driven just by simple Makefiles, so do need some tweaking to ensure the proper flags are set.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
---->>>[(I was expecting a 'dch --local', or some other edit to<br>
debian/changelog, at this point, to distinguish your package from the<br>
archive version...)]<br>
<br>
Not yet. Don't need to since I'm doing this as prep work before rolling<br>
out a 'final edition'. Gotta be able to install and run it, first. THEN<br>
build debs.<br>
</blockquote>
<br>
OK.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
---->>>[dh binary --with autoreconf<br>
--builddirectory=/.../openldap-2.4.42+dfsg/debian/build<br>
--parallel]<br>
<br>
Same thing. dh executes to install target on "binary." Builddirectory is<br>
resolved in debian/rules as the same thing at line 34...<br>
builddir := $(CURDIR)/debian/build<br>
</blockquote>
<br>
Not the same, trivially demonstrated:<br>
<br>
dh binary<br>
<br>
executes ./configure in the current directory, creating ./config.log.<br>
<br>
dh binary --builddirectory=$(pwd)/debian/build<br>
<br>
cd's into debian/build and executes ../../configure, creating debian/build/config.log.<br>
<br>
And that does matter, as evidenced by your earlier quotes of things failing to find debian/build/libtool.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Autoreconf usually unnecessary too when working with a virgin source tree<br>
or after a clean.<br>
</blockquote>
<br>
Yes, if we were building unmodified upstream sources: but in this case, you're missing out on changes made to <a href="http://configure.in" rel="noreferrer" target="_blank">configure.in</a> by any Debian patches, of which there are several. Notably, some of the patches change or add other functionality _and_ change the build system to make it all work; so if you still have those packages included but you're not doing autoreconf, then yes, it's quite likely to break.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
---->>>[ Missing '--with autoreconf' might explain why you find yourself<br>
having to edit <a href="http://configure.in" rel="noreferrer" target="_blank">configure.in</a>, while missing --builddirectory would explain<br>
the error about missing libtool I remarked on earlier. ]<br>
<br>
Not. The vars were undefined in [context]. (Yes, I realize that's kinda<br>
vague... but, I went thru that hours ago) See below.<br>
....<br>
<br>
fakeroot dpkg-buildpackage comes after I know this thing is going to<br>
install and execute and pass a couple hundred tests.<br>
</blockquote>
<br>
For faster iterations during development:<br>
<br>
export DEB_BUILD_OPTIONS=nocheck<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
---->>> 'dpkg-buildpackage -us -uc -b' does succeed for me, though, with no<br>
changes at all to the package. So maybe try using that instead?]<br>
<br>
Try running an ldapsearch -ZZ resulting in TLS 1.2 from Debian/GnuTLS to<br>
about 2000 other openldap servers running on Redhat or CentOS and you'll<br>
understand pretty quick. Try adding a few more overlays and backends, too.<br>
</blockquote>
<br>
I don't understand how this is related to the dpkg-buildpackage suggestion, sorry.<br>
<br>
I said "with no changes to the package" because that's how I'm testing it. I'd make sure you're calling the right commands to build the source unmodified first, then change GnuTLS to OpenSSL. I wouldn't expect further changes to be necessary.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(BELOW: After my changes)<br>
<br>
build/top.mk:VERSION_OPTION = @VERSION_OPTION@<br>
<<<<-------------------------------<br>
</blockquote>
<br>
Looks like the VERSION_OPTION stuff is related to debian/patches/libldap-symbol-versions, which touches... <a href="http://configure.in" rel="noreferrer" target="_blank">configure.in</a>. So yes, I'd expect to run into breakage with that patch applied but not running autoreconf.<br>
<br>
And your GSSAPI_LIBS problem probably has two parts... the first is also autoreconf-related (since the gssapi patch also modifies the build system), and the second is fixed by running dpkg-buildpackage instead of debian/rules directly, which _shouldn't_ be necessary, but apparently is with the current xenial package. Next time I touch the Ubuntu package I'll look into that and try to fix it.<br>
</blockquote></div><br></div>
</blockquote></div><br></div>