-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlIx0A0ACgkQkX2Xpv6ydvR0uwCeLvnnsxTl4LNbFl1J21LvEXDi iuoAoOpCirT4B/O4x5AV+gleUUauXwNT =IRvg -----END PGP SIGNATURE----- _______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
