-----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
> GEM-dev@iem.at
> 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-----