make check fails in [build JCS]

Stephan Bergmann sbergman at
Fri Dec 7 08:31:57 UTC 2018

On 12/11/2018 10:38, Stephan Bergmann wrote:
> On 03/09/2018 17:23, Stephan Bergmann wrote:
>> On 29/08/18 11:43, Noel Grandin wrote:
>>> On 2018/08/29 11:06 AM, Stephan Bergmann wrote:
>>>> investigating deeper into the issue.  (Apparently, Java no longer 
>>>> accepts file:... URLs there, at least on Windows, and won't accept 
>>>> full pathnames starting with a drive letter like C:/..., but does 
>>>> accept ("drive-absolute") pathnames like /...; so my hack should 
>>>> work as long as your files are on drive C.)
>>> That probably needs whatever magic will convert a cygwin path into a 
>>> DOS/NT path i.e. something starting with
>>>     C:\
>>> (note the backslash instead of a forwardslash)
>> No, things unfortunately appear to be more broken than that (at least 
>> with JDK 10.0.2):
>> * Using C:\foo\bar.jar pathnames in a jar's manifest class-path 
>> doesn't work (and 
>> <> 
>> does require those values to be "relative URLs").  At java run-time 
>> (e.g., when executing a JunitTest), resolving classes via that 
>> class-path entry apparently fails.
>> * Likewise when using C:/foo/bar.jar pathnames.
>> * Using file:/C:/foo/bar.jar URLs in a jar's manifest class-path would 
>> work at run-time.  However, when that jar is then mentioned in the 
>> -classpath argument of some javac invocation at build time, that 
>> invocation fails with "error: illegal argument for --class-path: 
>> Illegal char <:> at index 4: file:/C:/..."
>> * The only working hack I found for now is to use /foo/bar.jar 
>> drive-relative pathnames, which happen to also match the syntax of 
>> relative URLs.
> (see also the recent discussion at 
> <> "Simplify and fix Java UNO 
> API test makefiles")

(...and <> 
"Fix Java Jar dependency classpath to pass the ClassPathURLCheck")

More information about the LibreOffice mailing list