Re: JOGL upgrade fails
Posted by Sven Gothel on Feb 12, 2012; 9:33pm
URL: https://forum.jogamp.org/JOGL-upgrade-fails-tp3728805p3738472.html
On 02/12/2012 10:02 PM, clevengr [via jogamp] wrote:
>
>
> Hi,
> First, thanks very much for all your responses; it's great that there is
> such immediate feedback on questions. Sorry it took me a couple of days to
> react; I spent a whole day trying to put all this together and then got
> sidetracked with Life.
>
> Wade: you were right -- as soon as I added the gluegen-rt-natives-xxx.jar
> to my Eclipse library (and then spent a bunch of time cleaning up Eclipse
> run configuration paths which still pointed to my old JOGL installation even
> though the Built Path pointed to the new installation) it worked great.
> Thanks!
>
> However, I'm confused about something. In previous versions of JOGL, I had
> to add the location of the relevant lib directories (e.g. jogl and gluegen)
> to my PATH. The procedure you described (and which works) doesn't include
> adding the .dlls to the PATH. What I'm confused about is how the underlying
> system is finding those .dlls when they're not in the PATH. Is there
> something magic (defined as: anything the user doesn't understand) about how
> Java processes .jar files (like gluegen-rt.jar) that causes it to look for
> .dlls in a jar in the the same location so that they don't need to be
> specified in the PATH? (I do realize this is a bit off-topic but I'm
> trying to get a clearer picture of how it works so I can accurately pass it
> on to students in classes I'm teaching using JOGL...)It's the new magic as described here:
http://forum.jogamp.org/JogAmp-Deployment-Enhancements-Automatic-loading-of-native-JARs-Applet-Application-td3362447.html
The magic is implemented within Gluegen and all modules benefit from it now.
We use a semantic names 'os.and.arch' which is utilized at build- and runtime:
http://jogamp.org/jogl/doc/deployment/JOGL-DEPLOYMENT.html#NativeJARFileNameConvention
>
> Sven: regarding your comment about perhaps needing to go back to not having
> separate directories for each platform: I LIKE the fact that the build
> system separates those things out. It makes it a little easier if one knows
> that all you need for your particular platform is contained in one place --
> without the overhead and confusion of having other platform stuff there as
> well. I've been using JOGL for a long time (much longer than my low-level
> questions would seem to imply;
Yup, the individual packages will be removed for RC6.
They - and the native library location etc .. are just a source of pain.
> I started with 1.1 (that is, the 1.1 that
> preceded the first JSR version) and have been using it ever since. I even
> fooled around a little with gl4Java
sweet .. yes it was fun doing gl4java back in the days.
> .) In all that time, no matter how great I think JOGL is (and I think it's
> wonderful), my biggest issue has been the difficulty involved it getting it
> running each time it changes.
> I think anything you guys can do to simplify the process for those who
> aren't involved in the build aspects and don't necessarily understand the
> underlying architecture and system issues but just want to download and use
> the system is great.
Yup. The fun side here is of course changing the internals
to make it easier required a change :)
But hopefully after this 'native JAR loading' is established,
we can leave it as it is.
Trust me .. this change was floating around in our minds for a long time
and we hesitated to implement it.
The final kick was the simple requirement to allow JOGL Applets to be
started w/o JNLP .. simple as that. The positive side effects for
the normal desktop application and developers were just a consequence :)
>
> Again, thanks to everyone for the help.
You are very welcome.
~Sven
URL: https://forum.jogamp.org/JOGL-upgrade-fails-tp3728805p3738472.html
On 02/12/2012 10:02 PM, clevengr [via jogamp] wrote:
>
>
> Hi,
> First, thanks very much for all your responses; it's great that there is
> such immediate feedback on questions. Sorry it took me a couple of days to
> react; I spent a whole day trying to put all this together and then got
> sidetracked with Life.
>
> Wade: you were right -- as soon as I added the gluegen-rt-natives-xxx.jar
> to my Eclipse library (and then spent a bunch of time cleaning up Eclipse
> run configuration paths which still pointed to my old JOGL installation even
> though the Built Path pointed to the new installation) it worked great.
> Thanks!
>
> However, I'm confused about something. In previous versions of JOGL, I had
> to add the location of the relevant lib directories (e.g. jogl and gluegen)
> to my PATH. The procedure you described (and which works) doesn't include
> adding the .dlls to the PATH. What I'm confused about is how the underlying
> system is finding those .dlls when they're not in the PATH. Is there
> something magic (defined as: anything the user doesn't understand) about how
> Java processes .jar files (like gluegen-rt.jar) that causes it to look for
> .dlls in a jar in the the same location so that they don't need to be
> specified in the PATH? (I do realize this is a bit off-topic but I'm
> trying to get a clearer picture of how it works so I can accurately pass it
> on to students in classes I'm teaching using JOGL...)
http://forum.jogamp.org/JogAmp-Deployment-Enhancements-Automatic-loading-of-native-JARs-Applet-Application-td3362447.html
The magic is implemented within Gluegen and all modules benefit from it now.
We use a semantic names 'os.and.arch' which is utilized at build- and runtime:
http://jogamp.org/jogl/doc/deployment/JOGL-DEPLOYMENT.html#NativeJARFileNameConvention
>
> Sven: regarding your comment about perhaps needing to go back to not having
> separate directories for each platform: I LIKE the fact that the build
> system separates those things out. It makes it a little easier if one knows
> that all you need for your particular platform is contained in one place --
> without the overhead and confusion of having other platform stuff there as
> well. I've been using JOGL for a long time (much longer than my low-level
> questions would seem to imply;
Yup, the individual packages will be removed for RC6.
They - and the native library location etc .. are just a source of pain.
> I started with 1.1 (that is, the 1.1 that
> preceded the first JSR version) and have been using it ever since. I even
> fooled around a little with gl4Java
sweet .. yes it was fun doing gl4java back in the days.
> .) In all that time, no matter how great I think JOGL is (and I think it's
> wonderful), my biggest issue has been the difficulty involved it getting it
> running each time it changes.
> I think anything you guys can do to simplify the process for those who
> aren't involved in the build aspects and don't necessarily understand the
> underlying architecture and system issues but just want to download and use
> the system is great.
Yup. The fun side here is of course changing the internals
to make it easier required a change :)
But hopefully after this 'native JAR loading' is established,
we can leave it as it is.
Trust me .. this change was floating around in our minds for a long time
and we hesitated to implement it.
The final kick was the simple requirement to allow JOGL Applets to be
started w/o JNLP .. simple as that. The positive side effects for
the normal desktop application and developers were just a consequence :)
>
> Again, thanks to everyone for the help.
You are very welcome.
~Sven
signature.asc (910 bytes) | Free forum by Nabble | Edit this page |