Anyone have problems running/building Refinery 2.0.3?

I get this error when running (on Windows XP, JDK 1.5.12, COLLADA DOM 1.4.1):


C:\Program Files\COLLADA\COLLADA_Refinery\preferences.xml not found or failed to load, default preferences loaded
Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Program Files\COLLADA\COLLADA_Refinery\libloader.dll: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem
        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)

Line 121 of LibLoader.java shows System.load(Refinery.RefineryDirectory + File.separator + “libloader.dll”);

I checked my Env Variables and COLLADA_REFINERY_LOCATION is properly set to C:\Program Files\COLLADA\COLLADA_Refinery and libloader.dll is in the directory.

Sorry, kind of a noob at Java, but when I build, the “jar cfm refinery.jar src/refinery/manifest.txt -C tmp refinery” part to create the jar package complains that manifest.txt is missing.

If yours is missing, it should be:


Manifest-Version: 1.0
Created-By: 1.5.0_07 (Sun Microsystems Inc.)
Main-Class: refinery.Refinery

Refinery.jar built from source has the same problem as above :/.

Also, the “Refinery” section in the forums is locked to Write/Reply Moderators only.



Refinery version 2.0.0 works fine though.  So if you're having problems, stick with 2.0.0.

Usually that means that you’re missing a DLL that libloader needs. You’re probably missing libcollada141dom12.dll. I think we used to put it somewhere in refinery\external-libs, and you’d have to manually copy it to the right spot. It should be in your current working directory when you run Refinery, which I think would be the bin folder if you’re running refinery.bat.

I changed things recently so that libcollada141dom12.dll gets put in the bin folder appropriately, so the copy step isn’t necessary. That’s only relevant if you’re working from the latest source though.

In any case you should look at libloader in Dependency Walker and make sure that you have all the necessary DLLs.

Thanks for the suggestions, mate!

Ran depends on libloader.dll, double checked deps. Copied libcollada141dom12.dll and libcollada141dom12_d.dll to the same level dir as refinery.jar (just in case, they also exist in the ‘bin’ and the ‘external-libs\COLLADA_DOM\lib’ directories). Still doesn’t work running refinery.bat or ‘java -jar refinery.jar’.

After some trial and error, Refinery 2.0.0 works with the libcollada141dom12.dll provided in that package, but borks if I copy libcollada141dom12.dll from Refinery 2.0.3. Wanted to figure out what the differences are between the dll’s provided in each package, but it could be any number of things. Seems to be more exports in the DLL provided with refinery 2.0.0 though, tho that doesnt really mean anything. The only real difference is the DLL provided with Refinery 2.0.3 was built against VS8 (requiring msvcr80.dll and msvcp80.dll) whereas the DLL with Refinery 2.0.0 is built against VS7 and requires (msvcr71.dll and msvcp71.dll). Copied msvcr80.dll and msvcp80.dll from a Visual Studio DDK directory into windows/system32 just in case (because loadlib was pulling the *80.dll’s randomly from a postgres installation in the path). Still didn’t work though.

Haha, was hoping for dumb luck by copying libcollada141dom12.dll from Refinery 2.0.0 to Refinery 2.0.3 but no game unfortunately. :confused: It results in the same UnsatisfiedLinkError when refinery tries to loadlibrary on libloader.dll.

Anyway, weird! Wish I could help more.

It’s probably still a DLL problem. Java suppresses the normal Windows popup dialog you get when a DLL failed to load due to not being able to find a DLL that it depends on. I wrote a small C++ program to try loading libloader.dll:

#include <windows.h>
#include <iostream>

using namespace std;

int main() {
	SetCurrentDirectoryA("C:\\sourceForge\\collada_refinery\\bin\\vc8\\release");
	HMODULE module = LoadLibraryA("C:\\sourceForge\\collada_refinery\\bin\\vc8\\release\\libloader.dll");
	if (module) {
		cout << "succeeded
";
		FreeLibrary(module);
	}
	else {
		cout << "failed
";
	}

	cout << "Press enter to continue";
	cin.get();

	return 0;
}

Try making a basic console app with that code and see what you get. Obviously you should adjust the paths to point to your libloader. The LoadLibrary call should succeed, and if it doesn’t you should get some explanation about what DLL is missing.

Great idea for a sanity check!

Did it… libloader.dll failed the loadlibrary. So I changed the test to try the suspected libcollada141dom12.dll provided in the Refinery 2.0.3 release. Also fails the test.

