Package Details: lwjgl 3.0.0b-1

Git Clone URL: (read-only)
Package Base: lwjgl
Description: Lightweight Java Game Library - for use in game projects in Java.
Upstream URL:
Keywords: development game java library
Licenses: BSD
Submitter: apaugh
Maintainer: Freso
Last Packager: Freso
Votes: 97
Popularity: 0.184942
First Submitted: 2009-05-25 22:17
Last Updated: 2015-12-14 23:34

Latest Comments

Freso commented on 2015-01-04 00:06

LWJGL 2.9.2 has been packaged and uploaded as lwjgl2:

xkero commented on 2013-11-16 15:25

"This package installs a bunch of solaris-specific and windows-specific files."

You can fix that by changing in package() the line `rm -rf doc` to `rm -rf doc native/{freebsd,macosx,solaris,windows}`

hobarrera commented on 2013-03-08 05:24

This package installs a bunch of solaris-specific and windows-specific files.

Freso commented on 2012-06-23 21:40

@trontonic: See my comments as of "Sun, 04 Dec 2011 13:16:37 +0000" and as of "Fri, 14 Oct 2011 20:54:21 +0000".

xyproto commented on 2012-06-23 20:29

Hi, the Mac OS X and Solaris files may not have to be included.

Freso commented on 2011-12-04 22:08

Yep. Feel free to make a pull request over at GitHub to make it through faster. If not, I'll probably not update it until the next version. Also, if there's some way to do intelligent stripping (e.g., only do it on 64-bit systems (I've never had any errors with it)), that would be appreciated too. It's most likely dirt simple, but, yeah. :)

Skal commented on 2011-12-04 20:56

@Freso: ok, I understand your reasoning. So I guess the !strip option is the only necessary change.

Freso commented on 2011-12-04 13:16

@J4913 and Skal: The library isn't supposed to be in any search paths on your system - it should only be available for developing against and programs using this, should package itself with this library included. This is why the non-Linux natives need to be included, as well as the 64-bit ones on 32-bit systems, to allow the Java program using this to run in those environments. (See my comment of "Fri, 14 Oct 2011 20:54:21 +0000".)

J4913 commented on 2011-12-04 12:33

Already did that, just thought the maintainer should know.

Why not just exclude 64-bit libraries on a 32-bit system?

Skal commented on 2011-12-04 12:05

Just add the following line in the PKGBUILD:


I also added this:

build() {
cd "$srcdir/$pkgname-$pkgver"
rm -Rf native/macosx
rm -Rf native/windows
rm -Rf native/solaris

Probably not necessary, but it cuts some weight from the package

You still have to add the !strip option, because of x64 libraries.

J4913 commented on 2011-12-04 09:52

/usr/bin/strip:./usr/share/lwjgl/native/solaris/ File format not recognized

Same for Freso's PKGBUILD. I'm not sure why we should be keeping the libraries for other OSs anyway.

Freso commented on 2011-11-22 15:41

Heh. There's a new PKGBUILD at Github. ;) If you orphan the package, I'll take it over and keep it updated myself. :)

Freso commented on 2011-10-29 13:23

Updated PKGBUILD available here:

Freso commented on 2011-10-19 23:10

Well, I only needed it to check something out... but sure, I'll try and keep it updated if you don't want to deal with it anymore. :)

apaugh commented on 2011-10-15 01:54

Yeah, according to the site there it should just be provided in a location that the user can copy the libraries again. In that case, I think your approach is better.

If you don't mind, I'll use your PKGBUILD for a release 2. Your PKGBUILD looks much more complete than mine does anyway. Or if you're interested in the package I could give you ownership, because I don't actually use the library anymore myself.

Freso commented on 2011-10-14 20:54

Per "How to install LWJGL?" on, they say that "[...] you do not install lwjgl. It should not be put in any system/jre folder [...]". Oblivious of the existence of this PKGBUILD, I made one myself, which doesn't install to the system folders, but just provides the library for applications to include/copy from. It can be found on GitHub:

Let me know what you think about the differences between the two. I'm not 100% convinced of either approach at the moment, to be honest. :)