Hallo devs!
I just "ported" the threaded soundfiler from Tim to main pd and as usual everything works on linux, but I tried now (hard) two days to make it work on win ... and I really don't know whats all about ... (tried on MinGW and msvc)
anyway, here is the problem:
1) 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 ?
2) So I simply also implemented this function in my external (because of the unresolved external), but it really BEHAVES DIFFERENT ! I don't know why, it compiles fine, no warning etc. (with MinGW + msvc) - but I always get a -1 returned from int bytesread = read(fd, buf, READHDRSIZE); read of <io.h> (same as in d_soundfile line 219) ?? (and it's no threading issue, because I simply copied the soundfiler code for debugging ...)
I really tried all different defines and link against different libs (like in the makefile of pd) ... but I have not much experience with windows compiling/linking ...
if someone wants to look into the code (especially into the windows makefiles): http://grh.mur.at/threadlib.tar.gz
Thanks, LG Georg
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 ...
So I simply also implemented this function in my external (because of the unresolved external), but it really BEHAVES DIFFERENT ! I don't know why, it compiles fine, no warning etc. (with MinGW + msvc)
- but I always get a -1 returned from
int bytesread = read(fd, buf, READHDRSIZE); read of <io.h> (same as in d_soundfile line 219) ?? (and it's no threading issue, because I simply copied the soundfiler code for debugging ...)
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 ...
cheers ... tim
Hallo!
hm ... why are you using pd's soundfile functions in the first place? libsndfile provides a much more powerful wave file parser than pd ...
yes, libsndfile is of course more powerfull, but in the moment I only want to load simple files ... like with soundfiler, but threaded. (And I don't want to spend more time on this now - because I have what I want - on linux)
And now I also want to understand this crazy behaviour ;) It's really the same code (copy+paste from d_soundfile.c) - but it behaves different !!? (on linux it behaves in the same way as the internal soundfiler)
Thanks for any hints, LG Georg
Hallo!
hm ... why are you using pd's soundfile functions in the first place? libsndfile provides a much more powerful wave file parser than pd ...
okay, I rewrote it now with libsndfile ... I should have done that earlier because it took me much less time then all the debugging on windows ... ;)
LG Georg
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..
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~..
Hallo!
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..
well, I made all that stuff ... in windows you cannot use any non-static function of pd which is not declared explicitely as __declspec(dllexport) extern (don't know the right syntax now ...) - correct me if I'm wrong ...
true, and libsndfile compiles in MinGW at least, used it for readanysf~..
you compiled readanysf~ on win? - I think there are for sure some windows guys interested in it ... :)
LG Georg
well, I made all that stuff ... in windows you cannot use any non-static function of pd which is not declared explicitely as __declspec(dllexport) extern (don't know the right syntax now ...) - correct me if I'm wrong ...
it should work in MinGW without explicit export (just add /path/to/pd.dll to LFLAGS, and -mms-bitfields to CFLAGS if you want MSVC ABI compatibility).
at least it never had problems with ggee or yves gui objects that linked to private-header stuff..but maybe it was all declared EXTERN?
#if defined(MSW) && !defined (__GNUC__) #ifdef PD_INTERNAL #define EXTERN __declspec(dllexport) extern #else #define EXTERN __declspec(dllimport) extern #endif /* PD_INTERNAL */ #else #define EXTERN extern #endif /* MSW */
..sorry, lost the win32 binaries, but all readanysf~ deps compiled with ./configure && make install in MinGW
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
-
carmen -
Georg Holzmann -
Hans-Christoph Steiner -
Tim Blechmann