Depends gives this error on load: “configuration information in “c:\program files\collada\collada_refinery\bin\LIBCOLLADA141DOM12.DLL” contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.”

Here are all the modules needed by libcollada141dom12.dll that are not pulled from c:\windows\system32:


c:\program files\collada\collada_refinery\bin\ICONV.DLL [passes load test]
c:\program files\collada\collada_refinery\bin\LIBCOLLADA141DOM12.DLL [fails]
c:\windows\winsxs\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.2600.2180_x-ww_522f9f82\GDIPLUS.DLL [I assume gdiplus is ok]

Wanted to build libcollada141dom12.dll to see if that helps, but just started collada and the sourceforge version i got is 1.4.1 DOM 1.3.

I tried Loadlibrary on msvcp80.dll and that fails. LoadLibrary on msvcp71.dll works. So that is suspect. I tried copying msvcp80.dll and msvcr80.dll from postgres and Joost bin/lib directories to windows/system32 and used the dependency walker to ensure that those are the libraries being loaded. Both fail the LoadLibrary test. Dunno if that’s expected or not.

Ah, ok. I think I know what the issue is.

A couple weeks ago I tracked down a problem where the debug COLLADA DOM DLL that gets shipped with Refinery was broken. It just didn’t work for some reason. I had to build my own. If you want to do that, you can download DOM 1.2.0 from here. DOM 1.2.0 isn’t in the list of downloads at the top, but it is in the list below. The latest version is 1.3.0 and probably won’t work with Refinery.

Another option is to checkout the latest version of Refinery from svn and use that. I fixed the issues in the svn repository so that one should work fine. Here’s how you would do it:

  • Download a subversion client for your platform.
  • Run “svn co https://colladarefinery.svn.sourceforge … nery/trunk COLLADA_Refinery”
    That will check out the Refinery to the folder COLLADA_Refinery (as specified in the last argument).
  • Make sure JDK_HOME is set correctly (which should’ve been done automatically if you ran the installer).
  • The COLLADA_REFINERY_LOCATION environment variable isn’t used anymore in the latest source, so don’t worry about resetting it.
  • Open and build the appropriate .sln file for your version of Visual Studio.
  • Make sure you have the Visual Studio 2005 runtime files on your machine. If you have VS 2005 installed, you already have them. Otherwise you can get them here.
  • Now you should be able to run the refinery.bat from the bin directory you built to.

Man, no dice. Shout out to Foster City btw (San Mateo here). I used to go play video games on the Mini Theater Screen over at SCEA a few years back when my friend was working there (2002?). :smiley:

Checked out latest trunk from svn. Built both the Debug and Release versions and both have the same problem which, I guess, we believe is a link error with libcollada141dom12.dll and one of the system or runtime DLL’s on some (just me?) systems (a shot in the dark)?

I googled msvcp80.dll and msvcr80.dll and downloaded some versions that are different than the one’s loaded on my system. Checksums are (0x000879bf and 0x000a0e2f) for msvcp80 and msvcr80 respectively. Didn’t help any, so I reverted back to my old ones which have checksums 0x0009072b and 0x000a0e2f for msvcp80 and msvcr80 respectively.

Downloaded and trying to build DOM 1.2.0. Compiles in VS8, but can’t seem to build a DLL that’s anywhere near the size of the 2MB libcollada141dom12.dll. DOM1.4? IntegrationFull1.4? Must have to use the makefiles.

Man, no dice. Shout out to Foster City btw (San Mateo here). I used to go play video games on the Mini Theater Screen over at SCEA a few years back when my friend was working there (2002?).
Hah, sweet. I don’t know the theater you’re talking about though. I just started a little while ago.

Checked out latest trunk from svn. Built both the Debug and Release versions and both have the same problem which, I guess, we believe is a link error with libcollada141dom12.dll and one of the system or runtime DLL’s on some (just me?) systems (a shot in the dark)?
Bummer. So you’re still getting the same error about libloader? Maybe the Refinery is still finding the wrong version of some DLLs. What is your PATH set to? Make sure the old Refinery bin location isn’t there.

I googled msvcp80.dll and msvcr80.dll and downloaded some versions that are different than the one’s loaded on my system. Checksums are (0x000879bf and 0x000a0e2f) for msvcp80 and msvcr80 respectively. Didn’t help any, so I reverted back to my old ones which have checksums 0x0009072b and 0x000a0e2f for msvcp80 and msvcr80 respectively.
It sounds like you already have VS 2005, right? So you should already have the runtime. You shouldn’t need to copy files from anywhere (sometimes depends gets confused and incorrectly reports DLLs missing).

