Hi
Windows 64 builds don't fall out by default at the moment as the build scripts don't do any detection of host arch. I recently updated JInputs buids to detect it, any objections to me poking LWJGLs so that on 64 bit windows it builds either 64 bit, or both 64 and 32 bit (the linux build xml builds just 64 bit IIRC).
I'm not a solaris used, but I've installed open solaris to build LWJGL, the resulting liblwjgl.so is confusingly dumped in to the linux dir, and file shows it as a 32 bit build. What i've read suggests that opensolaris detects you arch and loads the dll appropriately, but does that mean I nead a 64/32 build .so when I do a 'file' on it?
Any objections to me prodding the builds to parameterise the signing of the files for the applet-distribute target. Currently, it fails to build because, surprise surprise, I don't have mazons keystore, alias, or password :)
Also got some updated JInput builds I can put in whilst I'm fiddling if it's wanted?
Endolf
Quote from: Endolf on April 06, 2009, 17:05:17
Windows 64 builds don't fall out by default at the moment as the build scripts don't do any detection of host arch. I recently updated JInputs buids to detect it, any objections to me poking LWJGLs so that on 64 bit windows it builds either 64 bit, or both 64 and 32 bit (the linux build xml builds just 64 bit IIRC).
sure. currently we're relying on mingw for 64bit and vcexpress for 32 bit - and to add insult to injury its done using different scripts with no detection of arch at all.
You are more than welcome to change this.
Linux produces whatever platform its being compiled on - so I have 2 vmware instances for this - debien 32 and debian 64 bit.
Quote from: Endolf on April 06, 2009, 17:05:17I'm not a solaris used, but I've installed open solaris to build LWJGL, the resulting liblwjgl.so is confusingly dumped in to the linux dir, and file shows it as a 32 bit build.
yes...
Elias did the solaris builds which is based on gcc also. It will build the platform its running under - so 32 bit if solaris 32bit. Either we need to create a solaris varian in platform_build or something should move it around.
Quote from: Endolf on April 06, 2009, 17:05:17What i've read suggests that opensolaris detects you arch and loads the dll appropriately, but does that mean I nead a 64/32 build .so when I do a 'file' on it?
eh? - I am not aware of how solaris handles 32/64 bit...
Quote from: Endolf on April 06, 2009, 17:05:17
Any objections to me prodding the builds to parameterise the signing of the files for the applet-distribute target. Currently, it fails to build because, surprise surprise, I don't have mazons keystore, alias, or password :)
fwiw, dont spend too much time on it since we ought to -in some time in the future - to rework the scripts quite a bit. It is a bit messy unfortunately. There is a test-keystore in applet/lwjglkeystore that can be used to sign with. The password is in the scripts. Ideally we'd like to get the nightly builds signed too, but I can't see how we would do this at the moment... (technically, its not LWJGLs certificate - but oddlabs, due to issues getting a cert for an virtual entity).
Quote from: Endolf on April 06, 2009, 17:05:17Also got some updated JInput builds I can put in whilst I'm fiddling if it's wanted?
sure, but we usually add jinput files directly into lwjgl-svn so not sure how we would handle this...
Btw, *very* nice job on the hudson stuff. Considering the mess LWJGL build scripts are (at least for the uninitiated) I am impressed by how much work you've gotten done!
I'm using vc express to compile 64 bit builds, which might explain why the files are different sizes :). I'll poke it so win32 and win64 work. I'll stick to the current format of compiling 64 bit only on 64 bit arch.
Open solaris appears to detect the hardware, and use 64 bit or 32 bit appropriatly. I have no idea how it does this, but as there are seperate 64 and 32 bit JVMs, I'll figure out how to do 32 and 64 bit libs. Might get them to compile on the same box if thats ok?. Saves yet another virtual machine :).
If I parameterise the build, I'll make it so that some -D options will be able to change the keystore, alias and password used, but by default the whole lot will be signed by the test keystore?, sound ok?
I was planning on sticking the new JInput libs in the repository as per normal, not hacking the build :)
Endolf
Quote from: Endolf on April 06, 2009, 18:24:28
I'm using vc express to compile 64 bit builds, which might explain why the files are different sizes :). I'll poke it so win32 and win64 work. I'll stick to the current format of compiling 64 bit only on 64 bit arch.
are you *sure* about that ? - vcexpress cannot do 64 bit ... you need vc for that.. - that is why we have two completely different builders mingw/vcexpress.
Quote from: Endolf on April 06, 2009, 18:24:28
Open solaris appears to detect the hardware, and use 64 bit or 32 bit appropriatly. I have no idea how it does this, but as there are seperate 64 and 32 bit JVMs, I'll figure out how to do 32 and 64 bit libs. Might get them to compile on the same box if thats ok?. Saves yet another virtual machine :).
no problem from my view.
Quote from: Endolf on April 06, 2009, 18:24:28
If I parameterise the build, I'll make it so that some -D options will be able to change the keystore, alias and password used, but by default the whole lot will be signed by the test keystore?, sound ok?
yup
Quote from: Endolf on April 06, 2009, 18:24:28
I was planning on sticking the new JInput libs in the repository as per normal, not hacking the build :)
fine by me
If you install the MS platform SDK, you can use VC express to build 64 bit applications. It doesn't have a 64 bit native compiler, but it does have a cross compiler in the platform SDK.
Endolf
did that with openal - but then you are building using a solution instead of the ant scripts ?
Nope, just ant. All you have to do is set the right environment variables so it's pointing to the right headers, libs etc and the right cl.exe. After that, it's all standard :)
Endolf
I tried using setenv /release /x64 but to no avail... must be missing something then? - it always complained about missing imports from jawt.dll
Are you building on a 64 bit os ?
Quote from: Matzon on April 07, 2009, 06:58:47
I tried using setenv /release /x64 but to no avail... must be missing something then? - it always complained about missing imports from jawt.dll
Are you building on a 64 bit os ?
I can't remember which env variables I set (I can check when I get home from work). There is a vcvarsamd64 or something that I referenced. I think in one of the bin folders there is an amd64 folder with it's own cl.exe. From what I've read, vc express doesn't have a native 64 bit compiler, as in the cl.exe is 32 bit, but it does have some that can output 64 bit libraries. You also have to change some of the include/lib folders in the ant scripts as they currently point to 32 bit libs and linking fails.
I am using a 64 bit win XP for the 64 bit windows builds.
I build JInput using the same environment and I had someone with windows 7 64 bit, with the 64 bit jre, saying that the binaries worked.
Endolf
got it working also!
I think the gist of the problem is that to link with jawt.dll - you need the correct version of the JDK installed. That is 64 bit JDK for 64 bit lwjgl.dll - however the JDK you download is packaged in an executable, which means you cannot create the 64 bit lwjgl with /delayload options unless you are on a 64 bit platform. *sigh*.
Any how - Windows 7 64 bit with vcexpress and platform sdk seems to do the trick.
What does the /delayload do?, I didn't understand what the documentation on it was talking about.
With JInput I expect a 64 bit JDK to get a 64 bit native, is that a problem?
Endolf
delayload waits with waiting loading of dependent libs.
In out case, it doesn't load jawt.dll before its actually needed. This fixes so that we dont have to add jawt.dll on the path until something that requires awt does. When that happens, *someone* have usually done some behind the scenes work so that the jre lib folder is on the OS's search path and we wont get a dependency issue.
Is that going to be a show stopper in terms of building 64 bit version with vc express?, I guess not, as I'm not planning on removing the mingw option.
Also, you mentioned that the openal SDK is no longer needed, is that true?, if so, I can go ahead and remove the alhome property in the native build scripts?
Endolf
I am not aware of any use of OpenAL header files - I *could* be wrong tho :)
the 64 bit version build with vcexpress is fine. If you can build from command line, then /delayload is supported and all is good.
I *think* all the platform builds are working correctly now. I hope I've not broken anything.
Things left to do
- Sort out the main distribution build so that by default it signs using the test keystore, but with -D arguements it will build with any other keystore/alias/password
- Update the version of JInput to include the natives for all platforms
Endolf
Hi
I've tweaked a few of the build configs, it now polls svn hourly to see if it needs to build as well as the nightly. It keeps 5 days worth of builds. It emails you if you break or fix any build (unfortunatly, if you screw up multiple platforms, you get multiple emails). Emails are sent to the sourceforge account linked to the user, so I have no idea where each one ends up :).
I hope this will be useful.
Endolf
I should have named this topic slightly better, it was intended to deal with the automated builds. Someone might be able to give you an answer but I suggest moving your post to a new topic so it is more visible.
Endolf