[PATCH] Cygwin: ldd: Also look for not found DLLs when exit status is non-zero
If the process exited with e.g. STATUS_DLL_NOT_FOUND, also process the file to look for not found DLLs. (We currently only do this when a STATUS_DLL_NOT_FOUND exception occurs, which I haven't managed to observe) This still isn't 100% correct, as it only examines the specified file for missing DLLs, not recursively on the DLLs it depends upon. --- winsup/utils/ldd.cc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/winsup/utils/ldd.cc b/winsup/utils/ldd.cc index e1af99e12..1e1863c1c 100644 --- a/winsup/utils/ldd.cc +++ b/winsup/utils/ldd.cc @@ -407,6 +407,8 @@ report (const char *in_fn, bool multiple) } break; case EXIT_PROCESS_DEBUG_EVENT: + if (ev.u.ExitProcess.dwExitCode != 0) + process_fn = fn_win; print_and_exit: print_dlls (&dll_list, isdll ? fn_win : NULL, process_fn); exitnow = true; -- 2.28.0
Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"
On Thu, 10 Sep 2020 09:15:00 +0900
Takashi Yano via Cygwin-patches wrote:
> Hi Corinna,
>
> On Wed, 9 Sep 2020 09:21:23 +0200
> Corinna Vinschen wrote:
> > On Sep 8 17:16, Takashi Yano via Cygwin-patches wrote:
> > > On Mon, 7 Sep 2020 23:17:36 +0200 (CEST)
> > > Johannes Schindelin wrote:
> > > > Hi Takashi,
> > > >
> > > > On Sat, 5 Sep 2020, Takashi Yano wrote:
> > > >
> > > > > On Fri, 4 Sep 2020 08:23:42 +0200 (CEST)
> > > > > Johannes Schindelin wrote:
> > > > > >
> > > > > > On Fri, 4 Sep 2020, Takashi Yano via Cygwin-patches wrote:
> > > > > >
> > > > > > > On Tue, 1 Sep 2020 18:19:16 +0200 (CEST)
> > > > > > > Johannes Schindelin wrote:
> > > > > > > [...]
> > > > `LANG=en_US.UTF-8` (meaning your patches force their console
> > > > applications'
> > > > output to be interpreted with code page 437) and therefore for those
> > > > users, things looked fine before, and now they don't.
> > > >
> > > > Note that I am not talking about developers who develop said console
> > > > applications. I am talking about users who use those console
> > > > applications.
> > > > In other words, I am talking about a vastly larger group of affected
> > > > people.
> > > >
> > > > All of those people (or at least a substantial majority) will now have
> > > > to
> > > > be told to please disable Pseudo Console support in v3.2.0 because they
> > > > would have to patch and rebuild those console applications that don't
> > > > call
> > > > `SetConsoleOutputCP()`, and that is certainly unreasonable to expect of
> > > > the majority of users. Not even the `cmd /c chcp 65001` work-around
> > > > (that
> > > > helps with v3.1.7) will work with v3.2.0 when Pseudo Console support is
> > > > enabled.
> > >
> > > In the case where pseudo console is disabled, the patch I proposed in
> > > https://cygwin.com/pipermail/cygwin-patches/2020q3/010548.html
> > > will solve the issue. I mean apps which work correctly in cygwin 3.0.7
> > > work in cygwin 3.2.0 as well with that patch.
> > >
> > > OTOH, in the case where pseudo console is enabled, non-cygwin apps which
> > > work correctly in command prompt, work in cygwin 3.2.0 as well.
> > >
> > > It is enough for all, isn't it?
> > >
> > > You may think that all non-cygwin apps which work in cygwin 3.0.7 must
> > > work in cygwin 3.2.0 even when pseudo console is enabled, but it is
> > > against the purpose of the pseudo console support. The goal of pseudo
> > > console support is to make non-cygwin apps work as if it is executed in
> > > command prompt.
> > >
> > > By the way, you complained regarding garbled output of the program which
> > > outputs UTF-8 string regardless of locale.
> > > https://cygwin.com/pipermail/cygwin-developers/2020-August/011951.html
> > > However, many Japanese programmers, for example, make programs which
> > > output SJIS (CP932) string regardless of locale.
> > >
> > > Why do you think the former must work while the latter deos not have to?
> > > Is there any reasonable reason other than backward compatibility?
> >
> > Is that still a concern with the latest from master? There's
> > a snapshot for testing, Johannes.
>
> We are still discussing about that.
> https://github.com/msys2/MSYS2-packages/issues/1974
>
> > Takashi, does the patch from
> > https://cygwin.com/pipermail/cygwin-developers/2020-August/011951.html
> > still apply to the latest from master? Question is, shouldn't the
> > Windows calls setting the codepage be only called if started from
> > child_info_spawn::worker for non-Cygwin executables?
>
> I'd propose the patch:
>
> diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
> index 37d033bbe..95b28c3da 100644
> --- a/winsup/cygwin/fhandler_tty.cc
> +++ b/winsup/cygwin/fhandler_tty.cc
> @@ -1830,7 +1830,11 @@ fhandler_pty_slave::setup_locale (void)
>extern UINT __eval_codepage_from_internal_charset ();
>
>if (!get_ttyp ()->term_code_page)
> -get_ttyp ()->term_code_page = __eval_codepage_from_internal_charset ();
> +{
> + get_ttyp ()->term_code_page = __eval_codepage_from_internal_charset ();
> + SetConsoleCP (get_ttyp ()->term_code_page);
> + SetConsoleOutputCP (get_ttyp ()->term_code_page);
> +}
> }
>
> void
>
> However, Johannes insists setting codepage for non-cygwin apps
> even when pseudo console is enabled, which I cannot agree.
>
> Actually, I hesitate even the patch above, however, it seems to
> be necessary for msys apps in terms of backward compatibility.
I found that output of Oracle java.exe and javac.exe are garbled
if the patch above is applied. This is because java.exe and javac.exe
output SJIS code unconditionally in my environment.
OTOH, rust-based program such as cargo and ripgrep output UTF-8
unconditionally. node.js also seems to output UTF-8 string by
default.
I think there is no way for both apps to work properly if pseudo
console is disabled. As far as I tested, both of them works when
pseudo console is enabled. IMHO, the be
Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"
On Tue, 8 Sep 2020 18:45:36 +0900 Takashi Yano via Cygwin-patches wrote: > Hi Corinna, > > On Tue, 8 Sep 2020 10:40:34 +0200 > Corinna Vinschen wrote: > > On Sep 7 13:45, Takashi Yano via Cygwin-patches wrote: > > > On Mon, 7 Sep 2020 01:04:13 +0900 > > > > > Chages: > > > > > - If global locale is set, it takes precedence. > > > > > > > > Changes: > > > > - Use __get_current_locale() instead of __get_global_locale(). > > > > - Fix a bug for ISO-8859-* charset. > > > > > > Changes: > > > - Use envblock if it is passed to CreateProcess in spawn.cc. > > > > For the time being and to make at least *some* progress and with my > > upcoming "away from keyboard"-time , I pushed the gist of my patch, > > replacing the locale evaluating code in fhandler_tty with the function > > __eval_codepage_from_internal_charset in its most simple form. > > I didn't touch anything else, given that this discussion is still > > ongoing. > > Your patch pushed does the magic! > > Even cygterm works even though the code does not check environment. > > The point is here. > > @@ -1977,9 +1807,6 @@ fhandler_pty_slave::fixup_after_exec () >if (!close_on_exec ()) > fixup_after_fork (NULL); /* No parent handle required. */ > > - /* Set locale */ > - setup_locale (); > - >/* Hook Console API */ > #define DO_HOOK(module, name) \ >if (!name##_Orig) \ > > Without this deletion, term_code_page is determined when > cygwin shell is executed. Since it is in fixup_after_exec(), > setlocale() does not called yet in the shell. As a result, > term_code_page cannot be determined correctly. > > In your new patch, term_code_page is determined when the first > non-cygwin program is execed in the shell. The shell process > already calls setlocale(), so term_code_page can be determined > using global locale. > > Thanks for the excellent idea! > > Only the problem I noticed is that cygterm does not work if the > shell does not call setlocale(). This happens if the shell is > non-cygwin program, for example, cmd.exe, however, it is unusual > case. I noticed this also happens when shell is /bin/ash (/bin/dash). However, it's still acceptable for me. -- Takashi Yano
Re: [PATCH] Cygwin: ldd: Also look for not found DLLs when exit status is non-zero
On Sep 10 13:27, Jon Turney wrote: > If the process exited with e.g. STATUS_DLL_NOT_FOUND, also process the > file to look for not found DLLs. > > (We currently only do this when a STATUS_DLL_NOT_FOUND exception occurs, > which I haven't managed to observe) > > This still isn't 100% correct, as it only examines the specified file > for missing DLLs, not recursively on the DLLs it depends upon. Better than nothing? Please push. Thanks, Corinna
Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"
Hi Takashi,
On Sep 10 09:15, Takashi Yano via Cygwin-patches wrote:
> On Wed, 9 Sep 2020 09:21:23 +0200
> Corinna Vinschen wrote:
> > Takashi, does the patch from
> > https://cygwin.com/pipermail/cygwin-developers/2020-August/011951.html
> > still apply to the latest from master? Question is, shouldn't the
> > Windows calls setting the codepage be only called if started from
> > child_info_spawn::worker for non-Cygwin executables?
>
> I'd propose the patch:
>
> diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
> index 37d033bbe..95b28c3da 100644
> --- a/winsup/cygwin/fhandler_tty.cc
> +++ b/winsup/cygwin/fhandler_tty.cc
> @@ -1830,7 +1830,11 @@ fhandler_pty_slave::setup_locale (void)
>extern UINT __eval_codepage_from_internal_charset ();
>
>if (!get_ttyp ()->term_code_page)
> -get_ttyp ()->term_code_page = __eval_codepage_from_internal_charset ();
> +{
> + get_ttyp ()->term_code_page = __eval_codepage_from_internal_charset ();
> + SetConsoleCP (get_ttyp ()->term_code_page);
> + SetConsoleOutputCP (get_ttyp ()->term_code_page);
> +}
> }
>
> void
>
> However, Johannes insists setting codepage for non-cygwin apps
> even when pseudo console is enabled, which I cannot agree.
>
> Actually, I hesitate even the patch above, however, it seems to
> be necessary for msys apps in terms of backward compatibility.
If we do as above, doesn't that mean the invocation of convert_mb_str in
fhandler_pty_master::accept_input, as well as the second invocation of
convert_mb_str in fhandler_pty_master::pty_master_fwd_thread are
redundant? Both are only called if get_ttyp ()->term_code_page differs
from the input or output console codepage. Given the above setting of
the console CP to term_code_page, this would never be the case, right?
Corinna
Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"
On Thu, 10 Sep 2020 16:04:07 +0200
Corinna Vinschen wrote:
> Hi Takashi,
>
> On Sep 10 09:15, Takashi Yano via Cygwin-patches wrote:
> > On Wed, 9 Sep 2020 09:21:23 +0200
> > Corinna Vinschen wrote:
> > > Takashi, does the patch from
> > > https://cygwin.com/pipermail/cygwin-developers/2020-August/011951.html
> > > still apply to the latest from master? Question is, shouldn't the
> > > Windows calls setting the codepage be only called if started from
> > > child_info_spawn::worker for non-Cygwin executables?
> >
> > I'd propose the patch:
> >
> > diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
> > index 37d033bbe..95b28c3da 100644
> > --- a/winsup/cygwin/fhandler_tty.cc
> > +++ b/winsup/cygwin/fhandler_tty.cc
> > @@ -1830,7 +1830,11 @@ fhandler_pty_slave::setup_locale (void)
> >extern UINT __eval_codepage_from_internal_charset ();
> >
> >if (!get_ttyp ()->term_code_page)
> > -get_ttyp ()->term_code_page = __eval_codepage_from_internal_charset ();
> > +{
> > + get_ttyp ()->term_code_page = __eval_codepage_from_internal_charset
> > ();
> > + SetConsoleCP (get_ttyp ()->term_code_page);
> > + SetConsoleOutputCP (get_ttyp ()->term_code_page);
> > +}
> > }
> >
> > void
> >
> > However, Johannes insists setting codepage for non-cygwin apps
> > even when pseudo console is enabled, which I cannot agree.
> >
> > Actually, I hesitate even the patch above, however, it seems to
> > be necessary for msys apps in terms of backward compatibility.
>
> If we do as above, doesn't that mean the invocation of convert_mb_str in
> fhandler_pty_master::accept_input, as well as the second invocation of
> convert_mb_str in fhandler_pty_master::pty_master_fwd_thread are
> redundant? Both are only called if get_ttyp ()->term_code_page differs
> from the input or output console codepage. Given the above setting of
> the console CP to term_code_page, this would never be the case, right?
You are right by default. However, if user change the code page using
chcp.com, conversion does work.
--
Takashi Yano
Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"
On Thu, 10 Sep 2020 23:16:10 +0900
Takashi Yano wrote:
> On Thu, 10 Sep 2020 16:04:07 +0200
> Corinna Vinschen wrote:
>
> > Hi Takashi,
> >
> > On Sep 10 09:15, Takashi Yano via Cygwin-patches wrote:
> > > On Wed, 9 Sep 2020 09:21:23 +0200
> > > Corinna Vinschen wrote:
> > > > Takashi, does the patch from
> > > > https://cygwin.com/pipermail/cygwin-developers/2020-August/011951.html
> > > > still apply to the latest from master? Question is, shouldn't the
> > > > Windows calls setting the codepage be only called if started from
> > > > child_info_spawn::worker for non-Cygwin executables?
> > >
> > > I'd propose the patch:
> > >
> > > diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
> > > index 37d033bbe..95b28c3da 100644
> > > --- a/winsup/cygwin/fhandler_tty.cc
> > > +++ b/winsup/cygwin/fhandler_tty.cc
> > > @@ -1830,7 +1830,11 @@ fhandler_pty_slave::setup_locale (void)
> > >extern UINT __eval_codepage_from_internal_charset ();
> > >
> > >if (!get_ttyp ()->term_code_page)
> > > -get_ttyp ()->term_code_page = __eval_codepage_from_internal_charset
> > > ();
> > > +{
> > > + get_ttyp ()->term_code_page =
> > > __eval_codepage_from_internal_charset ();
> > > + SetConsoleCP (get_ttyp ()->term_code_page);
> > > + SetConsoleOutputCP (get_ttyp ()->term_code_page);
> > > +}
> > > }
> > >
> > > void
> > >
> > > However, Johannes insists setting codepage for non-cygwin apps
> > > even when pseudo console is enabled, which I cannot agree.
> > >
> > > Actually, I hesitate even the patch above, however, it seems to
> > > be necessary for msys apps in terms of backward compatibility.
> >
> > If we do as above, doesn't that mean the invocation of convert_mb_str in
> > fhandler_pty_master::accept_input, as well as the second invocation of
> > convert_mb_str in fhandler_pty_master::pty_master_fwd_thread are
> > redundant? Both are only called if get_ttyp ()->term_code_page differs
> > from the input or output console codepage. Given the above setting of
> > the console CP to term_code_page, this would never be the case, right?
>
> You are right by default. However, if user change the code page using
> chcp.com, conversion does work.
Not only user, but also app may change the codepage by SetConsoleCP()
and SetConsoleOutputCP().
--
Takashi Yano
