git submodule + gettext / envsubst

git submodule + gettext / envsubst

[Andreas Heckel]

Hi,

I recently faced some error messages when using git submodules. I found, that Cygwin's git works nicely on its own. But when I have MSYS binary paths in my environment, Cygwin's git finds the msys gettext and envsubst binary and tries to use it, resulting in error messages (see below). I did solve the issue, by installing Cygwin's gettext (which git does not seem to be requiring).
I write, because I found it somewhat odd, that Cygwin's git is not dependent on gettext, but uses it, if it finds it somewhere in the path environment. Just to emphasize, in my Cygwin environment all Cygwin paths come first. So it was only using the wrong msys binary, because there was none in Cygwin.
Is this behaviour expected and intended or could it be mitigated during installation somehow?

Just for completeness: I am using Cygwin and msys updated to the latest versions.
The original error message:

$ git submodule update
      0 [main] gettext (10868) child_copy: cygheap read copy failed, 0x800000000..0x80002A310, done 0, windows pid 10868, Win32 error 6
   1248 [main] gettext 583 C:\msys64\usr\bin\gettext.exe: *** fatal error - couldn't create signal pipe, Win32 error 5
      0 [main] envsubst (4800) child_copy: cygheap read copy failed, 0x800000000..0x80002A378, done 0, windows pid 4800, Win32 error 6
    604 [main] envsubst 584 C:\msys64\usr\bin\envsubst.exe: *** fatal error - couldn't create signal pipe, Win32 error 5
      0 [main] envsubst (2160) child_copy: cygheap read copy failed, 0x800000000..0x80002A378, done 0, windows pid 2160, Win32 error 6
   1016 [main] envsubst 1385 C:\msys64\usr\bin\envsubst.exe: *** fatal error - couldn't create signal pipe, Win32 error 5




Cheers,
Andreas

Re: git submodule + gettext / envsubst

[Adam Dinwoodie]

On Fri, 23 Jun 2023 at 08:59, Andreas Heckel via Cygwin wrote:
>
> Hi,
>
> I recently faced some error messages when using git submodules. I found, that Cygwin's git works nicely on its own. But when I have MSYS binary paths in my environment, Cygwin's git finds the msys gettext and envsubst binary and tries to use it, resulting in error messages (see below). I did solve the issue, by installing Cygwin's gettext (which git does not seem to be requiring).
> I write, because I found it somewhat odd, that Cygwin's git is not dependent on gettext, but uses it, if it finds it somewhere in the path environment. Just to emphasize, in my Cygwin environment all Cygwin paths come first. So it was only using the wrong msys binary, because there was none in Cygwin.
> Is this behaviour expected and intended or could it be mitigated during installation somehow?

This sounds like a missing dependency in Cygwin's Git package. I'm
slightly surprised – the package is included in the build
requirements, and cygport is normally pretty good at detecting runtime
dependencies in this sort of circumstance – but I'll get it fixed as
soon as I manage to get a new Git release out.

That's going to happen Any Day Now, although it has been Any Day Now
for a few months at this point thanks to a variety of other life
issues taking priority…

Adam

Re: git submodule + gettext / envsubst

[Jon Turney]

On 23/06/2023 11:11, Adam Dinwoodie via Cygwin wrote:
> On Fri, 23 Jun 2023 at 08:59, Andreas Heckel via Cygwin wrote:
>>
>> Hi,
>>
>> I recently faced some error messages when using git submodules. I found, that Cygwin's git works nicely on its own. But when I have MSYS binary paths in my environment, Cygwin's git finds the msys gettext and envsubst binary and tries to use it, resulting in error messages (see below). I did solve the issue, by installing Cygwin's gettext (which git does not seem to be requiring).
>> I write, because I found it somewhat odd, that Cygwin's git is not dependent on gettext, but uses it, if it finds it somewhere in the path environment. Just to emphasize, in my Cygwin environment all Cygwin paths come first. So it was only using the wrong msys binary, because there was none in Cygwin.
>> Is this behaviour expected and intended or could it be mitigated during installation somehow?
> 
> This sounds like a missing dependency in Cygwin's Git package. I'm
> slightly surprised – the package is included in the build
> requirements, and cygport is normally pretty good at detecting runtime
> dependencies in this sort of circumstance – but I'll get it fixed as
> soon as I manage to get a new Git release out.
> 
> That's going to happen Any Day Now, although it has been Any Day Now
> for a few months at this point thanks to a variety of other life
> issues taking priority…

perhaps git.cygport needs DEPS_PATH="/usr/libexec/git-core" or something 
like that (so that executables files in that directory are included in 
the automatic dependency check)

[1] https://cygwin.github.io/cygport/pkg_info_cygpart.html#DEPS_PATH

Re: git submodule + gettext / envsubst

[Brian Inglis]

On 2023-06-23 06:35, Jon Turney via Cygwin wrote:
> On 23/06/2023 11:11, Adam Dinwoodie via Cygwin wrote:
>> On Fri, 23 Jun 2023 at 08:59, Andreas Heckel via Cygwin wrote:
>>>
>>> Hi,
>>>
>>> I recently faced some error messages when using git submodules. I found, that 
>>> Cygwin's git works nicely on its own. But when I have MSYS binary paths in my 
>>> environment, Cygwin's git finds the msys gettext and envsubst binary and 
>>> tries to use it, resulting in error messages (see below). I did solve the 
>>> issue, by installing Cygwin's gettext (which git does not seem to be requiring).
>>> I write, because I found it somewhat odd, that Cygwin's git is not dependent 
>>> on gettext, but uses it, if it finds it somewhere in the path environment. 
>>> Just to emphasize, in my Cygwin environment all Cygwin paths come first. So 
>>> it was only using the wrong msys binary, because there was none in Cygwin.
>>> Is this behaviour expected and intended or could it be mitigated during 
>>> installation somehow?
>>
>> This sounds like a missing dependency in Cygwin's Git package. I'm
>> slightly surprised – the package is included in the build
>> requirements, and cygport is normally pretty good at detecting runtime
>> dependencies in this sort of circumstance – but I'll get it fixed as
>> soon as I manage to get a new Git release out.
>>
>> That's going to happen Any Day Now, although it has been Any Day Now
>> for a few months at this point thanks to a variety of other life
>> issues taking priority…
> 
> perhaps git.cygport needs DEPS_PATH="/usr/libexec/git-core" or something like 
> that (so that executables files in that directory are included in the automatic 
> dependency check)
> 
> [1] https://cygwin.github.io/cygport/pkg_info_cygpart.html#DEPS_PATH

Most git binaries link to gettext's libintl8 /usr/bin/cygintl-8.dll but a number 
of Git shell scripts:

/usr/libexec/git-core/git-bisect
/usr/libexec/git-core/git-filter-branch
/usr/libexec/git-core/git-merge-octopus
/usr/libexec/git-core/git-merge-one-file
/usr/libexec/git-core/git-merge-resolve
/usr/libexec/git-core/git-mergetool
/usr/libexec/git-core/git-quiltimport
/usr/libexec/git-core/git-request-pull
/usr/libexec/git-core/git-submodule
/usr/libexec/git-core/git-web--browse

each source:

	. git-sh-setup in /usr/libexec/git-core/

which sources:

	. "$(git --exec-path)/git-sh-i18n" in /usr/libexec/git-core/

which sources:

	. gettext.sh in /usr/bin/

which defines shell functions which run the gettext binaries:

	/usr/bin/gettext
	/usr/bin/ngettext

so not easily detectable, probably needing cygport REQUIRES=gettext.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry