[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: