Hi, im trying to develop a custom conditioner. Before i can do that, i tried recompiling the conditioners.vcproj using VC8 express. After setting up the build environment properly, i managed to successfully compile the project. But now Refinery no longer works. Heres the error from cmd
Exception in thread “main” java.lang.UnsatisfiedLinkError: C:\Prog
ADA\COLLADA_Refinery\libloader.dll: Can’t find dependent libraries
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.load0(Unknown Source)
at java.lang.System.load(Unknown Source)
at refinery.LibLoader.<clinit>(LibLoader.java:121)
at refinery.Refinery.<init>(Refinery.java:90)
at refinery.Refinery.main(Refinery.java:315)
When you loaded the Refinery solution did you do a “clean”. And then only rebuild the conditioners project?
The libloader is a DLL that is required to communicate from the C++ conditioners with the Java refinery GUI. We released the source of that too as the LibLoader project in the Refinery solution. If that project isn’t built or the DLL is missing or misplaced, the refinery will fail to start.
I’m also starting to look at developing a custom conditioner and I’ve run across a few issues with the refinery build process that I wanted to share:
The first thing I noticed is that Conditioners.vcproj is missing from the VC++7 directory. No real problem there since I was able to copy the project from the VC++8 directory and modify the version number in a text editor. After this the solution loaded fine.
The next thing is my own fault but it’s still a little annoying. I started off by doing a “clean” on the entire solution which unfortunately blew away the refinery.jar file. I say it was unfortunate because I had only installed with the “Developer” option so I didn’t have the source files to recreate refinery.jar. No real problem again, I just reinstalled with the “Source” option and continued. Related to the issue of which install configs install which files, I also noticed that libxml2 is not installed with the “Developer” option though it is installed with the “Source” option. Not sure if this is actually a bug or not. I know the coherency test project needs libxml but I don’t know if it counts as a conditioner or as part of the core refinery build.
I also had to modify all the projects to refer to $(JDK_HOME) instead of the fixed path to the JDK that was originally set in the projects. This was an issue because Sun really wanted me to download JDK v1.6.0 instead of 1.5.0.7 (or whatever version the projects assume). Interestingly I noticed that the conditioners project already used JDK_HOME even though none of the other projects did.
I also had some issues with the variable COLLADA_DOM_LOCATION. I noticed that the conditioner project just referenced …/…/external-libs/collada_dom directly while the other projects used COLLADA_DOM_LOCATION which wasn’t set by the installation. Since the installer went to the trouble to install a version of the collada dom at a known location I figured I would just refer directly to that instead of having to set another environment variable. Since I was making this change I also got rid of any references to COLLADA_EXTERNAL_LIBS_LOCATION for the same reason. Since the installer put those libs at a known location relative to the project files I just pointed to them directly instead of using the environment variable. Again, I wouldn’t go so far as to call this last item a bug so much as a difference of opinion. Either way you decide to go (environment variable or not) it would be good to be consistent between projects.
Anyway, after making these few changes I’m able to build and run all of refinery under VC++7. Now I’m looking forward to getting to work on some conditioners.
Hey Thayer,
Thanks for that info. I will make sure things get updated properly for the next release or update.
I mainly use VC8 and then update the project files in VC7 before releasing. I guess there are a lot of smaller details that I missed, like using/not using certain environment variables.
You are absolutely correct to not use COLLADA_DOM_LOCATION and EXTERNAL_LIBS_LOCATION. We packaged a copy fo the DOM with the Refinery so the refinery always uses the one version of the DOM. and people shouldn’t build conditioners against a local copy of the DOM they have elsewhere, incase they are different versions in the future(like an updated DOM but not refinery).
I’m actually surprised that “clean” removes the refinery.jar file. I thought the rules to make and delete that file were in the “javaSrc” project, which shouldn’t be in the developer release. Maybe it is but all the source files aren’t. arg… stupid mistakes…