Bug 621992 – media-libs/libbluray-1.0.1 - configure: error: could not find jni.h

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Daniel Kenzelmann 2017-06-17 07:36:58 UTC]

when emerging libbluray the following error occurs:

checking jni.h usability... no
checking jni.h presence... no
checking for jni.h... no
configure: error: could not find jni.h

java system vm is oracle-jre-bin-1.8

use flags are:
[ebuild     U  ] media-libs/libbluray-1.0.1:0/2::gentoo [1.0.0:0/2::gentoo] USE="fontconfig truetype xml -aacs -bdplus -java -static-libs -utils (-udf%)" ABI_X86="32 (64) (-x32)"

jni.h seems to be present here:
/var/tmp/portage/media-libs/libbluray-1.0.1/work/libbluray-1.0.1/jni/jni.h
and here:
/usr/include/libavcodec/jni.h (from ffmpeg)




Reproducible: Always

[Comment 1 Daniel Kenzelmann 2017-06-17 07:37:40 UTC]

Created attachment 476724 [details]
emerge --info

[Comment 2 Daniel Kenzelmann 2017-06-17 07:39:07 UTC]

Created attachment 476726 [details]
config.log

[Comment 3 Markus Walter 2017-06-19 12:52:11 UTC]

I see the same issue on hardened ~amd64.

[Comment 4 Markus Walter 2017-06-29 08:44:20 UTC]

This does not occur with libbluray-1.0.0.

[Comment 5 Alex 2017-11-19 20:56:53 UTC]

Same here with libbluray-9999:

It wants jhi.h even when 'java' USE is unset (and 'bdjava' disabled during config).

Also it throws "unrecognized options" warning:

------------------------------------------------------------------------
/var/tmp/portage/media-libs/libbluray-9999/work/libbluray-9999/configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/libbluray-9999 --htmldir=/usr/share/doc/libbluray-9999/html --libdir=/usr/lib64 --disable-optimizations --disable-examples --disable-bdjava --with-fontconfig --with-freetype --disable-static --enable-udf --with-libxml2

configure: WARNING: unrecognized options: --disable-bdjava, --enable-udf
...
checking jni.h presence... no
checking for jni.h... no
configure: error: could not find jni.h
----------------------------------------------------------------------

Regards,
Akex

[Comment 6 Alex 2017-11-22 20:04:06 UTC]

UPD. Just to clarify several (probably already known) things:

1) '--disable-java' and '--disable-udf' configure options were removed upstream in 1.0.1: http://git.videolan.org/?p=libbluray.git;a=blob_plain;f=ChangeLog;hb=HEAD
AFAIK, UDF support is always on now.

2) Seems like 'jni.h' issue sits upstream, i.e. it fails even if libbluray without java is compiled directly from git master.

3) However, upstream source code has some 'jni.h' in 'libbluray/jni/' dir. I don't know why it doesn't want to use that jni.h

4) There's a workaround for it: a custom JDK_HOME var. E.g. in top source dir ('libbluray') symlink 'jni' dir to 'include' and run 'JDK_HOME=/tmp/libbluray/ ./configure --disable-bdjava-jar'.

5) It may throw an error "libudfread source tree not found". There's a workaround for it too https://github.com/jb-alvarado/media-autobuild_suite/issues/328 : 'git submodule update --init'

As last, after all the above manipulations it builds.
However, I'm not sure if it works.
Also looks like the libbluray-9999.ebuild is outdated a bit, at least for 'udf' and 'java' USE flags.

Regards,
Alex

[Comment 7 Andrew Udvare 2017-12-04 03:48:10 UTC]

Got this bug with USE="-java". The issue is that JDK_HOME is set. If JDK_HOME is unset before configuration, the library builds. This is because their configure.ac looks for JDK_HOME regardless of the --disable-bdjava-jar flag (which may no longer be valid).

https://git.videolan.org/?p=libbluray.git;a=blob;f=configure.ac;h=98a5226dd78e4753acddfe051930f73c1c118bd5;hb=c74d0319d92aea254c55daa36ecc441986e0219d#l212

I put this in multilib_src_configure():

if ! use java; then
    unset JDK_HOME
fi

[Comment 8 Pacho Ramos 2017-12-04 11:32:44 UTC]

I think we should unset it always for later allow java eclass to put the right value... also, it seems that ebuild is setting JDK_HOME on its own :/

[Comment 9 James Le Cuirot 2017-12-04 11:51:16 UTC]

(In reply to Pacho Ramos from comment #8)
> I think we should unset it always for later allow java eclass to put the
> right value... also, it seems that ebuild is setting JDK_HOME on its own :/

No time to look into this much immediately but at a glance, it shouldn't be necessary for the ebuild to set JDK_HOME. I'm thinking that perhaps java-pkg-opt-2.eclass should unset variables like JDK_HOME when the USE flag (java in this case) is not enabled to prevent this kind of thing happening elsewhere.

Also, in case it isn't clear, JREs don't include jni.h, only JDKs.

[Comment 10 Pacho Ramos 2017-12-16 12:28:42 UTC]

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8db7da2e6cbf969fd4bf267f0bb2d42a3b7e6e8e