Hi Joseph,
I found a work-around for the above problem by copying all the dlls into the
System32 folder in Windows. I shall continue working this way until I can
figure out what I am doing wrong with my Linker settings.
I really wish people with DLL errors would search the forums/archives,
it seems like we're answering these questions all the time these days.
Just last week another person was having similar problems and it took
about 3 days of back-and-forth messages before he decided to follow our
advice and it finally was resolved...
Finding DLLs has nothing to do with your linker settings. Once you have
an .exe file, the linking process is done. Linking means taking all .obj
and .lib files and putting them together (possibly dropping unused
symbols and doing optimizations) to make an .exe file.
DLLs are searched for at runtime. When the OS loads an .exe that refers
to some DLLs, it will search through a fixed list of locations to find
these DLLs:
1. In the same directory as the .exe
2. In the Windows system / system32 / sysWOW64 directories
3. In each directory of your system PATH
At this point, the linker has no influence whatsoever. The DLLs will
either be found in the above list of locations, or they won't be. If
you're getting an error that your application can't find a given DLL,
then it means that DLL is not in one of that list of locations.
Note that IMHO, location 2 (the Windows system directories) are the
WORST place you could put your DLLs. You're polluting your Windows
installation, and eventually it will be a nightmare to manage (you will
get apps loading the wrong DLL because you put a version of it in that
directory, etc.).
If you're deploying an OSG-based app, I would suggest you package up the
required DLLs with your exe and resources and distribute it that way.
Since the OS tries the same directory as the exe first, it will find the
right DLLs every time (as long as you know you're putting the right DLLs
there in the first place).
In reading your previous message, you don't really give enough details
for us to be able to help you more than give general information like
I've done above. This is all knowledge you should have if you're
developing applications on Windows. The compilation process, the linking
process, and the app execution process (including dynamic linking and
dynamic loading) are part of knowing your tools before you start working.
One thing I noticed from your message: You seem to assume that if you
set an environment variable called OSG_BIN_PATH to a list of directories
(OSG itself and your 3rdparty dependencies) then when starting the app
will load the DLLs from there. That isn't the case - notice that I
didn't mention OSG_BIN_PATH in the above list of locations searched by
the OS for DLLs. You would need to put the directories where your OSG
DLLs are on your PATH for them to be found. Same for 3rd party DLLs.
In that other case a week ago that I mentioned above, the person was
also not giving us enough information, and then from partial answers
(the best answers we could give based on the info provided) would make
wrong assumptions and question why it still didn't work. In the end,
when all the information was there, we were able to give the appropriate
solution and the problem was resolved. So I think if the above
information doesn't help you solve your problem, you should give us more
information. What DLL is it looking for? What is your system's PATH set
to? (open a command prompt and type "set PATH" and copy-paste the value
it prints out) Are you sure your app is linked to the same version of
OSG as your DLLs? (this was the other person's problem, they had linked
their app to an older version of OSG, then they rebuilt OSG from source
and thought their app would just use those DLLs without having to be
recompiled)
Hope this helps,
J-S
--
______________________________________________________
Jean-Sebastien Guay [email protected]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
