LWJGL3 ARM?

[Coioidea]

Does the LWJGL3 support arm platform still? I can't Build it successful on ARM platform.

[Spasi]

Not yet. Support for ARM is scheduled for the 3.0.2 release. We're currently working on #100 for the 3.0.1 release.

[Coioidea]

Thanks,I think we can add a schedule on the website.

[Spasi]

It's hard to tell without knowing more specifics about it. But yes, projects like Kotlin native, Scala native and JEP 295 are very interesting.

[datahaki]

i tried 3.1.3 on Nvidea Jetson TX2 which has aarch64 but there doesn't seem to be the right binary available

java.lang.UnsatisfiedLinkError: /tmp/lwjglidsc/3.1.3-SNAPSHOT/liblwjgl.so: /tmp/lwjglidsc/3.1.3-SNAPSHOT/liblwjgl.so: cannot open shared object file: No such file or directory (Possible cause: architecture word width mismatch)
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)

The project is here

https://github.com/idsc-frazzoli/owly3d

Please let me know, if I am making an obvious mistake. Is arm supported by lwjgl?

[Spasi]

Support for Android & ARM is a (very slow) work-in-progress. It currently lives in the android branch. See the android-test repository for build instructions and demos.

[datahaki]

@Spasi thank you for the reply!

for now, I only would like to read out a joystick, so I probably will look for a simple, quick alternative.

[Sliveer]

Where can I check when lwjgl will be supported on arm? When you say "(very slow) work-in-progress", do you have any idea how slow it will be? (several months, several years, unlikely to ever exist?) Is there a version of lwjgl2 that works on arm?

I'm not very good at all this, but from what I understood the code is currently compiled for different OS, but appart from compiling it for a device using arm are there other things to do? (would it be possible to do this work myself? I read that several years ago some people did so, but they did not provide a download link for it)

[Spasi]

Is there a version of lwjgl2 that works on arm?

No.

are there other things to do? (would it be possible to do this work myself?)

You can find build instructions in android-test. Assuming you have Android Studio installed and you're experienced with building Android programs, it should be straightforward.

Note that this produces binaries for the core library and native libraries whose code is included in the LWJGL repository (stb, nuklear, nanovg, etc). Libraries built separately (jemalloc, OpenAL Soft, etc.) are currently not supported. This is the biggest piece of the puzzle missing atm.

Also note that this produces a build that is Android-specific. It won't work on a generic ARM device. But most of the work done for Android will be useful for generic ARM builds.

do you have any idea how slow it will be? (several months, several years, unlikely to ever exist?)

Several months at best. Reasons:

• Currently there isn't anyone else contributing to this effort. I've repeatedly asked for help with porting the LWJGL-CI projects to Android/ARM.
• I've been very busy the past few months and this will continue for quite a while.
• This is necessarily a side-project for me, LWJGL needs to progress regardless of what happens with the ARM builds.
• I've been demoralized by how bad Android is at optimizing Java code. The NIO implementation is a joke and we cannot even depend on the most basic of optimizations. To get decent performance may require significant rewrite of LWJGL internals and even API changes. I really don't want to do that.
• Recent advances like Scala Native and Kotlin Native may make this entire effort obsolete, why bother with JNI anymore? On Android for example, you can easily write most of your application in Java/Kotlin and offload performance-sensitive and native-interop code (e.g. OpenGL/Vulkan) to Kotlin Native. Great development experience + zero overhead.

[Sliveer]

Thank you for the quick and detailed answer!

I'm not working on android actually, I'm working on raspberry. So when you say "It won't work on a generic ARM device.", I guess raspberries are included in "generic ARM device"?

I don't know about android, but I think lwjgl is still very interesting for raspberries.

[Spasi]

I guess raspberries are included in "generic ARM device"?

Yes. Any device that can run a Linux ARM JDK (e.g. Oracle JDK, Zulu Embedded).

I think lwjgl is still very interesting for raspberries.

Indeed. And with a Hotspot JVM it should run great as is.

[Sliveer]

After spending some time trying to figure out what would be the best solution for me I found this tutorial : http://rogerallen.github.io/jetson/2014/07/31/minecraft-on-jetson-tk1/

