Hi Sergei, On Thu, Jan 05, 2023 at 03:26:14PM +0300, Sergei Golovan wrote: > Sorry for a delay.
Thank you for following anyway and more for this level of detail! > I support the idea of dropping the libtool-bin dependency for dh-lua. Thank you! > 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. I agree with this adaption. The /usr/bin/libtool from libtool-bin does not pick up these flags either, so they are inserted elsewhere if needed. Skipping them here avoids using those flags twice. > Unfortunately, hamlib can't be fixed so easily. Something remains wrong. hamlib is a relatively simple matter. It happens to use /usr/bin/libtool for other things and was relying on dh-lua having a dependency on libtool-bin. Now that dh-lua drops it, hamlib needs to gain it directly. Once added, it builds successfully. Of course, this approach goes against the original goal of getting rid of libtool-bin, but it lets us split the problem into ever shrinking pieces. dh-lua certainly is the biggest piece left. > 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. Please go ahead. Helmut