Downloaded and trying to build DOM 1.2.0. Compiles in VS8, but can’t seem to build a DLL that’s anywhere near the size of the 2MB libcollada141dom12.dll. DOM1.4? IntegrationFull1.4? Must have to use the makefiles.
No, you have the right idea using the normal VS 2005 project files. You want to build the Release DLL version of the solution. You should get a file libcollada141dom12.dll in the bin directory. Mine weighs in at 2.1 MBs.

Built libcollada141dom12.dll from scratch on Visual Studio 2005. Had to use the Project Files in the projects/VC++7 directory and convert them to Visual Studio 2005 (VS8) files. The project files in the VC++8 are missing some of the build parameters that the VC++7 project has to build the final libcollada141dom12.dll from the static libs and place the dll in the ‘bin’ directory.

Used the rebuilt libcollada141dom12.dll with the SVN/trunk version of Refinery (2.0.3+). Tried running them together and still fails.

Sanity check by using LoadLibrary test on the rebuilt libcollada141dom12.dll fails. Sanity check on libcollada141dom12.dll packaged with Refinery 2.0.0 succeeds. Summary so far, Refinery 2.0.0 works but Refinery 2.0.3 fails with UnsatisfiedLinkError presumably because its build of libcollada141dom12.dll cannot be loaded.

Hah, sweet. I don’t know the theater you’re talking about though. I just started a little while ago.

Heh, yeah, there used to be a projector and a 15 foot screen with theater-like seating in a room to the right of the entrance door (dunno if you guys are on the same floor still). This was back when we were excited about the mini-tower sized PS2 dev boxes and doing stuff with the eye-toy and “Minority Report Glove” that was in R&D.

P.S. I’m fine using Refinery 2.0.0 I suppose. Trying to build a web service that converts a bunch of the most popular 3d file formats to COLLADA/DAE. Was looking for example code for standalone conditioners that run as executables, but it seems that they’ve all been moved into refinery. As a note to newcomers to Collada, the Conditioner Samples that Remi mentions in the “Collada: Sailing the Gulf…” book are not in the DOM samples anymore. But you can still find them in SVN for DOM 1.1 here:

http://collada-dom.svn.sourceforge.net/ … 3/samples/

Myself, I’m probably gonna go back to the standalone exe style and call the translation from system in Ruby on Rails or os.system for Django. Or maybe extend Python itself so that Django can validate and convert 3d file formats “natively.”

Any advantage to sticking with conditioners wrapped by the java refinery service? (other than the crossplatform GUI?) Visually creating a tool-chain and macros seems like a good idea tho!

I’m fine using Refinery 2.0.0 I suppose.
Fair enough. Shame you’re such a quitter though. (I kid :P)

I’m supposed to get a copy of VMware sometime soon. When I do I’ll check out Refinery from svn and see if it’ll run on a clean Windows XP. If that works then I’ll just assume there was something screwy going on with your system and forget about it.

As a note to newcomers to Collada, the Conditioner Samples that Remi mentions in the “Collada: Sailing the Gulf…” book are not in the DOM samples anymore.
They should all be in the Refinery now. I wouldn’t grab them from the old COLLADA DOM code. The old conditioners distributed with the DOM never really worked from what I remember. The code has been reworked and improved pretty drastically.

Myself, I’m probably gonna go back to the standalone exe style and call the translation from system in Ruby on Rails or os.system for Django. Or maybe extend Python itself so that Django can validate and convert 3d file formats “natively.”

Any advantage to sticking with conditioners wrapped by the java refinery service? (other than the crossplatform GUI?) Visually creating a tool-chain and macros seems like a good idea tho!
The advantage is efficiency when chaining together many conditioners. If you have a chain of 5 conditioners and each is its own exe, then running a COLLADA file through that chain means you’re going to have to load and then save the file 5 times. Since save/load typically takes longer than the actual conditioner, that’s going to be very inefficient. The way the Refinery works, the file is loaded once at the beginning, then passed along to each DLL conditioner in the form of a DAE object, then saved once at the end.

Whether or not the efficiency gains are worth the extra infrastructure work depends on your situation of course. If you’re not doing conditioner chaining then it certainly isn’t worth it.

Thanks sthomas! That chaining advice and avoid saving to disk is a good tip. Let us know how that VMWare clean install goes. Might try that myself in the next 3 weeks. I’ll be sure to reply to this topic if/when I do.


Fair enough. Shame you're such a quitter though. (I kid Razz) 

Gah! Haha… I tried! I want a new computer :/.

Ok, got VMware installed and tried installing Refinery. First I installed the latest JDK and the VS 2005 redist. Otherwise, I’m working on a clean Windows XP Pro SP 2.

Refinery 2.0 wouldn’t run at first. libloader was failing. Depends said it couldn’t resolve msvcp71.dll. I tried looking for an official Visual Studio 2003 redist but wasn’t successful, so I downloaded msvcp71.dll from dll-files.com and put it in Windows\System32. Then it ran fine.

Refinery 2.0.3 and 2.1.0 (the not-yet released version from svn) just won’t run. I get this error with either version:

Exception in thread “main” java.lang.UnsatisfiedLinkError: C:\Program Files\COLLADA\COLLADA_Refinery\libloader.dll: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem
Opening libloader in depends gives me this:

Error: The Side-by-Side configuration information for “c:\program files\collada\collada_refinery\bin\vc8\release\LIBCOLLADA141DOM12.DLL” contains errors.
Googling the problem took me here. There are lots of different people suggesting different solutions that worked for them. I tried a couple but didn’t have any luck.

I have to work on some other stuff now, but I’ll be back.

Props man. That was fast, setting up VMs are a pain, good thing you can alt-tab to something else :D.

Error: The Side-by-Side configuration information for “c:\program files\collada\collada_refinery\bin\vc8\release\LIBCOLLADA141DOM12.DLL” contains errors.

Yup, I got that error too for 2.0.3 on load in dependency walker. Good find on the Googling.

Hopefully copying msvcp80.dll and msvcr80.dll from the working machine onto the VM Stock install will fix it. Otherwise gotta find the incompatibility with the static libs used on the compiling machine with the runtime libraries on VM?

hi,

just tried the compilation on a fresh Parallels Installation with current SVN-version of both Refinery and DOM. Apparently I got the Refinery running without any major problems, but I build the DOM 1.3 first and linked the libloader against that version (not the one bundled with Refinery).

If that doesn’t work for you: do you compile on a FAT32-partition? If you do, you might have to enable “Use FAT32 Work-around” in Project-properties->Manifest Tool->General. I ran into this problem a couple of months ago when I installed a cross-platform accessible partition. If the workaround is not enabled on FAT32, the dynamic loader simply does not find the DLL.

Thanks heinzi, tried it and confirming that your method works! compiled libloader and all the conditioner projects using libcollada14dom13.lib, copied the libcollada141dom13.dll to the dynamic loading path (the ‘bin’ dir of the Refinery Folder if you’re using the *.bat file otherwise the same dir that you run ‘java -jar refinery.jar’).

Before this threads dies, what is the difference between libcollada14dom12 and libcollada14dom13? I wasn’t clear on this. If one is a newer library than the other but implements the same Specification (Collada 1.4), why would Refinery or any project be built against the older libcollada14dom12 over libcollada14dom13?

Thanks for the tip Heinrich.

Before this threads dies, what is the difference between libcollada14dom12 and libcollada14dom13? I wasn’t clear on this. If one is a newer library than the other but implements the same Specification (Collada 1.4), why would Refinery or any project be built against the older libcollada14dom12 over libcollada14dom13?
libcollada141dom13.dll is DOM 1.3.0, which is the latest released version. libcollada141dom12.dll is DOM 1.2.0. It looks like we just haven’t updated the Refinery to use the latest version of the DOM yet. I filed a bug to do that for the next release of Refinery.

I don’t think the real issue was the DOM version though. I think I had the right idea all along about the VS2005 redist, but I was linking to the wrong redist. Our software is built with VS2005 SP1, which has a different redist than plain VS2005, which is the redist I was linking you to. The VS2005 SP1 redist is available here.

When I take a clean Windows XP and try to run Refinery, it doesn’t work. After I install the VS2005 SP1 redist though, Refinery runs fine. We shouldn’t bother the user with this sort of nonsense though, so I filed a bug. I have to work on other things now but hopefully either me or Herbert can address this in the near future.

Actually I went ahead and submitted revision 53, which modifies the installer to run the VS2005 SP1 redist. The installer used for the next version of Refinery should work on all Windows machines.

:smiley:

really learned a lot from here