The second point explains how to build lwjgl for arm (raspberry), but it is 3 years old. I'll try this as soon as I get my raspberry back, but until then could you tell me if it seems to be a proper way to do it? (I guess things have change in 3 years, maybe it's not a good idea to do it anymore, if it actually ever worked)

[Spasi]

That article is for lwjgl2, so not applicable to lwjgl3.

Building LWJGL for ARM locally should be simple. The existing scripts should work out-of-the-box, or may require minimal changes. If you try it and encounter problems, please open a new issue and they will be addressed.

In order to have official support though, the build needs to be practical. For LWJGL, this means the ARM builds must run on Travis CI. The script that builds the Linux x64 binaries is here. We need a script that installs a cross-compiling toolchain for ARM and then builds LWJGL using it. Then we need the same for (some of) LWJGL's dependencies.

If anyone wants to try that, the process is:

1) Fork lwjgl3. 2) Register your forked repository with travis-ci. 3) Push a .travis.yml file with the build script you wrote. 4) ...repeat 3 until it works.

You're done when ant compile-native succeeds. Ignore ant upload-native (you don't need awscli and the secure variables either).

[Sliveer]

Oh sorry, I forgot it was for LWJGL3.

So you're saying if I follow the steps described on this link: https://www.lwjgl.org/guide#build-instructions with my raspberry it should actually compile the natives correctly and I'll have a working LWJGL on my raspberry? (I just want to make sure I'm following the right instructions, I'm really not familiar with all this yet)

[Spasi]

it should actually compile the natives correctly and I'll have a working LWJGL on my raspberry?

I'm saying it's a good starting point. The master branch doesn't know anything about ARM atm, so it'll think it's doing an x86 or x64 build. This will likely be problematic, but it shouldn't take many changes to make it work. Better build instructions:

• ant compile-templates (this compiles the Kotlin code, it will take a while)
• ant compile (generates the Java/C code, compiles the Java code)
• ant compile-native

The last one will probably fail with an ARM toolchain. You'll have to modify config/build-definitions.xml and config/linux/build.xml to make it work. You can use the android branch as a reference and see what changes were required there. Note that the Android build has its own config/android/build.xml but you won't need to do that for a Raspberry build.

[Sliveer]

I finally found some time to try this! The first build takes approximately 2 hours, but does not reach the end because of a java.lang.OutOfMemoryError: Java heap space.

