[PATCH] Freetype Directory Bug On zLinux

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] Freetype Directory Bug On zLinux

Adam Farley8
Hi All,

On zLinux, freetype's .so file is typically installed in
/usr/lib/s390x-linux-gnu, however the generated configure script doesn't
look for it there.

This causes configure to fail. I know you can avoid that with options, but
I think a fix would be better.

If we add this code to lib-freetype.m4 (line 365) and re-run autogen.sh,
this fixes the problem.

if test "x$FOUND_FREETYPE" != xyes; then
   FREETYPE_BASE_DIR="$SYSROOT/usr"
   if test "x$OPENJDK_TARGET_CPU_ARCH" = xs390; then
      LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include],
[$FREETYPE_BASE_DIR/lib/s390x-linux-gnu], [well-known location])
   fi
fi

Thoughts?

Best Regards

Adam Farley

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Freetype Directory Bug On zLinux

John Paul Adrian Glaubitz
On 01/12/2018 03:29 PM, Adam Farley8 wrote:
> On zLinux, freetype's .so file is typically installed in
> /usr/lib/s390x-linux-gnu, however the generated configure script doesn't
> look for it there.

Odd. Normally I would expect it to look in the locations that are
set through /etc/ld.so.conf{,.d}

> This causes configure to fail. I know you can avoid that with options, but
> I think a fix would be better.
>
> If we add this code to lib-freetype.m4 (line 365) and re-run autogen.sh,
> this fixes the problem.
>
> if test "x$FOUND_FREETYPE" != xyes; then
>     FREETYPE_BASE_DIR="$SYSROOT/usr"
>     if test "x$OPENJDK_TARGET_CPU_ARCH" = xs390; then
>        LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include],
> [$FREETYPE_BASE_DIR/lib/s390x-linux-gnu], [well-known location])
>     fi
> fi
>
> Thoughts?

Seems like a workaround for an actual bug to me. Also, on Debian s390x,
the directory for shared libraries is also /usr/lib/s390x-linux-gnu:

glaubitz@zelenka:~$ ls -dl /usr/lib/s390x-linux-gnu
drwxr-xr-x 29 root root 28672 Dec 18 08:20 /usr/lib/s390x-linux-gnu
glaubitz@zelenka:~$

And I'm quite sure we don't have a quirk in the Debian openjdk package
in the form of a patch. So, I'm not sure why the configure doesn't work
in your case.

Adrian

--
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Freetype Directory Bug On zLinux

Adam Farley8
On 01/12/2018 03:29 PM, Adam Farley8 wrote:
>> On zLinux, freetype's .so file is typically installed in
>> /usr/lib/s390x-linux-gnu, however the generated configure script
doesn't
>> look for it there.
>
>Odd. Normally I would expect it to look in the locations that are
>set through /etc/ld.so.conf{,.d}

From the configure output, it appears to look for it in x86_64-linux-gnu
so I don't know what to tell you.

>
>> This causes configure to fail. I know you can avoid that with options,
but
>> I think a fix would be better.
>>
>> If we add this code to lib-freetype.m4 (line 365) and re-run
autogen.sh,

>> this fixes the problem.
>>
>> if test "x$FOUND_FREETYPE" != xyes; then
>>     FREETYPE_BASE_DIR="$SYSROOT/usr"
>>     if test "x$OPENJDK_TARGET_CPU_ARCH" = xs390; then
>>        LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include],
>> [$FREETYPE_BASE_DIR/lib/s390x-linux-gnu], [well-known location])
>>     fi
>> fi
>>
>> Thoughts?
>
>Seems like a workaround for an actual bug to me. Also, on Debian s390x,
>the directory for shared libraries is also /usr/lib/s390x-linux-gnu:
>
>glaubitz@zelenka:~$ ls -dl /usr/lib/s390x-linux-gnu
>drwxr-xr-x 29 root root 28672 Dec 18 08:20 /usr/lib/s390x-linux-gnu
>glaubitz@zelenka:~$
>
>And I'm quite sure we don't have a quirk in the Debian openjdk package
>in the form of a patch. So, I'm not sure why the configure doesn't work
>in your case.

When you run configure, do you use --disable-warnings-as-errors?
Like here: https://github.com/linux-on-ibm-z/docs/wiki/Building-OpenJDK
If you use that, the error goes away, and it doesn't seem to adversely
affect the build.

>
>Adrian
>
>--
>  .''`.  John Paul Adrian Glaubitz
>: :' :  Debian Developer - [hidden email]
>`. `'   Freie Universitaet Berlin - [hidden email]
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Freetype Directory Bug On zLinux

Erik Joelsson
In reply to this post by Adam Farley8
Hello Adam,

Configure already looks in:

$SYSROOT/usr/lib/$OPENJDK_TARGET_CPU-linux-gnu

Which I would expect to cover your case, unless there is a mismatch
between s390 and s390x here. Is your OPENJDK_TARGET_CPU set to s390 or
s390x in this case? If this discrepancy between arch names cannot be
resolved, then a special case like the one you propose is needed.

/Erik


On 2018-01-12 06:29, Adam Farley8 wrote:

> Hi All,
>
> On zLinux, freetype's .so file is typically installed in
> /usr/lib/s390x-linux-gnu, however the generated configure script doesn't
> look for it there.
>
> This causes configure to fail. I know you can avoid that with options, but
> I think a fix would be better.
>
> If we add this code to lib-freetype.m4 (line 365) and re-run autogen.sh,
> this fixes the problem.
>
> if test "x$FOUND_FREETYPE" != xyes; then
>     FREETYPE_BASE_DIR="$SYSROOT/usr"
>     if test "x$OPENJDK_TARGET_CPU_ARCH" = xs390; then
>        LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include],
> [$FREETYPE_BASE_DIR/lib/s390x-linux-gnu], [well-known location])
>     fi
> fi
>
> Thoughts?
>
> Best Regards
>
> Adam Farley
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Freetype Directory Bug On zLinux

John Paul Adrian Glaubitz
On 01/12/2018 06:03 PM, Erik Joelsson wrote:
> Which I would expect to cover your case, unless there is a mismatch between s390 and s390x here. Is your OPENJDK_TARGET_CPU set to s390 or s390x in this case? If this discrepancy between arch names cannot be resolved, then a special case like the one you propose is needed.
 From Adam's last mail it seems there is something wrong with his build
environment:

> From the configure output, it appears to look for it in x86_64-linux-gnu
> so I don't know what to tell you.

So, we need to figure out first the configure is looking in x86_64-linux-gnu
on the s390x environment.

Adrian

--
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Freetype Directory Bug On zLinux

Adam Farley8
Hi John, Erik,

-- Erik's comments --

>Configure already looks in:

>$SYSROOT/usr/lib/$OPENJDK_TARGET_CPU-linux-gnu

>Which I would expect to cover your case, unless there is a mismatch
>between s390 and s390x here. Is your OPENJDK_TARGET_CPU set to s390 or
>s390x in this case? If this discrepancy between arch names cannot be
>resolved, then a special case like the one you propose is needed.

My IF statement checks if OPENJDK_TARGET_CPU = s390. I have to assume that
means OPENJDK_TARGET_CPU is set to s390. Since the folder is
s390x-linux-gnu,
it's likely the extra x causing the problem.

As detailed below, s390x and s390 are both valid OPENJDK_TARGET_CPU
values,
according to the default generated_configure.sh file, so I think we need
to accomodate both if we want to continue supporting them. This appears
the
most straight-forward way to do that.

What do you think?

-- John's comments --

>> Which I would expect to cover your case, unless there is a mismatch
>>between s390 and s390x here. Is your OPENJDK_TARGET_CPU set to s390 or
>>s390x in this case? If this discrepancy between arch names cannot be
resolved,
>>then a special case like the one you propose is needed.
> From Adam's last mail it seems there is something wrong with his build
>environment:

Not as far as I can tell. In generated_configure.sh, both s390 and s390x
are
listed as valid OPENJDK_TARGET_CPU values.

I figure, if some code is looking for
$SYSROOT/usr/lib/$OPENJDK_TARGET_CPU-linux-gnu
as Erik suggests, it's the fact that the $OPENJDK_TARGET_CPU value is
s390, but
the folder name is s390x-linux-gnu (note the extra x) that's causing this.

>> From the configure output, it appears to look for it in
x86_64-linux-gnu
>> so I don't know what to tell you.

>So, we need to figure out first the configure is looking in
x86_64-linux-gnu
>on the s390x environment.

There's a bunch of IF statements in lib-freetype.m4 that appear to check
platform-specific freetype locations sequentially, regardless of whether
we have
any evidence that we're on that platform. Hence my addition to that list
of IF
statements.

Best Regards

Adam Farley



From:   John Paul Adrian Glaubitz <[hidden email]>
To:     Erik Joelsson <[hidden email]>, Adam Farley8
<[hidden email]>, [hidden email]
Date:   12/01/2018 17:29
Subject:        Re: [PATCH] Freetype Directory Bug On zLinux



On 01/12/2018 06:03 PM, Erik Joelsson wrote:
> Which I would expect to cover your case, unless there is a mismatch
between s390 and s390x here. Is your OPENJDK_TARGET_CPU set to s390 or
s390x in this case? If this discrepancy between arch names cannot be
resolved, then a special case like the one you propose is needed.
 From Adam's last mail it seems there is something wrong with his build
environment:

> From the configure output, it appears to look for it in x86_64-linux-gnu
> so I don't know what to tell you.

So, we need to figure out first the configure is looking in
x86_64-linux-gnu
on the s390x environment.

Adrian

--
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Freetype Directory Bug On zLinux

John Paul Adrian Glaubitz
Hi Adam!

On 01/15/2018 06:15 PM, Adam Farley8 wrote:
>>Which I would expect to cover your case, unless there is a mismatch
>>between s390 and s390x here. Is your OPENJDK_TARGET_CPU set to s390 or
>>s390x in this case? If this discrepancy between arch names cannot be
>>resolved, then a special case like the one you propose is needed.
>
> My IF statement checks if OPENJDK_TARGET_CPU = s390. I have to assume that
> means OPENJDK_TARGET_CPU is set to s390. Since the folder is s390x-linux-gnu,
> it's likely the extra x causing the problem.

I have just done a fresh clone of OpenJDK-11 from jdk/hs and performed test
builds on Debian/s390x with the following configure lines:

Server:

CONF=linux-s390x-normal-server-release make clean ; CONF=linux-s390x-normal-server-release MAKE_VERBOSE=y QUIETLY= LOG=debug sh ./configure
--with-jvm-variants=server --with-boot-jdk=/usr/lib/jvm/java-9-openjdk-s390x/ --disable-precompiled-headers --disable-warnings-as-errors && make JOBS=32
MAKE_VERBOSE=y QUIETLY= LOG=debug CONF=linux-s390x-normal-server-release

Zero:

CONF=linux-s390x-normal-zero-release MAKE_VERBOSE=y QUIETLY= LOG=debug make clean CONF=linux-s390x-normal-zero-release ; sh ./configure --with-jvm-variants=zero
--with-boot-jdk=/usr/lib/jvm/java-9-openjdk-s390x/ --disable-precompiled-headers --disable-warnings-as-errors && make JOBS=32 MAKE_VERBOSE=y QUIETLY= LOG=debug
CONF=linux-s390x-normal-zero-release

Both builds succeed without any issues, so I'm not sure there isn't something
wrong with your build environment. For reference, Debian/s390x has the freetype
runtime and development library components in /usr/lib/s390x-linux-gnu:

(sid_s390x-dchroot)glaubitz@zelenka:~/openjdk/hs$ dpkg -L libfreetype6:s390x |grep s390 && dpkg -L libfreetype6-dev:s390x |grep s390
/usr/lib/s390x-linux-gnu
/usr/lib/s390x-linux-gnu/libfreetype.so.6.15.0
/usr/lib/s390x-linux-gnu/libfreetype.so.6
/usr/lib/s390x-linux-gnu
/usr/lib/s390x-linux-gnu/libfreetype.a
/usr/lib/s390x-linux-gnu/libfreetype.la
/usr/lib/s390x-linux-gnu/pkgconfig
/usr/lib/s390x-linux-gnu/pkgconfig/freetype2.pc
/usr/lib/s390x-linux-gnu/libfreetype.so
(sid_s390x-dchroot)glaubitz@zelenka:~/openjdk/hs$

Can you post your configure lines?

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Freetype Directory Bug On zLinux

Severin Gehwolf
Hi,

On Mon, 2018-01-15 at 20:21 +0100, John Paul Adrian Glaubitz wrote:

> Hi Adam!
>
> On 01/15/2018 06:15 PM, Adam Farley8 wrote:
> > > Which I would expect to cover your case, unless there is a
> > > mismatch
> > > between s390 and s390x here. Is your OPENJDK_TARGET_CPU set to
> > > s390 or
> > > s390x in this case? If this discrepancy between arch names cannot
> > > be
> > > resolved, then a special case like the one you propose is needed.
> >
> > My IF statement checks if OPENJDK_TARGET_CPU = s390. I have to
> > assume that
> > means OPENJDK_TARGET_CPU is set to s390. Since the folder is s390x-
> > linux-gnu,
> > it's likely the extra x causing the problem.
>
> I have just done a fresh clone of OpenJDK-11 from jdk/hs and
> performed test
> builds on Debian/s390x with the following configure lines:
>
> Server:
>
> CONF=linux-s390x-normal-server-release make clean ; CONF=linux-s390x-
> normal-server-release MAKE_VERBOSE=y QUIETLY= LOG=debug sh
> ./configure
> --with-jvm-variants=server --with-boot-jdk=/usr/lib/jvm/java-9-
> openjdk-s390x/ --disable-precompiled-headers --disable-warnings-as-
> errors && make JOBS=32
> MAKE_VERBOSE=y QUIETLY= LOG=debug CONF=linux-s390x-normal-server-
> release
>
> Zero:
>
> CONF=linux-s390x-normal-zero-release MAKE_VERBOSE=y QUIETLY=
> LOG=debug make clean CONF=linux-s390x-normal-zero-release ; sh
> ./configure --with-jvm-variants=zero
> --with-boot-jdk=/usr/lib/jvm/java-9-openjdk-s390x/ --disable-
> precompiled-headers --disable-warnings-as-errors && make JOBS=32
> MAKE_VERBOSE=y QUIETLY= LOG=debug
> CONF=linux-s390x-normal-zero-release
>
> Both builds succeed without any issues, so I'm not sure there isn't
> something
> wrong with your build environment. For reference, Debian/s390x has
> the freetype
> runtime and development library components in /usr/lib/s390x-linux-
> gnu:
>
> (sid_s390x-dchroot)glaubitz@zelenka:~/openjdk/hs$ dpkg -L
> libfreetype6:s390x |grep s390 && dpkg -L libfreetype6-dev:s390x |grep
> s390
> /usr/lib/s390x-linux-gnu
> /usr/lib/s390x-linux-gnu/libfreetype.so.6.15.0
> /usr/lib/s390x-linux-gnu/libfreetype.so.6
> /usr/lib/s390x-linux-gnu
> /usr/lib/s390x-linux-gnu/libfreetype.a
> /usr/lib/s390x-linux-gnu/libfreetype.la
> /usr/lib/s390x-linux-gnu/pkgconfig
> /usr/lib/s390x-linux-gnu/pkgconfig/freetype2.pc
> /usr/lib/s390x-linux-gnu/libfreetype.so
> (sid_s390x-dchroot)glaubitz@zelenka:~/openjdk/hs$
>
> Can you post your configure lines?

FYI:

Adam mentioned in another thread[1] that --disable-warnings-as-errors
to configure makes the error go away.

Thanks,
Severin

[1] http://mail.openjdk.java.net/pipermail/build-dev/2018-January/020616.html
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Freetype Directory Bug On zLinux

Adam Farley8
Hi All,

>
>On Mon, 2018-01-15 at 20:21 +0100, John Paul Adrian Glaubitz wrote:
>> Hi Adam!
>>
>> On 01/15/2018 06:15 PM, Adam Farley8 wrote:
>> > > Which I would expect to cover your case, unless there is a
>> > > mismatch
>> > > between s390 and s390x here. Is your OPENJDK_TARGET_CPU set to
>> > > s390 or
>> > > s390x in this case? If this discrepancy between arch names cannot
>> > > be
>> > > resolved, then a special case like the one you propose is needed.
>> >
>> > My IF statement checks if OPENJDK_TARGET_CPU = s390. I have to
>> > assume that
>> > means OPENJDK_TARGET_CPU is set to s390. Since the folder is s390x-
>> > linux-gnu,
>> > it's likely the extra x causing the problem.
>>
>> I have just done a fresh clone of OpenJDK-11 from jdk/hs and
>> performed test
>> builds on Debian/s390x with the following configure lines:
>>
>> Server:
>>
>> CONF=linux-s390x-normal-server-release make clean ; CONF=linux-s390x-
>> normal-server-release MAKE_VERBOSE=y QUIETLY= LOG=debug sh
>> ./configure
>> --with-jvm-variants=server --with-boot-jdk=/usr/lib/jvm/java-9-
>> openjdk-s390x/ --disable-precompiled-headers --disable-warnings-as-
>> errors && make JOBS=32
>> MAKE_VERBOSE=y QUIETLY= LOG=debug CONF=linux-s390x-normal-server-
>> release
>>
>> Zero:
>>
>> CONF=linux-s390x-normal-zero-release MAKE_VERBOSE=y QUIETLY=
>> LOG=debug make clean CONF=linux-s390x-normal-zero-release ; sh
>> ./configure --with-jvm-variants=zero
>> --with-boot-jdk=/usr/lib/jvm/java-9-openjdk-s390x/ --disable-
>> precompiled-headers --disable-warnings-as-errors && make JOBS=32
>> MAKE_VERBOSE=y QUIETLY= LOG=debug
>> CONF=linux-s390x-normal-zero-release
>>
>> Both builds succeed without any issues, so I'm not sure there isn't
>> something
>> wrong with your build environment. For reference, Debian/s390x has
>> the freetype
>> runtime and development library components in /usr/lib/s390x-linux-
>> gnu:
>>
>> (sid_s390x-dchroot)glaubitz@zelenka:~/openjdk/hs$ dpkg -L
>> libfreetype6:s390x |grep s390 && dpkg -L libfreetype6-dev:s390x |grep
>> s390
>> /usr/lib/s390x-linux-gnu
>> /usr/lib/s390x-linux-gnu/libfreetype.so.6.15.0
>> /usr/lib/s390x-linux-gnu/libfreetype.so.6
>> /usr/lib/s390x-linux-gnu
>> /usr/lib/s390x-linux-gnu/libfreetype.a
>> /usr/lib/s390x-linux-gnu/libfreetype.la
>> /usr/lib/s390x-linux-gnu/pkgconfig
>> /usr/lib/s390x-linux-gnu/pkgconfig/freetype2.pc
>> /usr/lib/s390x-linux-gnu/libfreetype.so
>> (sid_s390x-dchroot)glaubitz@zelenka:~/openjdk/hs$
>>
>> Can you post your configure lines?

bash ./configure

Though now the problem has suddenly vanished. I don't know why. :(

Will continue to poke at this.

>
>FYI:
>
>Adam mentioned in another thread[1] that --disable-warnings-as-errors
>to configure makes the error go away.
>
>Thanks,
>Severin
>

And thank you for mentioning that. :)

>Hello Adam,

>Configure already looks in:

>$SYSROOT/usr/lib/$OPENJDK_TARGET_CPU-linux-gnu

>Which I would expect to cover your case, unless there is a mismatch
>between s390 and s390x here. Is your OPENJDK_TARGET_CPU set to s390 or
>s390x in this case? If this discrepancy between arch names cannot be
>resolved, then a special case like the one you propose is needed.

>/Erik

I have tried and tried, and cannot find this code line in the JDK,
anywhere. Nor can I find variations on it. The closest I can find is a
list of possible locations, but these are hard-coded (and don't have
OPENJDK_TARGET_CPU in their code), and none are s390 or s390x.

Please spell out exactly where this line is, as I have no idea.

Thanks everyone for your time. We'll get to the bottom of this! :)

Best Regards

Adam Farley

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Freetype Directory Bug On zLinux

Erik Joelsson


On 2018-01-16 09:03, Adam Farley8 wrote:

> >Configure already looks in:
>
> >$SYSROOT/usr/lib/$OPENJDK_TARGET_CPU-linux-gnu
>
> >Which I would expect to cover your case, unless there is a mismatch
> >between s390 and s390x here. Is your OPENJDK_TARGET_CPU set to s390 or
> >s390x in this case? If this discrepancy between arch names cannot be
> >resolved, then a special case like the one you propose is needed.
>
> I have tried and tried, and cannot find this code line in the JDK,
> anywhere. Nor can I find variations on it. The closest I can find is a
> list of possible locations, but these are hard-coded (and don't have
> OPENJDK_TARGET_CPU in their code), and none are s390 or s390x.
>
> Please spell out exactly where this line is, as I have no idea.
>
I'm referring to this block:

           if test "x$FOUND_FREETYPE" != xyes; then
             FREETYPE_BASE_DIR="$SYSROOT/usr"
             if test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include],
[$FREETYPE_BASE_DIR/lib/$OPENJDK_TARGET_CPU-linux-gnu], [well-known
location])
             else
LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include],
[$FREETYPE_BASE_DIR/lib/i386-linux-gnu], [well-known location])
               if test "x$FOUND_FREETYPE" != xyes; then
LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include],
[$FREETYPE_BASE_DIR/lib32], [well-known location])
               fi
             fi
           fi

Reading it again I realize that the directory is only searched for 64bit
builds. Looking in platforms.m4, I see that s390 is 32bit and s390x is
64bit. This means it will work fine for s390x, but not for s390. Given
that your libraries are found in a directory with s390x in the name, I
assume that you actually do want to produce a 64bit build, or am I
missing something? If you need this to work for 32bit, then it's
possible we need to tweak something. I think it wouldn't be such a bad
idea to always search $SYSROOT/usr/lib/$OPENJDK_TARGET_CPU-linux-gnu,
regardless of architecture.

Also note that your proposed code checked for
OPENJDK_TARGET_CPU_ARCH=s390, that's a different variable than
OPENJDK_TARGET_CPU. The arch in our model is more of a family of cpus,
ignoring things like address width.

/Erik

> Thanks everyone for your time. We'll get to the bottom of this! :)
>
> Best Regards
>
> Adam Farley
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Freetype Directory Bug On zLinux

Erik Joelsson


On 2018-01-16 09:50, Erik Joelsson wrote:

>
>
> On 2018-01-16 09:03, Adam Farley8 wrote:
>> >Configure already looks in:
>>
>> >$SYSROOT/usr/lib/$OPENJDK_TARGET_CPU-linux-gnu
>>
>> >Which I would expect to cover your case, unless there is a mismatch
>> >between s390 and s390x here. Is your OPENJDK_TARGET_CPU set to s390 or
>> >s390x in this case? If this discrepancy between arch names cannot be
>> >resolved, then a special case like the one you propose is needed.
>>
>> I have tried and tried, and cannot find this code line in the JDK,
>> anywhere. Nor can I find variations on it. The closest I can find is a
>> list of possible locations, but these are hard-coded (and don't have
>> OPENJDK_TARGET_CPU in their code), and none are s390 or s390x.
>>
>> Please spell out exactly where this line is, as I have no idea.
>>
> I'm referring to this block:
>
>           if test "x$FOUND_FREETYPE" != xyes; then
>             FREETYPE_BASE_DIR="$SYSROOT/usr"
>             if test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
> LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include],
> [$FREETYPE_BASE_DIR/lib/$OPENJDK_TARGET_CPU-linux-gnu], [well-known
> location])
>             else
> LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include],
> [$FREETYPE_BASE_DIR/lib/i386-linux-gnu], [well-known location])
>               if test "x$FOUND_FREETYPE" != xyes; then
> LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include],
> [$FREETYPE_BASE_DIR/lib32], [well-known location])
>               fi
>             fi
>           fi
>
> Reading it again I realize that the directory is only searched for
> 64bit builds. Looking in platforms.m4, I see that s390 is 32bit and
> s390x is 64bit. This means it will work fine for s390x, but not for
> s390. Given that your libraries are found in a directory with s390x in
> the name, I assume that you actually do want to produce a 64bit build,
> or am I missing something? If you need this to work for 32bit, then
> it's possible we need to tweak something. I think it wouldn't be such
> a bad idea to always search
> $SYSROOT/usr/lib/$OPENJDK_TARGET_CPU-linux-gnu, regardless of
> architecture.
>
Are the libraries in your s390x directory 32bit or 64bit? Am I correct
in assuming that the x suffix is signifying 64bit instead of 32bit?

/Erik

> Also note that your proposed code checked for
> OPENJDK_TARGET_CPU_ARCH=s390, that's a different variable than
> OPENJDK_TARGET_CPU. The arch in our model is more of a family of cpus,
> ignoring things like address width.
>
> /Erik
>
>> Thanks everyone for your time. We'll get to the bottom of this! :)
>>
>> Best Regards
>>
>> Adam Farley
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with
>> number 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>> PO6 3AU
>

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Freetype Directory Bug On zLinux

Magnus Ihse Bursie
On 2018-01-16 18:54, Erik Joelsson wrote:

>
>
> On 2018-01-16 09:50, Erik Joelsson wrote:
>>
>>
>> On 2018-01-16 09:03, Adam Farley8 wrote:
>>> >Configure already looks in:
>>>
>>> >$SYSROOT/usr/lib/$OPENJDK_TARGET_CPU-linux-gnu
>>>
>>> >Which I would expect to cover your case, unless there is a mismatch
>>> >between s390 and s390x here. Is your OPENJDK_TARGET_CPU set to s390 or
>>> >s390x in this case? If this discrepancy between arch names cannot be
>>> >resolved, then a special case like the one you propose is needed.
>>>
>>> I have tried and tried, and cannot find this code line in the JDK,
>>> anywhere. Nor can I find variations on it. The closest I can find is a
>>> list of possible locations, but these are hard-coded (and don't have
>>> OPENJDK_TARGET_CPU in their code), and none are s390 or s390x.
>>>
>>> Please spell out exactly where this line is, as I have no idea.
>>>
>> I'm referring to this block:
>>
>>           if test "x$FOUND_FREETYPE" != xyes; then
>>             FREETYPE_BASE_DIR="$SYSROOT/usr"
>>             if test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
>> LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include],
>> [$FREETYPE_BASE_DIR/lib/$OPENJDK_TARGET_CPU-linux-gnu], [well-known
>> location])
>>             else
>> LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include],
>> [$FREETYPE_BASE_DIR/lib/i386-linux-gnu], [well-known location])
>>               if test "x$FOUND_FREETYPE" != xyes; then
>> LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include],
>> [$FREETYPE_BASE_DIR/lib32], [well-known location])
>>               fi
>>             fi
>>           fi
>>
>> Reading it again I realize that the directory is only searched for
>> 64bit builds. Looking in platforms.m4, I see that s390 is 32bit and
>> s390x is 64bit. This means it will work fine for s390x, but not for
>> s390. Given that your libraries are found in a directory with s390x
>> in the name, I assume that you actually do want to produce a 64bit
>> build, or am I missing something? If you need this to work for 32bit,
>> then it's possible we need to tweak something. I think it wouldn't be
>> such a bad idea to always search
>> $SYSROOT/usr/lib/$OPENJDK_TARGET_CPU-linux-gnu, regardless of
>> architecture.
>>
> Are the libraries in your s390x directory 32bit or 64bit? Am I correct
> in assuming that the x suffix is signifying 64bit instead of 32bit?
Yes, s390x means 64-bit. We do not support 32-bit s390, so I don't think
it's likely that Adam was trying to build that.

Just like we sometimes just say "sparc" when we really mean "sparcv9", I
presume that "s390" here really mean "s390x".

I'm guessing that the config.guess script (and our wrapper) perhaps is
not 100% correct in determining s390x. It has certainly not seen much
testing.

/Magnus

>
> /Erik
>> Also note that your proposed code checked for
>> OPENJDK_TARGET_CPU_ARCH=s390, that's a different variable than
>> OPENJDK_TARGET_CPU. The arch in our model is more of a family of
>> cpus, ignoring things like address width.
>>
>> /Erik
>>
>>> Thanks everyone for your time. We'll get to the bottom of this! :)
>>>
>>> Best Regards
>>>
>>> Adam Farley
>>>
>>> Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with
>>> number 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>>> PO6 3AU
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Freetype Directory Bug On zLinux

Adam Farley8
>On 2018-01-16 18:54, Erik Joelsson wrote:
>>
>>
>> On 2018-01-16 09:50, Erik Joelsson wrote:
>>>
>>>
>>> On 2018-01-16 09:03, Adam Farley8 wrote:
>>>> >Configure already looks in:
>>>>
>>>> >$SYSROOT/usr/lib/$OPENJDK_TARGET_CPU-linux-gnu
>>>>
>>>> >Which I would expect to cover your case, unless there is a mismatch
>>>> >between s390 and s390x here. Is your OPENJDK_TARGET_CPU set to s390
or
>>>> >s390x in this case? If this discrepancy between arch names cannot be
>>>> >resolved, then a special case like the one you propose is needed.
>>>>
>>>> I have tried and tried, and cannot find this code line in the JDK,
>>>> anywhere. Nor can I find variations on it. The closest I can find is
a

>>>> list of possible locations, but these are hard-coded (and don't have
>>>> OPENJDK_TARGET_CPU in their code), and none are s390 or s390x.
>>>>
>>>> Please spell out exactly where this line is, as I have no idea.
>>>>
>>> I'm referring to this block:
>>>
>>>           if test "x$FOUND_FREETYPE" != xyes; then
>>>             FREETYPE_BASE_DIR="$SYSROOT/usr"
>>>             if test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
>>> LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include],
>>> [$FREETYPE_BASE_DIR/lib/$OPENJDK_TARGET_CPU-linux-gnu], [well-known
>>> location])
>>>             else
>>> LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include],
>>> [$FREETYPE_BASE_DIR/lib/i386-linux-gnu], [well-known location])
>>>               if test "x$FOUND_FREETYPE" != xyes; then
>>> LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include],
>>> [$FREETYPE_BASE_DIR/lib32], [well-known location])
>>>               fi
>>>             fi
>>>           fi

I'm embarassed that it took me this long to figure out you were referring
to the jdk10 code. I was scouring my copy of the jdk9 source and wondering
what on earth you were talking about. Whoops. :)

>>>
>>> Reading it again I realize that the directory is only searched for
>>> 64bit builds. Looking in platforms.m4, I see that s390 is 32bit and
>>> s390x is 64bit. This means it will work fine for s390x, but not for
>>> s390. Given that your libraries are found in a directory with s390x
>>> in the name, I assume that you actually do want to produce a 64bit
>>> build, or am I missing something? If you need this to work for 32bit,
>>> then it's possible we need to tweak something. I think it wouldn't be
>>> such a bad idea to always search
>>> $SYSROOT/usr/lib/$OPENJDK_TARGET_CPU-linux-gnu, regardless of
>>> architecture.
>>>
>> Are the libraries in your s390x directory 32bit or 64bit? Am I correct
>> in assuming that the x suffix is signifying 64bit instead of 32bit?
>Yes, s390x means 64-bit. We do not support 32-bit s390, so I don't think
>it's likely that Adam was trying to build that.
>
>Just like we sometimes just say "sparc" when we really mean "sparcv9", I
>presume that "s390" here really mean "s390x".
>
>I'm guessing that the config.guess script (and our wrapper) perhaps is
>not 100% correct in determining s390x. It has certainly not seen much
>testing.

For some reason my code now works perfectly. I am 100% certain that this
defect was occuring before I installed a selection of packages on the
machine, so I figure one of these, or something else I did, resulted
in the correct s390x being passed.

I'll try to figure out what has happened.

P.S. I'm trying to build s390x (64bit) on a 64bit machine. I don't know
where the code was getting s390.

>
>/Magnus
>
>>
>> /Erik
>>> Also note that your proposed code checked for
>>> OPENJDK_TARGET_CPU_ARCH=s390, that's a different variable than
>>> OPENJDK_TARGET_CPU. The arch in our model is more of a family of
>>> cpus, ignoring things like address width.
>>>
>>> /Erik
>>>
>>>> Thanks everyone for your time. We'll get to the bottom of this! :)
>>>>
>>>> Best Regards
>>>>
>>>> Adam Farley

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Freetype Directory Bug On zLinux

Adam Farley8
In reply to this post by Magnus Ihse Bursie
Hi All,

In JDK9 on zLinux 64bit, it seems we don't look for libfreetype.so
in /usr/lib/$OPENJDK_TARGET_CPU-linux-gnu by default.

If you DO have pkg-config, "configure" searches for freetype in
several places, including a place relative to gcc,
(gcc/../../etc) where it uses the correct folder name and finds
libfreetype.so.

If you DON'T have pkg-config, it searches a few places, gets
desperate, and ends up in a 64bit-only if statement (where it
assumes it's running on intel linux and fails trying to check
x86_64-linux-gnu).

As far as I can tell, this is a build bug, and can be fixed
in one of three ways:

1) We add the aforementioned IF statement, effectively adding
/usr/lib/s390x-linux-gnu to the list of places configure looks
for libfreetype.so

2) We add something into the configure files that checks for
the presence of pkg-config before we look for freetype, if
only on zlinux.

3) We backport the jdk10 solution, or a simplified version of it.

Note that we may need to fix the 64bit-only if statement anyway,
as there are many 64-bit locations that are not 64bit linux.

Thoughts?

Best Regards

Adam Farley

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU