The LibSndFile Update
I use libsndfile for one small routine in the editor to figure out the length in time of a sound file.So, download the current package, looks simple enough. Plug it in, environment variable, add include and lib directories to the project, run a build... and get a set of link errors.
It turns out that libsndfile is all c (with a nice c++ wrapper now) so I do a little coding and use the c++ wrapper class.Nice. Fiddle around with the includes and get the files in the project sorted out. (Previously I had libsndfile headers included directly in the project for some reason.
Anyway, get it all neat and tidy, run the build again... link errors. Easy enough. Verify the headers are being found on the include path, verify the link path ( uses the same environment variable)
Once I am happy that its not a weird typo or something in the link path, and I stuff around with a #pragma comment(lib,"libsndfile-1.lib") just to check that the file is being found.... I get back to the undefined sysmbol.
The symbols seem to be in the libsndfile-1.def file and in the .lib file. Much as the name mangling makes sense, at least it looks like its probably nearly there.
Anyway, guessing its due to the dll being compiled with a different compiler, the usual solution is to try to build it with my compiler, for my architecture etc. So pull down the source gz and unpack it. Then read the docs and find that due to the weakness in the MS C compiler, there is no way in hell I can compile a new copy.
Anyway, in the docs I find a reference to re-generating the .lib file from the .dll using the lib.exe tool. New one on me. Anyway, makes sense. All I need is to know the link points and the name mangling I guess and the linker does the rest.
The command line is:
lib /machine:i386 /def:libsndfile-1.def
But getting this command to run was incredibly frustrating.
Open a command promp in the lib directory. Try to run lib.exe. Cant be found. Find it and include it in the path. (C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\lib.exe)
Once I get that done, it will not run due to mspdb100.dll is missing...
Run a search and find there are about 4 copies of that file in different architecture directories and one in the Common7 directory. I guess common7. Try a little copy past magic... no love. Undo the copy paste hack.
Google a bit. Find references to using the VC command prompt... but its no longer included in the install. I know there is usually a batch file to set the environment for any command line play... where the sausage is that? Looks like a winner in the directory with lib.exe (vcvars32.bat) sounds nice.
So with a little command line magic, I run that batchfile and then lib.exe and ... fail again. WTF? Still no mspdb100.dll ? More googling... find a comment in a forum on stackoverflow mentions a different batch file (vcvarsall.bat). Doesn't say anything useful about it... Play hunt the file, contains a bit of batchfile magic which picks between architectures to set up an environment... so looks like a possibility. Run that... run lib.exe and tada.... lib.exe now works. .lib file is regenerated.
Build now works and link errors are banished. Now if I simply undo a couple of steps.. they should re-appear and confirm my understanding. <Undo steps to cause link errors> .... WTF? They are still not comming back.????????? Now I'm really confused.
Have I fixed the environment? Did I fix the .lib file? Did fairies just stop messing with me? What did I do to fix the freakin errors?
Ok, totally clean the output and do a rebuild.... still no link errors.... turn the linker onto verbose just to see what it sees...
Talk about frustrating. I can cause all the usual errors by messing with the linker additional library paths... but I cannot cause the undefined symbol errors again. Why not? I want my errors! (If only to prove that I didn't waste hours sorting it out because it a freakin typo or something.
Ok, working backward into the vcvarsall.bat and from there into the vcvars32.bat... there are a whole bunch of environment variables and paths being set that I probably cannot unset easily.
The main vars are:
VS100COMNTOOLS (Permanent Change)
LIBPATH (Temp Change)
LIB (Temp Change)
PATH (Permanent Change)
INCLUDE (Temp Change)
I would not expect enough to be different in the path and the VS100COMNTOOLS vars to "fix" the link errors but it seems the only possibility at the moment.
After some buggering around... there comes a point of diminishing returns to re-create an error that I did not want in the first place.
Need a copy of WinMerge to check the two lib files and try to determine if they are being regenerated or not.
Hmmm.. I'm out of time and need to move on to other things.... this is really frustrating.
No comments:
Post a Comment