GNOME Bugzilla – Bug 737124
java-atk-wrapper: make distcheck doesn't works
Last modified: 2021-05-17 15:40:00 UTC
STEPS TO REPRODUCE autogen.sh & make & make distcheck OUTPUT: make[4]: Entering directory '/mnt/data/source/java-atk-wrapper/java-atk-wrapper-0.30.5/_build/jni/src' /bin/sh ../../libtool --tag=CC --mode=compile ccache gcc -DHAVE_CONFIG_H -I. -I../../../jni/src -I../.. -I/include -I/include/linux -pthread -I/opt/gnome3/include/atk-1.0 -I/opt/gnome3/include/gtk-2.0 -I/opt/gnome3/lib/gtk-2.0/include -I/opt/gnome3/include/pango-1.0 -I/opt/gnome3/include/cairo -I/opt/gnome3/include/gdk-pixbuf-2.0 -I/opt/gnome3/include/glib-2.0 -I/opt/gnome3/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/libpng16 -I/usr/include/gconf/2 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -DATK_BRIDGE_LIB_PATH=\"/opt/gnome3/lib/gtk-2.0\" -g -O2 -MT libatk_wrapper_la-AtkWrapper.lo -MD -MP -MF .deps/libatk_wrapper_la-AtkWrapper.Tpo -c -o libatk_wrapper_la-AtkWrapper.lo `test -f 'AtkWrapper.c' || echo '../../../jni/src/'`AtkWrapper.c libtool: compile: ccache gcc -DHAVE_CONFIG_H -I. -I../../../jni/src -I../.. -I/include -I/include/linux -pthread -I/opt/gnome3/include/atk-1.0 -I/opt/gnome3/include/gtk-2.0 -I/opt/gnome3/lib/gtk-2.0/include -I/opt/gnome3/include/pango-1.0 -I/opt/gnome3/include/cairo -I/opt/gnome3/include/gdk-pixbuf-2.0 -I/opt/gnome3/include/glib-2.0 -I/opt/gnome3/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/libpng16 -I/usr/include/gconf/2 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -DATK_BRIDGE_LIB_PATH=\"/opt/gnome3/lib/gtk-2.0\" -g -O2 -MT libatk_wrapper_la-AtkWrapper.lo -MD -MP -MF .deps/libatk_wrapper_la-AtkWrapper.Tpo -c ../../../jni/src/AtkWrapper.c -fPIC -DPIC -o .libs/libatk_wrapper_la-AtkWrapper.o ../../../jni/src/AtkWrapper.c:20:17: fatal error: jni.h: No such file or directory #include <jni.h> ^ compilation terminated. Makefile:489: recipe for target 'libatk_wrapper_la-AtkWrapper.lo' failed NOTES: Although right now not all GNOME modules pass the make distcheck, in general is a good thing to keep it working. make distcheck packs the source code on a tarball, and automatically checks that the content of the tarball properly builds. So it is a good check to do before uploading the release. For example, it helps to check that all the needed files are included on the tarball. It is even included as a step on the general guide to make GNOME releases [1]. [1] https://wiki.gnome.org/MaintainersCorner/Releasing
The problem seems to be that these files are in a weird include folder that is not included when the thing is compiled. Adding the following to ~/.bashrc seemed to fix this and a second similar problem which came up: export C_INCLUDE_PATH=/usr/java/jdk1.8.0_05/include:/usr/java/jdk1.8.0_05/include/linux I guess it's just a case of compiling with these includes. I'll see about adding them to the appropriate compile script.
Ah no, the problem is not that. Things seems to be set up right[1] However it seems to be caused by the JDK_HOME constant not being set. [1] https://git.gnome.org/browse/java-atk-wrapper/tree/acinclude.m4
Ok I figured it out: the file JavaInfo.java looks for system files only. Basically autogen.sh & make & make distcheck does work, but it only works as root. The constant JAVA_HOME is quite misleading knowing that. I think that it might be best to configure a way to install do this from the home directory too but first off I might rename JAVA_HOME to something like JAVA_SRC so it's not misleading. I'll check that is not already being used for something else.
Changed JDK_HOME to JDK_SRC https://bugzilla.gnome.org/show_bug.cgi?id=738730
Changed JAVA_HOME to JRE_SRC https://bugzilla.gnome.org/show_bug.cgi?id=738731 Now, to figure out what to do with JavaInfo.java for home installs...
I am not sure what fixed this exactly, but it does seem to be fixed now. Could you confirm that it is the same for you?
(In reply to comment #6) > I am not sure what fixed this exactly, but it does seem to be fixed now. Could > you confirm that it is the same for you? Sorry, I was mistaken here. It turns out make distcheck only works if run after the following command jhbuild buildone java-atk-wrapper. I think the problem is caused by the default prefix for autogen.sh and configure and their associated permissions.
(In reply to comment #7) > (In reply to comment #6) > > I am not sure what fixed this exactly, but it does seem to be fixed now. Could > > you confirm that it is the same for you? > > Sorry, I was mistaken here. It turns out make distcheck only works if run after > the following command > > jhbuild buildone java-atk-wrapper. > > I think the problem is caused by the default prefix for autogen.sh and > configure and their associated permissions. For me, make distcheck also fails after a 'jhbuild buildone java-atk-wrapper'
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > I am not sure what fixed this exactly, but it does seem to be fixed now. Could > > > you confirm that it is the same for you? > > > > Sorry, I was mistaken here. It turns out make distcheck only works if run after > > the following command > > > > jhbuild buildone java-atk-wrapper. > > > > I think the problem is caused by the default prefix for autogen.sh and > > configure and their associated permissions. > > For me, make distcheck also fails after a 'jhbuild buildone java-atk-wrapper' Yes, I see you are correct sorry I must have not been paying proper attention in that case. I think this is a high priority to solve and I suspect it just needs the includes to be set up right so they can find the run time environment without needing to be in a root shell. Some of the stuff that is already in configure.ac confuses me but a patch is not too far off.
On looking into it further, I am no longer sure this is actually a bug we want to fix. It's apparent that java security updates in version 7 are responsible for this problem. Basically it comes down to what happens in this makefile: https://git.gnome.org/browse/java-atk-wrapper/tree/wrapper/org/GNOME/Accessibility/Makefile.am I think because distcheck only has read permissions it causes the java stuff that would normally work to fail yet for security reasons, I am not sure we want to change the permissions, essentially.
(In reply to comment #10) > On looking into it further, I am no longer sure this is actually a bug we want > to fix. It's apparent that java security updates in version 7 are responsible > for this problem. ../../../jni/src/AtkWrapper.c:20:17: fatal error: jni.h: No such file or directory #include <jni.h> ^ compilation terminated. make[4]: *** [libatk_wrapper_la-AtkWrapper.lo] Error 1 make[4]: Leaving directory `/mnt/smalldata/source/java-atk-wrapper/java-atk-wrapper-0.30.9/_build/jni/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/mnt/smalldata/source/java-atk-wrapper/java-atk-wrapper-0.30.9/_build/jni' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/mnt/smalldata/source/java-atk-wrapper/java-atk-wrapper-0.30.9/_build' make[1]: *** [all] Error 2 make[1]: Leaving directory `/mnt/smalldata/source/java-atk-wrapper/java-atk-wrapper-0.30.9/_build' make: *** [distcheck] Error 1 [jhbuild-devel]@atanagildo:~/source/java-atk-wrapper$ dpkg -l | grep openjdk ii openjdk-6-jdk:amd64 6b33-1.13.5-1ubuntu0.14.04 amd64 OpenJDK Development Kit (JDK) ii openjdk-6-jre:amd64 6b33-1.13.5-1ubuntu0.14.04 amd64 OpenJDK Java runtime, using Hotspot JIT ii openjdk-6-jre-headless:amd64 6b33-1.13.5-1ubuntu0.14.04 amd64 OpenJDK Java runtime, using Hotspot JIT (headless) ii openjdk-6-jre-lib 6b33-1.13.5-1ubuntu0.14.04 all OpenJDK Java runtime (architecture independent libraries) The same error happens to me is using java 6
(In reply to comment #11) > (In reply to comment #10) > > On looking into it further, I am no longer sure this is actually a bug we want > > to fix. It's apparent that java security updates in version 7 are responsible > > for this problem. > ../../../jni/src/AtkWrapper.c:20:17: fatal error: jni.h: No such file or > directory > #include <jni.h> > ^ > compilation terminated. > make[4]: *** [libatk_wrapper_la-AtkWrapper.lo] Error 1 > make[4]: Leaving directory > `/mnt/smalldata/source/java-atk-wrapper/java-atk-wrapper-0.30.9/_build/jni/src' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory > `/mnt/smalldata/source/java-atk-wrapper/java-atk-wrapper-0.30.9/_build/jni' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > `/mnt/smalldata/source/java-atk-wrapper/java-atk-wrapper-0.30.9/_build' > make[1]: *** [all] Error 2 > make[1]: Leaving directory > `/mnt/smalldata/source/java-atk-wrapper/java-atk-wrapper-0.30.9/_build' > make: *** [distcheck] Error 1 > [jhbuild-devel]@atanagildo:~/source/java-atk-wrapper$ dpkg -l | grep openjdk > ii openjdk-6-jdk:amd64 > 6b33-1.13.5-1ubuntu0.14.04 amd64 OpenJDK > Development Kit (JDK) > ii openjdk-6-jre:amd64 > 6b33-1.13.5-1ubuntu0.14.04 amd64 OpenJDK Java > runtime, using Hotspot JIT > ii openjdk-6-jre-headless:amd64 > 6b33-1.13.5-1ubuntu0.14.04 amd64 OpenJDK Java > runtime, using Hotspot JIT (headless) > ii openjdk-6-jre-lib > 6b33-1.13.5-1ubuntu0.14.04 all OpenJDK Java > runtime (architecture independent libraries) > > The same error happens to me is using java 6 Yeah the same principle applies though. I just tried running; make dist then manually running the make commands on it. There is a bug on make install which does not appear when I run build with jhbuild so I am pretty sure there is still something wrong with the way prefixes libraries and includes are set up but I am pretty sure that bug is not responsible for this one now. This bug is basically because the jar file that is generated is read-only in a discheck where it needs to not be for the discheck to pass and finding jni is a symptom rater than a cause. If you scroll up a bit in the discheck console log you'll see this and that's where it starts, I think: ../JavaInfo.java:1: error: error while writing JavaInfo: ../JavaInfo.class (Permission denied) public class JavaInfo { ^ 1 error Maybe I should leave this bug open and see about fixing that bug in make install just to be certain. I would imagine if that bug is causing this one then fixing that would fix this.
(In reply to comment #12) > Maybe I should leave this bug open and see about fixing that bug in make > install just to be certain. I would imagine if that bug is causing this one > then fixing that would fix this. Ok so if I run make dist then extract the tar.gz then do /configure --prefix=/opt/gnome && make && make install Then that works. I am pretty sure that this problem is to do with java security now and thus that it is perhaps is not actually something we want to fix for security reasons. That said, I would rather find a nice way to have the program figure out what kind of prefix to use so that people can install in their home directory without manually having to set a prefix in order for the make install to work properly... What do you think?
(In reply to comment #13) > (In reply to comment #12) > > Maybe I should leave this bug open and see about fixing that bug in make > > install just to be certain. I would imagine if that bug is causing this one > > then fixing that would fix this. > > Ok so if I run make dist then extract the tar.gz then do > > /configure --prefix=/opt/gnome && make && make install Well, if make dist and compile manually works, I guess that we can assume that the bug is not of high priority. > Then that works. I am pretty sure that this problem is to do with java security > now and thus that it is perhaps is not actually something we want to fix for > security reasons. That said, I would rather find a nice way to have the program > figure out what kind of prefix to use so that people can install in their home > directory without manually having to set a prefix in order for the make install > to work properly... > > What do you think? Probably it is not worth to use too much time on this bug right now, as there is an alternative. I would keep it open, as the bug is present, but I would lower the priority.
[Moving at-spi/java-atk-wrapper bugs to separate product. See bug 740075]
I found a good explanation on the issue seen in this bug on the automake manual for later.[1] [1] https://www.gnu.org/software/automake/manual/automake.html#Hard_002dCoded-Install-Paths
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/java-atk-wrapper/-/issues/11.