Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1198182 > unrolled thread

Bug#1071581: dialog: stop using libtool-bin

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1071581: dialog: stop using libtool-bin Helmut Grohne <helmut@subdivi.de> - 2024-05-21 16:10 +0200
    Bug#1071581: dialog: stop using libtool-bin Thomas Dickey <dickey@his.com> - 2024-05-21 21:20 +0200
      Bug#1071581: dialog: stop using libtool-bin Helmut Grohne <helmut@subdivi.de> - 2024-05-22 08:20 +0200
        Bug#1071581: dialog: stop using libtool-bin Thomas Dickey <dickey@his.com> - 2024-05-22 10:10 +0200
    Bug#1071581: dialog: stop using libtool-bin Helmut Grohne <helmut@subdivi.de> - 2024-05-22 15:30 +0200
      Bug#1071581: dialog: stop using libtool-bin Thomas Dickey <dickey@his.com> - 2024-05-23 10:40 +0200

#1198182 — Bug#1071581: dialog: stop using libtool-bin

[Multipart message — attachments visible in raw view] — view raw

Source: dialog
Version: 1.3-20240307-2
Severity: normal
Tags: patch
User: debian-cross@lists.debian.org
Usertags: cross-satisfiability

Hi Santiago,

we want to remove the package libtool-bin from the archive, because any
attempt of using it breaks cross compilation. The dialog package is a
bit strange in this regard. It's autoconf stuff attempts to detect
whether there is a libtool.m4 and when there isn't attempts to use a
pre-configured libtool (the one from libtool-bin). Unfortunately, last
time it was autoreconf'ed, that happened without libtool.m4. So
basically, making libtool-bin go away here amounts to autoreconfing
dialog after libtoolizing it. And that's pretty much what I did in the
attached patch. The dialog binary and libdialog.la are bit-identical
with this change.

Helmut

[toc] | [next] | [standalone]

#1198203

[Multipart message — attachments visible in raw view] — view raw

On Tue, May 21, 2024 at 04:00:56PM +0200, Helmut Grohne wrote:
> Source: dialog
> Version: 1.3-20240307-2
> Severity: normal
> Tags: patch
> User: debian-cross@lists.debian.org
> Usertags: cross-satisfiability
> 
> Hi Santiago,
> 
> we want to remove the package libtool-bin from the archive, because any
> attempt of using it breaks cross compilation. The dialog package is a
> bit strange in this regard. It's autoconf stuff attempts to detect
> whether there is a libtool.m4 and when there isn't attempts to use a
> pre-configured libtool (the one from libtool-bin). Unfortunately, last
> time it was autoreconf'ed, that happened without libtool.m4. So
> basically, making libtool-bin go away here amounts to autoreconfing
> dialog after libtoolizing it. And that's pretty much what I did in the
> attached patch. The dialog binary and libdialog.la are bit-identical
> with this change.

hmm - there are two sets of changes - I don't see a reason for the
change to the curses function checks.

(as for libtool - I recall commenting on that, recently)

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

[toc] | [prev] | [next] | [standalone]

#1198233

Hi Thomas,

On Tue, May 21, 2024 at 03:06:00PM -0400, Thomas Dickey wrote:
> hmm - there are two sets of changes - I don't see a reason for the
> change to the curses function checks.

Thank you for reviewing my patch. The curses function check change does
have a reason. It can be solved differently in principle.

When I ran autoheader, config.hin would lack all the defines that should
have come from CF_CURSES_FUNCS while the relevant HAVE_* defines would
still show up in config.log after running configure and therefore the
resulting dlg_config.h would also lack them. That meant that dialog
would perceive a very dysfunctional curses and its shim would fail to
compile. Quite clearly, we shouldn't assume a crippled curses and
config.hin should contain the relevant templates. As it turns out,
autoheader interprets the m4 files and collects the AC_DEFINE and
AC_DEFINE_UNQUOTED invocations, well some of them actually. The
AC_CHECK_FUNCS would be collected whereas CF_CURSES_FUNCS not, even
though both seemed quite similar. The subtle difference is that
AC_CHECK_FUNCS uses AS_FOR (a loop that is evaluated using m4) whereas
CF_CURSES_FUNCS uses a shell for loop. Thus, autoheader would only see a
single, bogus AC_DEFINE_UNQUOTED for all of CF_CURSES_FUNCS and ignore
that. Avoiding this shell loop is key here and I went for manually
unrolling it, because AS_FOR didn't work out initially and unrolling
seemed workable to me. The crucial bit here is that you cannot use shell
for control flow here. If you prefer AS_FOR or some other working
mechanism, that's fine. Just do something about it to avoid dialog
failing to build when we remove libtool-bin from Debian.

Helmut

[toc] | [prev] | [next] | [standalone]

#1198274

[Multipart message — attachments visible in raw view] — view raw

On Wed, May 22, 2024 at 08:12:04AM +0200, Helmut Grohne wrote:
> Hi Thomas,
> 
> On Tue, May 21, 2024 at 03:06:00PM -0400, Thomas Dickey wrote:
> > hmm - there are two sets of changes - I don't see a reason for the
> > change to the curses function checks.
> 
> Thank you for reviewing my patch. The curses function check change does
> have a reason. It can be solved differently in principle.
> 
> When I ran autoheader, config.hin would lack all the defines that should

I don't use autoheader (though it's present in the fork I've maintained for
about the past quarter-century).  The configure script generates the complete
dlg_config.h without that crutch.  Attempting to bypass that will certainly
lead to unnecessary bug reports.

> have come from CF_CURSES_FUNCS while the relevant HAVE_* defines would
> still show up in config.log after running configure and therefore the
> resulting dlg_config.h would also lack them. That meant that dialog
> would perceive a very dysfunctional curses and its shim would fail to
> compile. Quite clearly, we shouldn't assume a crippled curses and
> config.hin should contain the relevant templates. As it turns out,
> autoheader interprets the m4 files and collects the AC_DEFINE and
> AC_DEFINE_UNQUOTED invocations, well some of them actually. The
> AC_CHECK_FUNCS would be collected whereas CF_CURSES_FUNCS not, even
> though both seemed quite similar. The subtle difference is that
> AC_CHECK_FUNCS uses AS_FOR (a loop that is evaluated using m4) whereas

Actually it would be AC_FOREACH, which invokes AH_TEMPLATE

fwiw, CF_CURSES_FUNCS predates that stuff (1997 versus 1999),
and there are other macros which might use those features.

(I added a to-do to follow up on this)

> CF_CURSES_FUNCS uses a shell for loop. Thus, autoheader would only see a
> single, bogus AC_DEFINE_UNQUOTED for all of CF_CURSES_FUNCS and ignore
> that. Avoiding this shell loop is key here and I went for manually
> unrolling it, because AS_FOR didn't work out initially and unrolling
> seemed workable to me. The crucial bit here is that you cannot use shell
> for control flow here. If you prefer AS_FOR or some other working
> mechanism, that's fine. Just do something about it to avoid dialog
> failing to build when we remove libtool-bin from Debian.
> 
> Helmut
> 

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

[toc] | [prev] | [next] | [standalone]

#1198218

Hi Thomas,

On Wed, May 22, 2024 at 03:53:43AM -0400, Thomas Dickey wrote:
> I don't use autoheader (though it's present in the fork I've maintained for
> about the past quarter-century).  The configure script generates the complete
> dlg_config.h without that crutch.  Attempting to bypass that will certainly
> lead to unnecessary bug reports.

I fear it occurred to me late that I should be using autoconf-dickey
instead of the standard autoconf for dialog. Hence my patch makes it
work the "wrong" autoconf and thus runs autoheader. I see how that would
not be necessary with autoconf-dickey.

> Actually it would be AC_FOREACH, which invokes AH_TEMPLATE
> 
> fwiw, CF_CURSES_FUNCS predates that stuff (1997 versus 1999),
> and there are other macros which might use those features.

Yeah. And if you make dialog work with autoconf-dickey and without
autoheader, then all of this becomes moot anyway.

Feel free to come up with a different solution as long as we stop
relying on /usr/bin/libtool as that's the component that will go away.
We now have one working solution and I'm happy if that is sufficient to
get the ball rolling for a better solution than mine.

Helmut

[toc] | [prev] | [next] | [standalone]

#1198307

[Multipart message — attachments visible in raw view] — view raw

On Wed, May 22, 2024 at 10:34:12AM +0200, Helmut Grohne wrote:
> Hi Thomas,
> 
> On Wed, May 22, 2024 at 03:53:43AM -0400, Thomas Dickey wrote:
> > I don't use autoheader (though it's present in the fork I've maintained for
> > about the past quarter-century).  The configure script generates the complete
> > dlg_config.h without that crutch.  Attempting to bypass that will certainly
> > lead to unnecessary bug reports.
> 
> I fear it occurred to me late that I should be using autoconf-dickey
> instead of the standard autoconf for dialog. Hence my patch makes it
> work the "wrong" autoconf and thus runs autoheader. I see how that would
> not be necessary with autoconf-dickey.
> 
> > Actually it would be AC_FOREACH, which invokes AH_TEMPLATE
> > 
> > fwiw, CF_CURSES_FUNCS predates that stuff (1997 versus 1999),
> > and there are other macros which might use those features.
> 
> Yeah. And if you make dialog work with autoconf-dickey and without
> autoheader, then all of this becomes moot anyway.
> 
> Feel free to come up with a different solution as long as we stop
> relying on /usr/bin/libtool as that's the component that will go away.
> We now have one working solution and I'm happy if that is sufficient to
> get the ball rolling for a better solution than mine.

thanks (on my to-do list)

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web