[pkg-lua-devel] Bug#1024721: Bug#1024721: dh-lua: stop using libtool-bin

[Sergei Golovan]

Hi Helmut,

Sorry for a delay.

On Wed, Nov 23, 2022 at 11:09 PM Helmut Grohne <helmut at subdivi.de> wrote:
>
> I would like to delete the libtool-bin package. The next paragraph
> explains why. You may skip it if you don't care.

I support the idea of dropping the libtool-bin dependency for dh-lua.

>
> I've come up with a patch that creates a libtool when needed in
> debian/.dh_lua-libtool. With this patch applied, I can drop the
> libtool-bin dependency. I've done a test build of lua-geoip using this
> the patched dh-lua and see that it builds successfully without pulling
> the libtool-bin package.
>
> So I went ahead and used ratt to check for possible failures in those
> 103 reverse dependencies and found the following failures:
>  - axtls is broken by my patch, because it injects -laxtls into compiler
>    flags picked up by configure.
>  - elektra #956949
>  - hamlib is broken by my patch, because it injects a non-existent
>    object file into compiler flags picked up by configure.
>  - libguestfs FTBFS on buildds
>  - lua-apr #935271
>  - lua-cyrussasl is broken by my patch, because it injects shell code
>    into compiler flags picked up by configure and configure passes that
>    code to the compiler verbatim.
>  - lua-zip is broken by my patch, because it injects shell code
>    into compiler flags picked up by configure and configure passes that
>    code to the compiler verbatim.
>  - luasocket is broken by my patch, because of a quoting issue in the
>    generated configure arising from LTCFGFLAGS containing quotes.
>  - neomutt #1023767
>  - rrdtool is broken by my patch, because it injects -lrrd into compiler
>    flags picked up by configure.

As far as I can see, the common problem with the patch is that it picks the
CFLAGS and LDFLAGS environment variables (created by the make tool
from CLIB_CFLAGS and CLIB_LDFLAGS, which are set in the dh-lib.conf).

These variables are used in an additional call of dh_auto_configure
which is necessary
to generate the libtool binary.

But are these variables necessary in this dh_auto_configure call? Maybe we can
just clear them before the call?

I've tried to use
$(H)dh_auto_configure --buildsystem=autoconf
--sourcedirectory=$(LBTL_DIR) -- "CFLAGS='' LDFLAGS=''
LDFLAGS_STATIC=''
and got almost all the broken builds succeed (the nested
dh_auto_configure sees the cleared variables, after that the newly
created
libtool builds the library just fine). One exception is hamlib. It
remains broken, I can't figure out what's wrong.

>
> So applying this patch would make six additional packages FTBFS. Of
> those, axtls and rrdtool try adding their library via CLIB_LDFLAGS. Both
> of them use a relative path with -L, which becomes invalid in configure.
> Adding $(CURDIR) may be a way to go here. hamlib could likewise prefix

Unfortunately, hamlib can't be fixed so easily. Something remains wrong.

> its object file with $(CURDIR). cyrus-sasl should use $(shell ...)
> instead of $$(...) to perform the shell evaluation. Likewise, lua-zip
> should use $(shell ...) in place of `...`. Finally, luasocket is
> difficult. Getting the quoting through the flags seems next to
> impossible, so I'd suggest moving the affected macros to a file and pass
> an -include flag via CFLAGS.
>
> Does this sound like we can move forward with this patch? I know it is
> not of the "it just works" kind.

After adding the clearing of CFLAGS and LDFLAGS the patch "almost
doesn't break anything". If we figure out how to fix the hamlib build,
I'll gladly apply the changes in the next upload.

Cheers!
-- 
Sergei Golovan