-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello antoine,
Do you have any news for this? Do you have a binary accompanied with dll we can test? thanks, best, n Le 12/09/13 16:30, IOhannes m zmoelnig a écrit : > On 2013-09-12 16:24, Antoine Villeret wrote: > > hi, > > > I found a workaround by putting the allocation in a #ifndef _WIN32 > > statement pthread_t is a structure under windows and not only a > > 64bit int. > > > with pd-vanilla I got : > > "C:\\MinGW\\msys\\1.0\\home\\antoine\\pd\\pd-vanilla\\extra\\Gem\\Gem.dll: > > > > couldn't load > > Gem: can't load library" > > > on startup... maybe because pd was build using microsoft compiler > > and Gem with MinGW > > no, this shouldn't be a problem. > C-binaries are compatible between different compilers, C++-binaries > are not. > Pd only has a C-interface, so there shouldn't be a problem. > otoh, Gem's plugins are all C++, that's the reason why Direct*-plugins > don't work with a mingw build. > > > > I also managed to produce a Gem.dll form Microsoft Visual C++ 2010 > > Express and this time Gem loads in pd-vanilla 0.45.2 > > > and it seems to work ! > > cool. > > > > but i am wondering if i am doing right : Gem claims that some dll > > are missing and I added them directly to the Windows\System32 > > folder should I include them in the Visual Project instead ? > > you should be able to put them besides Gem.dll. > if that doesn't work, put them besides pd.exe. > Windows\System32 is a *bad* place. > > fgvmadsr > IOhannes > > _______________________________________________ > GEM-dev mailing list > [email protected] > http://lists.puredata.info/listinfo/gem-dev > - -- http://www.nimon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAlJe0i4ACgkQyQxFEQ9xedOtBACfdCuTWXOcqH9TX64grOhW76S9 fsAAnjzfElqTBJHMaXYfTvikOtJirjyH =VowC -----END PGP SIGNATURE-----
_______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
