Travis Build, Natives Not Loading

[TheDudeFromCI]

Hello,

I'm currently working on a personal game engine project. For this project, I am using Travis and Maven for unit testing and code coverage. While tests all work fine on my laptop, even pulling and building from a completely clean slate, some of the tests which require LWJGL libraries in order to run while failing on Travis. The library in question is Assimp.

Travis Build Log:

[05:10:33][Info][Time-limited test] Loading the resource [Res: unit_tests/cube.fbx].
Exception in thread "Thread-7" java.lang.ExceptionInInitializerError
	at net.whg.frameworks.external.AssimpAPIBridge.load(AssimpAPIBridge.java:13)
	at net.whg.we.resource.MeshConverterFuture.run(MeshConverterFuture.java:48)
	at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
	at org.lwjgl.system.Checks.check(Checks.java:99)
	at org.lwjgl.system.Pointer$Default.<init>(Pointer.java:52)
	at org.lwjgl.system.SharedLibrary$Default.<init>(SharedLibrary.java:18)
	at org.lwjgl.system.linux.LinuxLibrary.<init>(LinuxLibrary.java:19)
	at org.lwjgl.system.APIUtil.apiCreateLibrary(APIUtil.java:124)
	at org.lwjgl.system.Library.loadNativeFromSystem(Library.java:300)
	at org.lwjgl.system.Library.loadNative(Library.java:286)
	at org.lwjgl.assimp.Assimp.<clinit>(Assimp.java:1859)
	... 3 more

The code on the line in question is simply the line indicated below.

@Override
	public AssimpScene load(File file)
	{
>>>>>		AIPropertyStore settings = Assimp.aiCreatePropertyStore();
		Assimp.aiSetImportPropertyInteger(settings, Assimp.AI_CONFIG_PP_SLM_VERTEX_LIMIT, 65535);

		AIScene scene = Assimp.aiImportFile(file.toString(),
				Assimp.aiProcess_Triangulate | Assimp.aiProcess_GenSmoothNormals | Assimp.aiProcess_FlipUVs
						| Assimp.aiProcess_CalcTangentSpace | Assimp.aiProcess_LimitBoneWeights
						| Assimp.aiProcess_SplitLargeMeshes | Assimp.aiProcess_OptimizeMeshes
						| Assimp.aiProcess_JoinIdenticalVertices);

		Assimp.aiReleasePropertyStore(settings);

		if (scene == null)
			return null;

		AssimpScene s = new AssimpSceneBridge(scene);
		Assimp.aiReleaseImport(scene);

		return s;
	}

I'm not sure how to approach the issue of configuring the native library path to load in this scenario, and any advice to point me in the right direction would be wonderful. I've spent several hours on Google looking this problem up, but to no avail. It also worth noting I am currently using LWJGL version 3.1.6.

Thank you in advance and have an amazing day.

[spasi]

What output do you get if you run the CI build with -Dorg.lwjgl.util.Debug=true -Dorg.lwjgl.util.DebugLoader=true?

[TheDudeFromCI]

I updated my Travis config file to the following, however, the output log has not changed in any way.

language: java

jdk:
  - oraclejdk8

before_install:
  - cd WraithEngine

env:
  - Dorg.lwjgl.util.Debug=true Dorg.lwjgl.util.DebugLoader=true

after_success:
  - mvn jacoco:report coveralls:report

[TheDudeFromCI]

Update: after more fiddling with the Travis.yml, it now prints the LWJGL debug.

[02:27:12][Info][Time-limited test] Loading the resource [Res: unit_tests/cube.fbx].
[LWJGL] Version: 3.1.6 build 14
[LWJGL] 	 OS: Linux v4.4.0-101-generic
[LWJGL] 	JRE: 1.8.0_151 amd64
[LWJGL] 	JVM: Java HotSpot(TM) 64-Bit Server VM v25.151-b12 by Oracle Corporation
[LWJGL] Loading library (system): lwjgl
[LWJGL] 	Using SharedLibraryLoader...
[LWJGL] 	Extracting: file:/home/travis/.m2/repository/org/lwjgl/lwjgl/3.1.6/lwjgl-3.1.6-natives-linux.jar!/liblwjgl.so
[LWJGL] 	Loaded from org.lwjgl.librarypath: /tmp/lwjgltravis/3.1.6-build-14/liblwjgl.so
[LWJGL] Loading library: assimp
[LWJGL] 	Using SharedLibraryLoader...
[LWJGL] 	Extracting: file:/home/travis/.m2/repository/org/lwjgl/lwjgl-assimp/3.1.6/lwjgl-assimp-3.1.6-natives-linux.jar!/libassimp.so
[LWJGL] MemoryUtil accessor: MemoryAccessorUnsafe
java.lang.NullPointerException
	at org.lwjgl.system.Checks.check(Checks.java:99)
	at org.lwjgl.system.Pointer$Default.<init>(Pointer.java:52)
	at org.lwjgl.system.SharedLibrary$Default.<init>(SharedLibrary.java:18)
	at org.lwjgl.system.linux.LinuxLibrary.<init>(LinuxLibrary.java:19)
	at org.lwjgl.system.APIUtil.apiCreateLibrary(APIUtil.java:124)
	at org.lwjgl.system.Library.loadNative(Library.java:329)
	at org.lwjgl.system.Library.loadNative(Library.java:313)
	at org.lwjgl.system.Library.loadNative(Library.java:235)
	at org.lwjgl.assimp.Assimp.<clinit>(Assimp.java:1859)
	at net.whg.frameworks.external.AssimpAPIBridge.load(AssimpAPIBridge.java:13)
	at net.whg.we.resource.MeshConverterFuture.run(MeshConverterFuture.java:48)
	at java.lang.Thread.run(Thread.java:748)
[LWJGL] 	libassimp.so not found in java.library.path=/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
Exception in thread "Thread-7" java.lang.ExceptionInInitializerError
	at net.whg.frameworks.external.AssimpAPIBridge.load(AssimpAPIBridge.java:13)
	at net.whg.we.resource.MeshConverterFuture.run(MeshConverterFuture.java:48)
	at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
	at org.lwjgl.system.Checks.check(Checks.java:99)
	at org.lwjgl.system.Pointer$Default.<init>(Pointer.java:52)
	at org.lwjgl.system.SharedLibrary$Default.<init>(SharedLibrary.java:18)
	at org.lwjgl.system.linux.LinuxLibrary.<init>(LinuxLibrary.java:19)
	at org.lwjgl.system.APIUtil.apiCreateLibrary(APIUtil.java:124)
	at org.lwjgl.system.Library.loadNativeFromSystem(Library.java:300)
	at org.lwjgl.system.Library.loadNative(Library.java:286)
	at org.lwjgl.assimp.Assimp.<clinit>(Assimp.java:1859)
	... 3 more

[spasi]

Looks like LWJGL finds libassimp.so but loading it fails. However, in LWJGL 3.1.6 we cannot see the failure reason, this has been fixed in 3.2.0.

The most likely issue is that Assimp has a dependency that is not satisfied on the Travis instance. What's the output of `ldd libassimp.so` there? You can use curl to get it in the CI build, from here.

[TheDudeFromCI]

Thank you very much for your help, I highly appreciate it. I'll be trying that method in the next build. I have also looked into updating the project to the newest version of LWJGL as well for other reasons which should hit the build server in a week or two. Thank you again.