Apparently in order to increase this space and avoid the issue I have to add -Xmx<space> to the java command lines. So I added <jvmarg value="-Xmx800m"/> each time I could in the build.xml file (probably not the best way to solve the issue, but it could've work I think), but I ended up with the same issue. As 800MB should be enough for the build to succeed, I guess I did not add the arguments at the necessary places, but I don't have any idea where to put it. And then I thought "hey, this is not compiling the C code, this doesn't have to be done on the raspberry!". Am I right? If I compile the Kotlin on my pc, then transfer the library to my raspberry to proceed to the next two commands is it going to be ok? (sadfully it's hard for me to test this, because the last steps will generate errors, and I need to be sure the error is not a consequences of the first step that I might've done the wrong way)

[Spasi]

Hmm, yes, doing the Kotlin compilation on a Raspberry is a waste of time. It's very slow, even on a high-end workstation, and there's no support for incremental compilation via the cli. It also needs around 1G of memory, not sure if the Raspberry has enough.

If I compile the Kotlin on my pc, then transfer the library to my raspberry to proceed to the next two commands is it going to be ok?

It should. Also copy any touch.txt files and make sure the last modified timestamps are maintained. You should be able to run the following targets on the PC:

• ant compile-templates (Kotlin compilation)
• ant generate (Java/C code generation)
• ant compile (Java compilation)

Then copy the modules/core/src/generated/ and bin/ folders to the Raspberry.

I also recommend disabling most bindings in config/build-bindings.xml (set the corresponding properties to false) until you have the core build working. It should significantly speed-up the build process.

[Sliveer]

Here I am again. I tried several thing, nothing worked... As I mentioned before I really don't have any skill in packaging and building projects so I kinda try things whithout actually knowing what I'm doing...

I guess it's better for me to wait until an arm version is released, even if it takes a long time. By the way if anyone has an arm compiled version of lwjgl3 that he can share (or even just the right config files to build it) don't hesitate to share it!

[mikehooper]

I got this to complete the build on my Pi3 albeit with 1 error.

Increase the swapfile size:

sudo nano /etc/dphys-swapfile

Change CONF_SWAPSIZE=100 to CONF_SWAPSIZE=1024 Reboot

Set an ant environment variable to allow java more memory:

export ANT_OPTS="-Xmx1g"
ant

Use ‘free -h’ in a separate terminal window to see how much swap space gets used.

[mikehooper]

The result of building on the Pi:

compile-native-platform: [Compiler] gcc: error: unrecognized command line option ‘-m32’ [Compiler] gcc: error: unrecognized command line option ‘-mfpmath=sse’ [Compiler] gcc: error: unrecognized command line option ‘-msse’; did you mean ‘-fdse’? [Compiler] gcc: error: unrecognized command line option ‘-msse2’

BUILD FAILED /home/pi/lwjgl3/build.xml:388: The following error occurred while executing this line: /home/pi/lwjgl3/config/linux/build.xml:101: The following error occurred while executing this line: /home/pi/lwjgl3/config/linux/build.xml:30: apply returned: 1

Total time: 3 seconds

[httpdigest]

The Raspberry Pi 3 is a 64 bit system and you probably do not have a cross-compile toolchain installed, but also don't need any. Just leave the "-m32" out. It should produce 64 bit binaries then. The Pi also has an ARM cpu and no x86, so it has no SSE. Try -mfpmath=neon or -mfpmath=vfp. Also remove the -msse and -msse2.

[mikehooper]

Although the Pi is 64bit, I'm using raspbian which is only 32bit. I've removed the unrecognised flags but still get errors reported though no detail. The -mfpmath flags didn't work. Any way to get more detail?

Buildfile: /home/pi/lwjgl3/build.xml

init:

check-dependencies:

bindings:

generate:

-init-compile:

compile:

compile-native:

compile-native-platform:

BUILD FAILED /home/pi/lwjgl3/build.xml:388: The following error occurred while executing this line: /home/pi/lwjgl3/config/linux/build.xml:178: The following error occurred while executing this line: /home/pi/lwjgl3/config/linux/build.xml:182: exec returned: 1

Total time: 3 seconds

[zhiyb]

build.xml:182, it is checking for gtk-3.0. You can try install the libgtk-3-dev package.

[zhiyb]

I got the master branch to compile on aarch64. I have commented out some flags in build script, replaced dyncall libraries using offline build mode LWJGL_BUILD_OFFLINE=true.

diff --git a/config/linux/build.xml b/config/linux/build.xml
index 41f340d..8d8e6ce 100644
--- a/config/linux/build.xml
+++ b/config/linux/build.xml
@@ -30,7 +30,7 @@
             <apply dir="@{dest}" executable="gcc" dest="@{dest}" skipemptyfilesets="true" failonerror="true" parallel="true" taskname="Compiler">
                 <arg line="-c -std=c11" unless:set="cpp"/>
                 <arg line="-c -std=c++11" if:set="cpp"/>
-                <arg line="-m64" if:true="${build.arch.x64}"/>
+       <!-- <arg line="-m64" if:true="${build.arch.x64}"/> -->
                 <arg line="-m32 -mfpmath=sse -msse -msse2" unless:true="${build.arch.x64}"/>
                 <arg line="-O3 @{lto} -fPIC @{flags} -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -D_GNU_SOURCE -DNDEBUG -DLWJGL_LINUX -DLWJGL_${build.arch}"/>

@@ -51,7 +51,7 @@
         <attribute name="name"/>
         <attribute name="dest"/>
         <attribute name="lang" default="c"/>
-        <attribute name="flags" default="-Werror -Wfatal-errors -Wall -Wextra -pedantic -Wno-extended-offsetof"/>
+        <attribute name="flags" default="-Wall -Wextra -pedantic -Wno-extended-offsetof"/>
         <element name="beforeCompile" optional="true"/>
         <element name="source"/>
         <element name="beforeLink" optional="true"/>
@@ -77,7 +77,7 @@
             <apply executable="gcc" failonerror="true" parallel="true" taskname="Linker" unless:set="lib-uptodate">
                 <srcfile/>
                 <arg value="-shared"/>
-                <arg value="-m64" if:true="${build.arch.x64}"/>
+       <!-- <arg value="-m64" if:true="${build.arch.x64}"/> -->
                 <arg value="-m32" unless:true="${build.arch.x64}"/>

                 <arg line="-z noexecstack"/>
@@ -256,13 +256,13 @@
         </build>

         <!-- SSE -->
-        <build name="lwjgl_sse" dest="${bin.native}/sse" if:true="${binding.sse}">
+        <!-- <build name="lwjgl_sse" dest="${bin.native}/sse" if:true="${binding.sse}">
             <source>
                 <arg value="-msse3"/>
                 <arg value="-I${src.native.rel}/util"/>
                 <fileset dir="." includes="${src.generated.native}/util/simd/*.c"/>
             </source>
-        </build>
+   </build> -->

         <!-- stb -->
         <build name="lwjgl_stb" dest="${bin.native}/stb" if:true="${binding.stb}">
diff --git a/modules/core/src/main/c/system/linux/wrap_memcpy.c b/modules/core/src/main/c/system/linux/wrap_memcpy.c
index 239c958..a71effb 100644
--- a/modules/core/src/main/c/system/linux/wrap_memcpy.c
+++ b/modules/core/src/main/c/system/linux/wrap_memcpy.c
@@ -2,7 +2,7 @@

 void *old_memcpy(void *, const void *, size_t);

-__asm__(".symver old_memcpy,memcpy@GLIBC_2.2.5");
+//__asm__(".symver old_memcpy,memcpy@GLIBC_2.2.5");

 void *__wrap_memcpy(void *dest, const void *src, size_t n) {
     return old_memcpy(dest, src, n);```

[Zamundaaa]

Has there been any progress on running lwjgl 3 on a raspberry pi 3 without putting too much effort into configuring etc (although I would do it anyway with effort)? If so, can someone give me a tutorial on how to make it work? If not, could someone point me to an alternative I can use as a openGL wrapper until lwjgl supports arm?

[mikehooper]

Using Pi3 Raspbian Stretch (32bit)

After commenting out the following in the build xml :

line 36: <!-- <arg line="-m32 -mfpmath=sse -msse -msse2" unless:true="${build.arch.x64}"/> -->

line 88:
<!-- <arg value="-m32" unless:true="${build.arch.x64}"/> -->

line 266:

<!--
         <build name="lwjgl_sse" dest="${bin.native}/sse" if:true="${binding.sse}">
             <source>
                 <arg value="-msse3"/>
                 <arg value="-I${src.native.rel}/util"/>
                 <fileset dir="." includes="${src.generated.native}/util/simd/*.c"/>
             </source>
         </build>
         -->

I get this far :

Buildfile: /home/pi/lwjgl3/build.xml

init:

check-dependencies:

-compile-generator:

bindings:

compile-templates:

generate:

-init-compile:

compile:

compile-tests:

compile-native:

compile-native-platform:
      [gcc] Linking lwjgl_rpmalloc
   [Linker] /tmp/ccWmgx5U.s: Assembler messages:
   [Linker] /tmp/ccWmgx5U.s:26: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:101: Error: selected processor does not support `dmb ishst' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:642: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:755: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:956: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:1017: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:1146: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:1211: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:1333: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:1394: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:1525: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:1552: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:1726: Error: selected processor does not support `dmb ishst' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:1945: Error: selected processor does not support `dmb ishst' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2011: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2139: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2160: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2193: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2246: Error: selected processor does not support `dmb ishst' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2274: Error: selected processor does not support `dmb ishst' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2320: Error: selected processor does not support `dmb ishst' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2385: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2419: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2481: Error: selected processor does not support `dmb ishst' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2495: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2521: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2557: Error: selected processor does not support `dmb ish' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2598: Error: selected processor does not support `dmb ishst' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2627: Error: selected processor does not support `dmb ishst' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2646: Error: selected processor does not support `dmb ishst' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2726: Error: selected processor does not support `dmb ishst' in ARM mode
   [Linker] /tmp/ccWmgx5U.s:2760: Error: selected processor does not support `dmb ishst' in ARM mode
   [Linker] lto-wrapper: fatal error: gcc returned 1 exit status
   [Linker] compilation terminated.
   [Linker] /usr/bin/ld: error: lto-wrapper failed
   [Linker] collect2: error: ld returned 1 exit status

BUILD FAILED
/home/pi/lwjgl3/build.xml:403: The following error occurred while executing this line:
/home/pi/lwjgl3/config/linux/build.xml:258: The following error occurred while executing this line:
/home/pi/lwjgl3/config/linux/build.xml:84: apply returned: 1

Total time: 25 seconds

[Spasi]

I haven't tried compiling rpmalloc on ARM yet, not sure what the problem is. It seems to support ARM, but you may want to disable it for now (it's optional). Bindings can be disabled in build-bindings.xml.

[mikehooper]

That seemed to work, had to disable 'tootle' as well.

I was expecting libglfw32.so to also be created - is this not the case ?

Buildfile: /home/pi/lwjgl3/build.xml

init:

check-dependencies:

-compile-generator:

bindings:

compile-templates:

generate:

-init-compile:

compile:
[javac: Core] Compiling 1865 source files to /home/pi/lwjgl3/bin/Core

compile-tests:

compile-native:

compile-native-platform:

-init-runtime:

tests:
    [Tests] [LWJGL] Version: 3.1.6 SNAPSHOT
    [Tests] [LWJGL]      OS: Linux v4.9.59-v7+
    [Tests] [LWJGL]     JRE: 1.8.0_65 arm
    [Tests] [LWJGL]     JVM: Java HotSpot(TM) Client VM v25.65-b01 by Oracle Corporation
    [Tests] [LWJGL] Loading library (system): lwjgl32
    [Tests] [LWJGL]     Loaded from java.library.path: libs/liblwjgl32.so
    [Tests] [LWJGL] Loading library: lwjgl32
    [Tests] [LWJGL] MemoryUtil accessor: MemoryAccessorUnsafe
    [Tests] [LWJGL]     Loaded from java.library.path: libs/liblwjgl32.so
    [Tests] /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt/jre/bin/java: symbol lookup error: /home/pi/lwjgl3/libs/liblwjgl32.so: undefined symbol: dcNewCallVM
    [Tests] The tests failed.

all:

BUILD SUCCESSFUL
Total time: 3 minutes 22 seconds

[Spasi]

The following bindings are built externally (see the LWJGL-CI repositories):

• Assimp
• bgfx
• dyncall
• GLFW
• jemalloc
• OpenAL Soft

The lwjgl3 Ant script downloads them as necessary, in shared or static library form.

Currently there are no CI scripts to build the above for ARM. Only dyncall has been ported to Android/ARM (example .travis.yml), because it's the only binding that the lwjgl3 core requires (that's why you're getting the symbol lookup error above).

[Sliveer]

Did you make a program using lwjgl3 work on rasp using this configuration for the build? Is it just about commentating these 3 lines from build.xml and disable lines 41 (tootle) and 36 (rpmalloc) from build-binding.xml ?

[mikehooper]

I'm trying to get the latest experimental build of Minecraft working. Its now got past the liblwjgl32.so requirement, but now needs libglfw32.so The only other change was commenting out the threadsPerProcessor="4"

[Zamundaaa]

Did you manage to get it to work?

[intrigus]

I'm currently trying to crosscompile for my raspberry pi using this docker image https://github.com/sdt/docker-raspberry-pi-cross-compiler . I'm currently having some setup-problems but I hope to solve those by the weekend.

[intrigus]

I finally got NanoVG running on my Pi: https://twitter.com/intrigus_/status/951588386002874369

@Spasi are you fine with using docker to cross-compile the binaries or do you prefer another solution?

[Spasi]

are you fine with using docker to cross-compile the binaries or do you prefer another solution?

It must be in the form of a .travis.yml script that can run on Travis CI. For example, this is the script that builds and uploads^* lwjgl's linux binaries.

Docker is supported on Travis CI and I have no objections if that's what you want to use. As long as it works and is not a maintenance nightmare.

^* if you go for it, ignore the uploading part (awscli and the secure vars)

[intrigus]

I got all but one external binding building. The remaining one should also build soon.

The lwjgl3 build should work, but there are some open problems that need to be solved as some of my solutions are hard-coded.

[Spasi]

@intrigus has almost completed an LWJGL port to ARMv6. This is the CPU architecture of the original Raspberry Pi.

I'm worried that we'll end up wasting a lot of time and effort on supporting builds that very few people will use. Is it reasonable to support ARMv6 these days?

What are the top architectures in widespread use today? We should focus on those, for both the Android/ARM builds and the generic ARM builds.

[intrigus]

@Spasi In my opinion it would probably be better to support ARMv7 since all bindings would work with it. (Excluding tootle and sse)

I'm not sure but I think that for using opengl es on pi's before model 2, you had to use a pi specific api. (Please correct me if I'm wrong) The pi 2 is also ARMv7.

[l3eta]

So I've gotten everything to build except for a few modules (Mainly Tootle, which I don't use so that's fine) However after going through and removing some methods from GLFW which are no longer used in the repo I've ran into this error which I have yet to figure out since it's so general.

/usr/local/jdk1.8.0_161/bin/java: symbol lookup error: /home/alarm/NetBeansProjects/OpenGL/libs/natives/liblwjgl32.so: undefined symbol: dcbNewCallback

I have yet to edit any of the natives except my own drop in glfw.so

[Spasi]

liblwjgl must be linked with dyncall (as a static library).

[l3eta]

That would make sense, so how would I go about doing that?

[zhiyb]

Download and build dyncall library, replace the pre-built binaries in LWJGL, then build LWJGL use offline mode:

LWJGL_BUILD_OFFLINE=true

[l3eta]

So I've build dyncall, where are the pre-built's to replace?

Nevermind, simple find | grep dyn helped.

[zhiyb]

Can't remember, but you can try build in online mode once, then search for libdyncall.a (should be downloaded automatically, but for i386/amd64)

[l3eta]

I've been running online mode this whole time, I had to build kotlin on my windows computer as don't have enough ram on my laptop. Not even sure how to turn online mode off, I don't really use ant very often

I have yet to find a libdyncall.a I actually deleted the c code from the lwjgl3/modules/core/ and it still compiles which makes me kinda wonder however it could be picking up the headers from /usr/include/

Found something useful to me:

<link> <fileset dir="${lib}/${platform}/${build.arch}/"> <include name="libdyn*.a"/> </fileset> </link>

[zhiyb]

I was building lwjgl3 natively (on aarch64). In my build, I can find libdyncallback_s.a libdyncall_s.a libdynload_s.a in libs/linux/x64. However, if I use online mode, it seems to overwrite those binaries every time, so I need to use offline mode.

[l3eta]

the bin/libs/linux/x86 folder doesn't even get used for me, it uses bin/linux/x86/

[zhiyb]

It's not in the bin folder

[l3eta]

What folder is it in? I'm not seeing any .a's being generated. I've got a bunch of .o's

I just checked my echo command from the build and my stuff is getting placed in bin

Edit 2: I think I fixed it, I had to place the built .a's into bin/libs/linux/x86 for it to link them, about to replace my .so and see if it works now.

Edit 3: Got it to work and make a window just gotta fix something that seems to return null now.

[zhiyb]

I could be using an outdated version, but for my build, they are directly in repo/libs/linux/x64:

$ ls
bin                gradlew.bat
build.gradle       libs
build.xml          LICENSE.md
config             modules
doc                README.md
gradle             settings.gradle
gradle.properties  update-dependencies.xml
gradlew
$ ls libs/linux/x64/
libdyncallback_s.a  libdyncall_s.a  libdynload_s.a

[zhiyb]

They are not generated, the binaries are downloaded directly from a server somewhere.