BlueMonkMN's picture

OpenTK.dll.config and dllmap configuration

The OpenTK,dll.config seems to be working great. So why would I not be able to get the same thing to work for the main application? I have an application "tmp.exe" which I have both tried to compile under Windows with Visual Studio and compile with MonoDevelop under Linux. In both cases, the program comes up just fine and shows me pretty graphics (an indication that OpenTK is working great), but as soon as I try to start the phase where sound is involved, I get a DllNotFoundException stating that fmodex was not found. The same application runs fine under windows when fmodex.dll is present. But when when fmodex is not present, and libfmodex-4.22.01.so is present instead, I can't seem to get it to work. I have the following content in tmp.exe.config:

<configuration>
<dllmap os="linux" dll="fmodex.dll" target="libfmodex-4.22.01.so"/>
</configuration>


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

Reading the documentation, I can think of two things to check:

  • the "dll" attribute is case-sensitive and should match your DllImport string exactly.
  • libfmodex should be in your LD_LIBRARY_PATH. It's not enough to place it the application directory (but I think you can use target="./libfmodex-4.22.01.so" in this case).
BlueMonkMN's picture

Stranger yet -- I have another project "MonoSamp.mdp" and when I run this from within the MonoDevelop IDE, the sound works fine, but when I run the compiled exe file directly, the menu comes up fine, but I get the same error as soon as any sound tried to play. When I try to run the tmp project from within the IDE, it doesn't work.

the Fiddler's picture

Have you set the IDE to create a launch script? If so, what does the script contain?

Also what does echo $LD_LIBRARY_PATH return in each case?

BlueMonkMN's picture

$LD_LIBRARY_PATH is empty (doesn't exist).
I didn't set the IDE to create a launch script, but apparently it is set to create one. the "MonoSamp" project is set to create one called monosamp, and the "tmp" project is set to create one called tmp. But I can't find them. There is no file called monosamp in the MonoSamp directory where the project resides or any of its children ("find -name monosamp" returned nothing).

(P.S. What is a launch script?)

objarni's picture

Did you try try the "./filename.so" trick?

BlueMonkMN's picture

Using the ./libfmodex-4.22.01.so trick works to make MonoSamp.exe run outside the IDE. But I still don't know why tmp.exe is behaving differently than MonoSamp.exe. It still looks for fmodex instead of libfmodex (I noticed that MonoSamp was failing with a similar message but the filename was different -- it was looking for libfmodex whereas tmp.exe was still looking for fmodex). I have scruitinized every aspect of the config files and they look identical to me except for the name (MonoSamp.exe.config and tmp.exe.config). I changed the permissions of the tmp.exe.config file because it was copied from a Fat32 file system and came across as an executable file. I even deleted and re-entered the newlines in case the Windows version of newlines were causing problems. Now it's permissions are even set the same and the executable still isn't picking up the config file and I can't figure out why.

P.S. I also tried copying MonoSamp.exe.config to tmp.exe.config and running tmp.exe from the same directory as MonoSamp.exe and that didn't work even though MonoSamp.exe does work from there.

objarni's picture

After you have solved this, please add the knowledge gained in the OpenTK FAQ so others do not have to reinvent the wheel ;)

BlueMonkMN's picture

OK, so really stupid error that I solved while I wasn't even at the computer, just reviewing the error messages in my head (which magically seems to work best first thing in the morning -- my head that is). Some of this info may be suitable for the FAQ, but this is so stupid, I don't know if this is :). We pretty much eliminated the config file as the problem yesterday and the project file was practically identical. So what's left? The code. Somehow I had flubbed the code. I vaguely remembered seeing the two error messages were complaining about "libfmodex-4.22.01.so" and "fmodex" and it hit me that the fmodex error message didn't have a ".dll" on the end so I figured I must have forgotten to put the ".dll" on the end when I was in Windows reverting that version of the source code back to a state that was the same for both Windows and Linux. Indeed that's what it was. Sorry for the run around, but I did learn a couple things about the config file in the process. Would you believe "April Fool!"? :)

the Fiddler's picture

Glad you sorted it out. :)

Sometimes I think this must be some kind of natural law, what other explanation is there? "The difficulty of locating an error is inversely proportional to its magnitude."

Or maybe its stupidity, I don't know: just the other day, I was hunting down a bug where one computer would receive oddly repeating data from its peer, when it was supposed to receive noise! Handshake? Check. Data flow? Check. Decoder? Looks fine. Final data? 0, 3, 6, ... 45, 0, 3, ... Turns out the data was correct all along, but the debugging code printed "i" instead of "channel_data[i]". Ugh.

It's also pretty interesting that errors like these are easier to catch a) in the morning and b) away from the code in question. A is obvious (you get tired as the day progresses), but b less so. It works though: take a 15-30' break (work on another part of the code, do something else) and when you get back, chances are the bug will become obvious.

BlueMonkMN's picture

The interesting thing is the Windows will accept and function correctly with either "fmodex" or "fmodex.dll". I wonder if mono should be smart enough to remap the same thing given either name.