On Nov 17, 2005, at 4:35 AM, carmen wrote:
On Wed, Nov 16, 2005 at 01:33:10PM +0000, Tim Blechmann wrote:
hi georg,
the soundfiler uses open_soundfile from d_soundfile.c to open a file. this function is not part of the public interface of pd - in linux I can forward declare it and I can use it - in windows I always get an unresolved external ... ... is there any way to link it so that I can use this in win like in linux ?
no, there is no way that i know of ...
the main difference is just that linux doesnt care about resolving symbols at compile time, where windows does. so if you add pd.dll (mingw) or pd.lib (msvc) to linker arguments it should work. and make sure theres no 'static' preceding the definition of the function..
Make sure to "strip" after linking against pd.dll, otherwise each resulting .dll will have a copy of pd.dll in it, which can add up quickly. Look at externals/build/win/makefile for an example (I am currently using the exact same strip command as in externals/linux/makefile).
hm ... why are you using pd's soundfile functions in the first place? libsndfile provides a much more powerful wave file parser than pd ... after using it for my sndfiler, i don't want to use anything else any more ...
true, and libsndfile compiles in MinGW at least, used it for readanysf~..
It would be great to have readanysf~ included in the upcoming extended builds. I can help you get incorporated, it shouldn't be too hard.
.hc
________________________________________________________________________ ____
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously.
- Benjamin Franklin