Bug#750811: Bug#751532: Bug#750811: brltty: FTBFS on kfreebsd*
Control: severity 751532 important
Am 15.06.2014 20:43, schrieb Paul Gevers:
> On 15-06-14 17:31, Samuel Thibault wrote:
>> This is most probably similar to #714559 which had the same issue.
>
> Yes, I agree. But interestingly enough, building liblouisutdml already
> failed in gcc-4.8 while brltty (and libbluray) only now start to fail with
> gcc-4.9, so something must have changed.
on kfreebsd, gcj is used again as the default jdk. I think at some time I
provided s symlink pointing to linux/jni_md.h in openjdk so you don't see this
on architectures where java points to openjdk.
> Shouldn't the package for kfreebsd* have the files in a different
> sub-directory? linux just feels wrong on kfreebsd. I expect (but don't know
> for sure) that the resolver is smart enough to look in a sub-directory
> matching the os, but as I would expect not look in the directory named by a
> different os.
Both gcj and openjdk use the linux subdirectory on all posix architectures
upstream. I don't see why this should be changed just locally without
addressing this upstream.
so for now packages building jni bindings should have both <jdk_home>/include
and <jdk_home>/include/linux on the include path. brltty having kfreebsd-gnu
seems to be wrong in any case.
As a long term solution try to get this directory name defined upstream,
however I see this ending up as a wontfix issue ... so it seems to be better
to make sure that all packages use both include paths, and hardcoding the
second one as `linux' on all architectures.
Reply to: