hi,
I tried to build Gem under Windows 7 with MinGW. It failed on pix_film with this error :
$ make Making all in src make[1]: Entering directory `/home/antoine/pd/externals/Gem/src' make all-recursive make[2]: Entering directory `/home/antoine/pd/externals/Gem/src' Making all in Gem make[3]: Entering directory `/home/antoine/pd/externals/Gem/src/Gem' UNUSED SOURCES: make[3]: Leaving directory `/home/antoine/pd/externals/Gem/src/Gem' Making all in RTE make[3]: Entering directory `/home/antoine/pd/externals/Gem/src/RTE' UNUSED SOURCES: make[3]: Leaving directory `/home/antoine/pd/externals/Gem/src/RTE' Making all in Utils make[3]: Entering directory `/home/antoine/pd/externals/Gem/src/Utils' UNUSED SOURCES: make[3]: Leaving directory `/home/antoine/pd/externals/Gem/src/Utils' Making all in Base make[3]: Entering directory `/home/antoine/pd/externals/Gem/src/Base' UNUSED SOURCES: make[3]: Leaving directory `/home/antoine/pd/externals/Gem/src/Base' Making all in plugins make[3]: Entering directory `/home/antoine/pd/externals/Gem/src/plugins' UNUSED SOURCES: make[3]: Leaving directory `/home/antoine/pd/externals/Gem/src/plugins' Making all in Controls make[3]: Entering directory `/home/antoine/pd/externals/Gem/src/Controls' UNUSED SOURCES: make[3]: Leaving directory `/home/antoine/pd/externals/Gem/src/Controls' Making all in Geos make[3]: Entering directory `/home/antoine/pd/externals/Gem/src/Geos' UNUSED SOURCES: make[3]: Leaving directory `/home/antoine/pd/externals/Gem/src/Geos' Making all in Manips make[3]: Entering directory `/home/antoine/pd/externals/Gem/src/Manips' UNUSED SOURCES: make[3]: Leaving directory `/home/antoine/pd/externals/Gem/src/Manips' Making all in Nongeos make[3]: Entering directory `/home/antoine/pd/externals/Gem/src/Nongeos' UNUSED SOURCES: make[3]: Leaving directory `/home/antoine/pd/externals/Gem/src/Nongeos' Making all in openGL make[3]: Entering directory `/home/antoine/pd/externals/Gem/src/openGL' UNUSED SOURCES: make[3]: Leaving directory `/home/antoine/pd/externals/Gem/src/openGL' Making all in Particles make[3]: Entering directory `/home/antoine/pd/externals/Gem/src/Particles' UNUSED SOURCES: make[3]: Leaving directory `/home/antoine/pd/externals/Gem/src/Particles' Making all in Pixes make[3]: Entering directory `/home/antoine/pd/externals/Gem/src/Pixes' /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../. ./src -I../../src -DGEM_INTERNAL -DGLEW_BUILD -DPD -I/home/antoine/pd/pd.git// src -g -O2 -freg-struct-return -mms-bitfields -O3 -falign-loops -falign-functio ns -falign-jumps -funroll-loops -ffast-math -mmmx -MT libPixes_la-pix_film.lo -M D -MP -MF .deps/libPixes_la-pix_film.Tpo -c -o libPixes_la-pix_film.lo `test -f 'pix_film.cpp' || echo './'`pix_film.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src -DGEM_INTERNA L -DGLEW_BUILD -DPD -I/home/antoine/pd/pd.git//src -g -O2 -freg-struct-return -m ms-bitfields -O3 -falign-loops -falign-functions -falign-jumps -funroll-loops -f fast-math -mmmx -MT libPixes_la-pix_film.lo -MD -MP -MF .deps/libPixes_la-pix_fi lm.Tpo -c pix_film.cpp -DDLL_EXPORT -DPIC -o .libs/libPixes_la-pix_film.o pix_film.cpp: In constructor 'pix_film::pix_film(t_symbol*)': pix_film.cpp:192:46: error: no matching function for call to 'ptw32_handle_t::pt w32_handle_t(int)' pix_film.cpp:192:46: note: candidates are: c:\mingw\bin../lib/gcc/mingw32/4.6.2/../../../../include/pthread.h:583:3: note: ptw32_handle_t::ptw32_handle_t() c:\mingw\bin../lib/gcc/mingw32/4.6.2/../../../../include/pthread.h:583:3: note: candidate expects 0 arguments, 1 provided c:\mingw\bin../lib/gcc/mingw32/4.6.2/../../../../include/pthread.h:583:3: note: ptw32_handle_t::ptw32_handle_t(const ptw32_handle_t&) c:\mingw\bin../lib/gcc/mingw32/4.6.2/../../../../include/pthread.h:583:3: note: no known conversion for argument 1 from 'int' to 'const ptw32_handle_t&' pix_film.cpp: In member function 'virtual void pix_film::closeMess()': pix_film.cpp:268:15: error: no match for 'operator=' in '((pix_film*)this)->pix_ film::m_thread_id = 0' pix_film.cpp:268:15: note: candidate is: c:\mingw\bin../lib/gcc/mingw32/4.6.2/../../../../include/pthread.h:583:3: note: ptw32_handle_t& ptw32_handle_t::operator=(const ptw32_handle_t&) c:\mingw\bin../lib/gcc/mingw32/4.6.2/../../../../include/pthread.h:583:3: note: no known conversion for argument 1 from 'int' to 'const ptw32_handle_t&' make[3]: *** [libPixes_la-pix_film.lo] Error 1 make[3]: Leaving directory `/home/antoine/pd/externals/Gem/src/Pixes' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/antoine/pd/externals/Gem/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/antoine/pd/externals/Gem/src' make: *** [all-recursive] Error 1
I tried to disable pthread by adding --disable-threads flag to ./configure but it doesn't help. Does this flag only disable threading for make ?
note that configure with relative path to Pd doesn't work. (can't find m_pd.h)
best regards
a -- do it yourself http://antoine.villeret.free.fr
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-09-12 09:05, Antoine Villeret wrote:
hi,
I tried to build Gem under Windows 7 with MinGW.
cool. last time i tried, i *could* successfully compile Gem on w7/mingw. i'll have a look into your problem asap.
in any case, there is a substential problem with the MinGW build, and that is that all the Direct* plugins will *not* work. that is: no DirectShow video and movie sources. the rest *should* work just fine.
fgmasdr IOhannes
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
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 !
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 ?
+ a
-- do it yourself http://antoine.villeret.free.fr
2013/9/12 IOhannes m zmoelnig zmoelnig@iem.at
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-09-12 09:05, Antoine Villeret wrote:
hi,
I tried to build Gem under Windows 7 with MinGW.
cool. last time i tried, i *could* successfully compile Gem on w7/mingw. i'll have a look into your problem asap.
in any case, there is a substential problem with the MinGW build, and that is that all the Direct* plugins will *not* work. that is: no DirectShow video and movie sources. the rest *should* work just fine.
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlIxbNQACgkQkX2Xpv6ydvRlfACg7fbMx3YiUAK6Cv76iYjJZ1Xw RrEAn2DzcM0zBolscgpaMv4/Bv2l3oL3 =fvN1 -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----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 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
hello,
sorry no news, I didn't work again on this since September
but I do have a working gem.dll from Visual C++ which seems to work but it's on a machine at home and I'm far from it now... i can send it to you for testing if you want and i can even make it available to the community if it sounds a good idea for most of you...
I will be back at home in one week
best
a
-- do it yourself http://antoine.villeret.free.fr
2013/10/16 Nicolas Montgermont nicolas_montgermont@yahoo.fr
-----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-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-
Antoine Villeret -
IOhannes m zmoelnig -
Nicolas Montgermont