Page 1 of 2 12 LastLast
Results 1 to 10 of 19

Thread: Anyone have problems running/building Refinery 2.0.3?

  1. #1
    Junior Member
    Join Date
    Jun 2007
    Posts
    8

    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):

    Code :
    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:

    Code :
    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.[/code]

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

  2. #2
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    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.

  3. #3
    Junior Member
    Join Date
    Jun 2007
    Posts
    8

    problem lies with libcollada141dom12.dll?

    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. :/ It results in the same UnsatisfiedLinkError when refinery tries to loadlibrary on libloader.dll.

    Anyway, weird! Wish I could help more.

  4. #4
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    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:
    Code :
    #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\n";
    		FreeLibrary(module);
    	}
    	else {
    		cout << "failed\n";
    	}
     
    	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.

  5. #5
    Junior Member
    Join Date
    Jun 2007
    Posts
    8

    definitely libcollada141dom12.dll

    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\LIBCOLLADA141DO M12.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:

    Code :
    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.

  6. #6
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    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.

  7. #7
    Junior Member
    Join Date
    Jun 2007
    Posts
    8
    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?).

    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.

  8. #8
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    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.

  9. #9
    Junior Member
    Join Date
    Jun 2007
    Posts
    8
    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 (VS 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!

  10. #10
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    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.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •