Re: [Bug-wget] "make check" fails in "Test-iri-disabled" on Mac OS X, after "./configure" and "make" of wget-1.19.4 complete

[Tim Rühsen]

The charset conversion has an issue on OSX since a while (OSX changed
something). And we have no OSX developer, so there is nothing to do for us.

In the past I had several contacts with charset issues on OSX, who found
configuration/installation issues after a while and then silenced
(problem solved for them).

Best thing is you send us the complete config.log and
tests/Test-iri-disabled.log.

You could also check if this might be a filesystem problem. HFS+ doesn't
always save files with the name you specify... it uses decomposed UTF-8
(AFAIR), while the perl test might check for composed UTF-8. You won't
see the difference on the console, but a byte-per-byte comparison of the
filenames wouldn't work and the test might fail. Just a guess.


With Best Regards, Tim



On 02/20/2018 11:53 AM, address@hidden wrote:
> 
> ### I did the following:
> 
> export PKG_CONFIG='/opt/pkg-config/bin/pkg-config'
> export PKG_CONFIG_PATH='/opt/pkg-config/lib/pkgconfig'
> 
> ./configure --with-ssl=openssl --with-openssl=yes 
> --with-libssl-prefix=/opt/openssl --with-zlib=/opt/zlib
> 
> make
> make check
> 
> 
> ### Actual Result:
> 
> "make check" printed the following failure.
> 
> FAIL: Test-iri-disabled.px
> 
> 
> "config.log" holds the following pieces of information indicating failures.
> 
> http://localhost:49307/p1_fran\347ais.html
> http://localhost:49307/p1_fran%E7ais.html
> Incomplete or invalid multibyte sequence encountered
> Failed to convert file name 'p1_français.html' (UTF-8) -> '?' (US-ASCII)
> 
> 
> http://localhost:49307/p2_\351\351n.html
> http://localhost:49307/p2_%E9%E9n.html
> Incomplete or invalid multibyte sequence encountered
> Failed to convert file name 'p2_één.html' (UTF-8) -> '?' (US-ASCII)
> 
> 
> http://localhost:49307/p3_\244\244\244.html
> http://localhost:49307/p3_%A4%A4%A4.html
> Incomplete or invalid multibyte sequence encountered
> Failed to convert file name 'p3_¤¤¤.html' (UTF-8) -> '?' (US-ASCII)
> 
> 
> There are some non-ASCII characters in the above file names. In case the 
> non-ASCII characters get corrupted through the Internet, I will describe them.
> 
> "p1_fran" on the left of "(UTF-8)" is followed by the "lowercase c with 
> cedilla", whose octal code is 0347 and hex code is E7 for Unicode codepoint 
> and for ISO-8859-1. It is a single-byte character for ISO-8859-1 (ISO 
> Latin-1). However, it is a double-byte character for UTF-8, and its hex code 
> is 0xC3A7 for UTF-8.
> 
> 
> "p2_" on the left of "(UTF-8)" is followed by two occurrences of the 
> "lowercase e with acute", whose octal code is 0351 and hex code is E9 for 
> Unicode codepoint and for ISO-8859-1. It is a single-byte character for 
> ISO-8859-1 (ISO Latin-1). However, it is a double-byte character for UTF-8, 
> and its hex code is 0xC3A9 for UTF-8.
> 
> 
> "p3_" on the left of "(UTF-8)" is followed by three occurrences of the 
> "generic currency sign", whose octal code is 0244 and hex code is A4 for 
> Unicode codepoint and for ISO-8859-1. It is a single-byte character for 
> ISO-8859-1 (ISO Latin-1). However, it is a double-byte character for UTF-8, 
> and its hex code is 0xC2A4 for UTF-8.
> 
> 
> ### Questions
> 
> While I would like this problem to be fixed, I also would like to know what 
> this test is trying to do. Is the test trying to convert "c cedilla" to plain 
> "c", and "e acute" to plain "e", and "generic currency sign" to the "dollar 
> sign"? Moreover, before converting from UTF-8 to US-ASCII, it has to convert 
> from the single-byte Unicode codepoint or ISO-8859-1 to the double-byte 
> UTF-8, does it not?
> 
> 
> ### Related
> 
> "make check" also fails in "Test-https-pfs" and "Test-https-tlsv1x" at the 
> same time as "Test-iri-disabled" under the same condition and the same 
> environment. Separately from this report, I am planning to report about 
> "Test-https-pfs" and "Test-https-tlsv1x" later.
> 
> In Bug 50223 (thread "bug-wget/2017-02/msg00010.html"), "make" failed to 
> compile/link on Mac OS X. Wget has made progress since then. Now, in my 
> situation, "make" completes to compile and link, but "make check" fails.
> 
> 
> ### Environment
> 
> wget-1.19.4
> Mac OS X
> Intel 64-bit
> 
>

signature.asc
Description: OpenPGP digital signature