Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32
Jonathan Yong is correct - removing --build allows make to complete
without error using the unmodified ltmain.sh
There's still the issue of generating a call to cmd.exe with an invalid
switch (//c), which will cause it to hang indefinitely if ever invoked.
The risk of breaking anything by fixing this seems like nil.
On 6/26/2021 3:17 PM, Brian Inglis wrote:
On 2021-06-25 14:46, Dietmar May via Cygwin wrote:
The build completes successfully by replacing the "cmd /c | sed"
construct with simply:
func_convert_core_msys_to_w32_result=$1
so no path translation takes place.
The function then becomes:
func_convert_core_msys_to_w32 ()
{
$debug_cmd
func_convert_core_msys_to_w32_result=$1
}
SUMMARY
func_convert_core_msys_to_w32 in
/usr/share/libtool/build-aux/ltmain.sh
has an extraneous '/' in the call to
( cmd //c echo "$1" )
causing make to hang indefinitely
when configured with
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
Which you don't need to change if you configure properly, as JonY
replied on the list to your earlier post:
On 2021-06-25 09:27, Jonathan Yong via Cygwin wrote:
>
> Don't set --build, you are building on Cygwin, not MSYS.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Custom locales seem not to work
On 2021-06-26 13:29, Brian Inglis wrote: On 2021-06-26 08:58, Алекса -скрыто- via Cygwin wrote: I have never seen ie used as a language code under Linux systems, and it is interlingual, associated with unspecified territory code XX, so you would have to set each locale category separately to achieve the desired effects: fr_CH or en_US. ... the locale should be set to "ie_XX.UTF-8", which the locale data provides, not "C" like Cygwin does now. If you setup non-interoperable custom locales, it is likely that Cygwin may not be seeing anything it can map, so will default to the hardwired built-in C/POSIX locale. You need to help us diagnose what, if anything, Cygwin may be seeing from your custom Windows locale. What does Cygwin show when you run the locale dump command from a shell: $ for o in -s -u -i -n -f ''; do locale $o; done Which are non-interoperable Windows-only totally meaningless language and territory values to Cygwin startup or any Cygwin, Linux, or Unix program based on Unix libraries or code, so everything might map to the system default locale at best, or hardwired built-in C/POSIX locale at worst. That custom locale would be better if developed as a fr_CH replacement or supplementary Windows locale. It might also help if you followed the Cygwin problem reporting guidelines: https://cygwin.com/problems.html and attached the required output as plain text to your next response. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Custom locales seem not to work
On 2021-06-26 08:58, Алекса -скрыто- via Cygwin wrote: I have never seen ie used as a language code under Linux systems, and it is interlingual, associated with unspecified territory code XX, so you would have to set each locale category separately to achieve the desired effects: fr_CH or en_US. ... the locale should be set to "ie_XX.UTF-8", which the locale data provides, not "C" like Cygwin does now. Which are non-interoperable Windows-only totally meaningless language and territory values to Cygwin startup or any Cygwin, Linux, or Unix program based on Unix libraries or code, so everything might map to the system default locale at best, or hardwired built-in C/POSIX locale at worst. That custom locale would be better if developed as a fr_CH replacement or supplementary Windows locale. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32
On 2021-06-25 14:46, Dietmar May via Cygwin wrote:
The build completes successfully by replacing the "cmd /c | sed"
construct with simply:
func_convert_core_msys_to_w32_result=$1
so no path translation takes place.
The function then becomes:
func_convert_core_msys_to_w32 ()
{
$debug_cmd
func_convert_core_msys_to_w32_result=$1
}
SUMMARY
func_convert_core_msys_to_w32 in
/usr/share/libtool/build-aux/ltmain.sh
has an extraneous '/' in the call to
( cmd //c echo "$1" )
causing make to hang indefinitely
when configured with
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
Which you don't need to change if you configure properly, as JonY
replied on the list to your earlier post:
On 2021-06-25 09:27, Jonathan Yong via Cygwin wrote:
>
> Don't set --build, you are building on Cygwin, not MSYS.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin, Unicode and "long" path names
On 2021-06-25 19:53, Vadim wrote:
Ah, this beautiful topic. Windows 7 x64.
This is the summary written as post-scriptum, tests and findings below:
1) Cygwin limits individual names to 255 bytes, Windows seems to follow
UTF-16 chars and work fine: 256 bytes in 108 characters works.
Basically, this becomes a bytes vs characters story.
2) Bash file name auto-expansion detects the file of that name, but it
gets truncated to 255 bytes. find's behaviour is the same ("No such file
or directory" due to trying to access a non-existing truncated name)
2.1) If you try to correct the above mistake by adding truncated
characters, then the program (cat) will complain about "File name too long"
2.2) If there exists a folder with a 255-byte name, equal to the
truncated name, then "find ." will do a listing on that folder twice
(effectively hiding the long-named folder from tools without leaving an
error message)
3) UNC Paths get the same treatment: File name too long.
I expected Cygwin to handle these names without problems just like
Windows, Explorer, cmd etc. do. Is this particular problem new or known?
All I could find on the mailing list is around the time when Cygwin
hadn't yet implemented Unicode support (UTF-8?), ~2004-2008.
These names were created by youtube-dl.exe executed from within Cygwin.
This file name is 255 bytes long and works:
s123點半蘋果新聞報道 字幕版重溫（2021年5月18日）︱蔡展鵬光顧賣淫骨場 O記
轉介律政司︱新巴車長被判不小心駕駛罪成︱深圳賽格大樓離奇劇晃 民眾慌忙逃
走︱蘋果日報 Apple Daily #香港新聞.txt
This is 256 bytes and works perfectly normal in Windows (explorer, can
paste and "dir " in cmd despite showing [] block chars), but not
Cygwin terminal (I used s123/s1234 as a prefix for easy auto-expansion):
s1234點半蘋果新聞報道 字幕版重溫（2021年5月18日）︱蔡展鵬光顧賣淫骨場 O
記轉介律政司︱新巴車長被判不小心駕駛罪成︱深圳賽格大樓離奇劇晃 民眾慌忙
逃走︱蘋果日報 Apple Daily #香港新聞.txt
If I try to use tab-expansion in the terminal (mintty, bash) the problem
becomes apparent ("xt" missing at the end):
$ cat s1234點半蘋果新聞報道\ 字幕版重溫（2021年5月18日）︱蔡展鵬光顧賣淫
骨場\ O記轉介律政司︱新巴車長被判不小心駕駛罪成 ︱深圳賽格大樓離奇劇晃\
民眾慌忙逃走︱蘋果日報\ Apple\ Daily\ #香港新聞.t
cat: 's1234點半蘋果新聞報道 字幕版重溫（2021年5月18日）︱蔡展鵬光顧賣淫
骨場 O記轉介律政司︱新巴車長被判不小心駕駛罪成︱深圳賽格大樓離奇劇晃 民
眾慌忙逃走︱蘋果日報 Apple Daily #香港新聞.t': No such file or directory
However, with one fewer byte it expands properly:
$ cat s123點半蘋果新聞報道\ 字幕版重溫（2021年5月18日）︱蔡展鵬光顧賣淫
骨場\ O記轉介律政司︱新巴車長被判不小心駕駛罪成︱深圳賽格大樓離奇劇晃\
民眾慌忙逃走︱蘋果日報\ Apple\ Daily\ #香港新聞.txt
hello
MAX_PATH? Yes, 255 bytes. Why then does the full file/folder name work
in Windows? This is the full name (a folder), 257 bytes:
20210518_9點半蘋果新聞報道 字幕版重溫（2021年5月18日）︱蔡展鵬光顧賣淫骨
場 O記轉介律政司︱新巴車長被判不小心駕駛罪成︱深圳賽格大樓離奇劇晃 民眾
慌忙逃走︱蘋果日報 Apple Daily #香港新聞
And it can get longer! In fact, I can bump the total path to 396 bytes
or "Column 249" as Notepad++ counts the characters (individual folder
name is 359b or 211 chars, "column 212"):
D:/abcdefgh/Local_TEMP/cygwinunicode
/1_123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789020210518_9
點半蘋果新聞報道 字幕版重溫（2021年5月18日）︱蔡展鵬光顧賣淫骨場 O記轉介
律政司︱新巴車長被判不小心駕駛罪成︱深圳賽格大樓離奇劇晃 民眾慌忙逃走︱
蘋果日報 Apple Daily #香港新聞
NTFS allows up to 255 UTF-16 for an individual path segment and this
seems to align with the Windows tooling: cmd and Explorer can browse
these fine, but the included file in the folder spills beyond the limit
and you run into the usual 'total path too long' problem).
Whether you manually add the missing "xt" to the tab-completion or use
UNC paths, the result is the same:
$ cat s1234點半蘋果新聞報道\ 字幕版重溫（2021年5月18日）︱蔡展鵬光顧賣淫
骨場\ O記轉介律政司︱新巴車長被判不小心駕駛罪成 ︱深圳賽格大樓離奇劇晃\
民眾慌忙逃走︱蘋果日報\ Apple\ Daily\ #香港新聞.txt
cat: 's1234點半蘋果新聞報道 字幕版重溫（2021年5月18日）︱蔡展鵬光顧賣淫
骨場 O記轉介律政司︱新巴車長被判不小心駕駛罪成︱深圳賽格大樓離奇劇晃 民
眾慌忙逃走︱蘋果日報 Apple Daily #香港新聞.txt': File name too long
$ cat '\\?\D:\abcdefgh\Local_TEMP\cygwinunicode\20210518_9點半蘋果新聞報
道 字幕版重溫（2021年5月18日）︱蔡展鵬光顧賣淫骨場 O記轉介律政司︱新巴車
長被判不小心駕駛罪成︱深圳賽格大樓離奇劇晃 民眾慌忙逃走︱蘋果日報 Apple
Daily #香港新聞.txt'
cat: '\\?\D:\abcdefgh\Local_TEMP\cygwinunicode\20210518_9點半蘋果新聞報
道 字幕版重溫（2021年5月18日）︱蔡展鵬光顧賣淫骨場 O記轉介律政司︱新巴車
長被判不小心駕駛罪成︱深圳賽格大樓離奇劇晃 民眾慌忙逃走︱蘋果日報 Apple
Daily #香港新聞.txt': File name too long
Filename 113 characters, 261 bytes:
$ wc -lwmcL <<< '20210518_9點半蘋果新聞報道 字幕版重溫（2021年5月18日）
︱蔡展鵬光顧賣淫骨場 O記轉介律政司︱新巴車長被判不小心駕駛罪成︱深圳賽格
大樓離奇劇晃 民眾慌忙逃走︱蘋果日報 Apple Daily #香港新聞.txt'
1 7 114 262 187
$ strace -o touch.strace /usr/bin/touch '20210518_9點半蘋果新聞報道 字幕
版重溫（2021年5月18日）︱蔡展鵬光顧賣淫骨場 O記轉介律政司︱新巴車長被判
不小心駕駛罪成︱深圳賽格大樓離奇劇晃 民眾慌忙逃走︱蘋果日報 Apple Daily
#香 港新聞.txt'
/usr/bin/touch: cannot touch '20210518_9點半蘋果新聞報道 字幕版重溫
（2021年5月18日）︱蔡展鵬光顧賣淫骨場 O記轉介律政司︱
新巴車長被判不小心駕駛罪成︱深圳賽格大樓離奇劇晃 民眾慌忙逃走︱蘋果日報
Apple Daily #香港新聞.txt': File name too long
Trim 2 leading and 4 trailing bytes and it works:
/usr/bin/touch '210518_9點半蘋果新聞報道 字幕版重溫（2021年5月18日）︱蔡
展鵬光顧賣淫骨場 O記轉介 律政司︱新巴車長被判不小心駕駛罪成︱深圳賽格大
樓離奇劇晃 民眾慌忙逃走︱蘋果日報 Apple Daily #香港新聞'
$ l '210518_9點半蘋果新聞報道 字幕版重溫（2021年5月18日）︱蔡展鵬光顧賣
淫骨場 O記轉介律政司︱新巴車長被判不小心駕駛罪成︱深圳賽格大樓離奇劇晃
民眾慌忙逃走︱蘋果日報 Apple Daily #香港新聞'
'210518_9點半蘋果新聞報道 字幕版重溫（2021年5月18日）︱蔡展鵬光顧賣淫骨
場
Re: Custom locales seem not to work
> I have never seen ie used as a language code under Linux systems, and it > is interlingual, associated with unspecified territory code XX, so you > would have to set each locale category separately to achieve the desired > effects: fr_CH or en_US. ... the locale should be set to "ie_XX.UTF-8", which the locale data provides, not "C" like Cygwin does now. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [PATCH] Cygwin: Zero out gmon header before use
On 23/06/2021 09:56, Mark Geisert wrote: Tools that process gmon.out files can be confused by gmon header fields with garbage in them due to lack of initialization. Repair that. Applied. Thanks.
Re: calm/mksetupini changes
On 28/03/2020 19:26, Jon Turney wrote: I've recently deployed some updates to calm, which change a few things maintainers may notice: Been a while since I wrote one of these mails: * Meaningless keys in .hint or src.hint files are now disallowed - 'requires:' and 'obsolete:' are not allowed in src.hint files - 'skip:' is not allowed in hint files In the unlikely event that: - you have a private package repository, AND - you run calm version >= 20210626 You'll might need to successfully run 'calm-tool fix-invalid-key-hint' on that repository, to drop those invalid keys, before you can use calm or mksetupini. * 'homepage:' is now mandatory in uploaded src.hint (or HOMEPAGE must exist in the .cygport, if you are using a cygport so old it doesn't generate src.hint files) * Upload of a 0-byte file in place of a empty compressed archive is no longer permitted (cygport stopped generating such anomalies years ago) * The 'virtual' is now allowed in 'category:', and indicates to calm that this package only exists to pull in other packages (i.e. is empty, but has dependencies, which it otherwise might warn about).
[ANNOUNCEMENT] Updated: Perl distributions
The following Perl distributions have been updated to their latest release version available on CPAN: noarch -- perl-Alien-Build-2.41-1 perl-Config-AutoConf-0.320-1 perl-Data-Dump-1.25-1 perl-Data-GUID-0.050-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Updated: Perl distributions
The following Perl distributions have been updated to their latest release version available on CPAN: noarch -- perl-Alien-Build-2.41-1 perl-Config-AutoConf-0.320-1 perl-Data-Dump-1.25-1 perl-Data-GUID-0.050-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Re;
Hello my friend, did you get my last message if no, write me through this email for more info : mrslin...@gmail.com? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
