hi, still busy with my PIII's. trying to build a Pd-ext without SSE2 for Windows. following the Pd-webpage for it. (i guess there's not an easier way to go)
i got stuck in ./building-libs-on-mingw.sh
"/bin/install:cannot stat 'pkgIndex.tcl': No such file or directory"
and after that a lot of lib directories are not found.
is it possible that the webpage is not in sync with the script and/or sources? or is it only one lib missing (which i hope).
another question: in the beginning of this building script i had to change the flags from pentium4 to pentium3. will this be enough? i hope the scripts are not taking the parameters from the machine on which the building is done (which is in my case a P4).
thanks,rolf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-01-23 21:54, rolf meesters wrote:
hi, still busy with my PIII's. trying to build a Pd-ext without SSE2 for Windows. following the Pd-webpage for it. (i guess there's not an easier way to go)
i got stuck in ./building-libs-on-mingw.sh
building Gem on mingw is _highly_ experimental and _only_ works with a recent git checkout.
there is close to zero chance that you can compile an older version of Gem (e.g. the latest and greatest stable release 0.93.3) with anything but visualstudio.
even then it is a big nightmare to setup (at least for me who barely uses w32 and/or it's development environment) - if you need anything but the core functionality.
if you can live without font support and the plugins for image (image loading, video loading, movie loading) acquisition work (they _might_ work on P3, but of course i never tested) or you can do without them, it should be fairly easy to compile:
- edit the file "configNT.h" (you should find that in your project
browser under Gem/config/ or Gem/Gem/ or Gem/Base/) by commenting out all defines about FTGL (that's probably only one at the beginning of the file)
- open the solution file matching your compiler best (e.g.
./build/win-vs2008/Gem.sln should work if you have VisualStudio-2008; if you have a newr IDE just pick the most recent and upgrade the project)
- remove all libraries with "ftgl" or "freetype" in their name from the
project settings (linker input).
- to turn off SSE2 support, go (again) to the project preferences, go
the C/C++|Preprocessor and remove __MMX__ and __SSE2__
- under C/C++|Codegeneration disable SIMD extensions
- recompile the "Gem" project (recompiling the entire solution most
likely won't work if you don't have the dependencies for all thos plugins installed in the right places)
mfgasdr IOhannes
Hello.
Envoyé: Mardi 24 Janvier 2012 09:30:18 Objet: Re: [PD] building Pd-ext/GEM for Windows
On 2012-01-23 21:54, rolf meesters wrote:
hi, still busy with my PIII's. trying to build a Pd-ext without SSE2 for Windows. following the Pd-webpage for it. (i guess there's not an easier way to go)
i got stuck in ./building-libs-on-mingw.sh
building Gem on mingw is _highly_ experimental and _only_ works with a recent git checkout.
So it works?!
After removing pix_film from pixes, compilation goes to linking but I've got this:
Creating library file: .libs/Gem.dll.a
Base/.libs/libBase.a(libBase_la-CPPExtern.o):C:\msys\1.0\home\patko\pd-extended
0.43\externals\gem\Gem\src\Base/CPPExtern.cpp:171: undefined reference to `sys_c
lose'
any idea about how to fix it?
On 01/28/12 11:18, Patrice Colet wrote:
building Gem on mingw is _highly_ experimental and _only_ works with
So it works?!
yes.
After removing pix_film from pixes, compilation goes to linking but I've got this:
why? all the dependency stuff (e.g. quicktime,...) is factored out into plugins; many plugins simply won't build on mingw yet (e.g. filmDS certainly won't; nobody tried filmQT yet; and plugins build with MSVC won't be usable in mingw builds; however, the plugins that can be build (e.g. videoVLC) are fully usable)
Creating library file: .libs/Gem.dll.a Base/.libs/libBase.a(libBase_la-CPPExtern.o):C:\msys\1.0\home\patko\pd-extended
0.43\externals\gem\Gem\src\Base/CPPExtern.cpp:171: undefined reference to `sys_c lose'any idea about how to fix it?
use Pd-0.43 or Pd-0.42 throughout...it seems like you are using Pd-0.43 headers but then you are linking with a 0.42 pd.lib ; you should not mix.
fgmasdr IOhannes
building Gem on mingw is _highly_ experimental and _only_ works with a
recent git checkout.
there is close to zero chance that you can compile an older version of Gem (e.g. the latest and greatest stable release 0.93.3) with anything but visualstudio.
even then it is a big nightmare to setup (at least for me who barely uses w32 and/or it's development environment) - if you need anything but the core functionality.
if you can live without font support and the plugins for image (image loading, video loading, movie loading) acquisition work (they _might_ work on P3, but of course i never tested) or you can do without them, it should be fairly easy to compile:
- edit the file "configNT.h" (you should find that in your project
browser under Gem/config/ or Gem/Gem/ or Gem/Base/) by commenting out all defines about FTGL (that's probably only one at the beginning of the file)
- open the solution file matching your compiler best (e.g.
./build/win-vs2008/Gem.sln should work if you have VisualStudio-2008; if you have a newr IDE just pick the most recent and upgrade the project)
- remove all libraries with "ftgl" or "freetype" in their name from the
project settings (linker input).
- to turn off SSE2 support, go (again) to the project preferences, go
the C/C++|Preprocessor and remove __MMX__ and __SSE2__
- under C/C++|Codegeneration disable SIMD extensions
great iohannes, thanks. a few points:
-- afaik the P3 has MMX & SSE & SIMD, why take this out?
-- to get going i started with the git-clone
git clone git://pd-gem.git.sourceforge.net/gitroot/pd-gem/Gem
is this 93.3?
-- at a first try: m_pd.h & pthread.h & sched.h were missing in the git-clone; i took them from the pd sources (0.43).
-- compiling only GEM gives a number of warnings. especially this one looks not right:
....\src\Gem\glew.cpp(247) : warning C4273: '__glewCopyTexSubImage3D' : inconsistent dll linkage d:\gem\src\gem\glew.h(12022) : see previous definition of '__glewCopyTexSubImage3D'
because it's given >2000 times, for every code that has to be glew'd. i guess there is some parameter for Windows not ok, but which one where?
-- is it eventually possible to use the recompiled GEM-93.3 in combination with Pd-ext 42.5? (still talking about Windows). i noticed before that GEM-93.3 needs a PthreadVC.dll which is not included in 42.5.
rolf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-01-24 23:05, rolf meesters wrote:
great iohannes, thanks. a few points:
-- afaik the P3 has MMX & SSE & SIMD, why take this out?
it does not come with SSE2 so you should take this out.
-- to get going i started with the git-clone
git clone git://pd-gem.git.sourceforge.net/gitroot/pd-gem/Gem
is this 93.3?
it is everything since Gem was checked into a public repository. with an ordinary git clone you get the full history (in this case, back to Gem-0.87 in 2002)
the default branch is "master" which is where current development is going on (that is: it's unstable) if you are feeling less adventurous, checkout the 0.93 branch which will currently be 0.93.3 (+ some minor bugfixes that did not make it into a 0.93.4 release yet)
-- at a first try: m_pd.h & pthread.h & sched.h were missing in the git-clone;
no they are not missing. they are not part of Gem, so they do not come with Gem.
i took them from the pd sources (0.43).
you should remove those files from your Gem directory and instead add the path to Pd to your "additional include paths" and "additional library paths" in the project settings.
Gem make some guesses where it could find those headers, but since there is no consistent install directory on w32 those guesses will more likely be wrong than correct.
-- compiling only GEM gives a number of warnings. especially this one looks not right:
....\src\Gem\glew.cpp(247) : warning C4273: '__glewCopyTexSubImage3D' : inconsistent dll linkage d:\gem\src\gem\glew.h(12022) : see previous definition of '__glewCopyTexSubImage3D'
because it's given >2000 times, for every code that has to be glew'd. i guess there is some parameter for Windows not ok, but which one where?
fortunately it is only a warning and not an error. so you can safely ignore it (at least that's what i did the last few years...) afaik this should be fixed in the master branch (either in commit:ba9e4623d61aff41 or in commit:69519ea2c27c8f1, some 10 days ago)
-- is it eventually possible to use the recompiled GEM-93.3 in combination with Pd-ext 42.5?
yes, there shouldn't be a problem.
the Gem that comes with PdX is not build for PdX: instead i turn on my w32 build machine, create a binary (compiled against Pd-vanilla), and upload it to gem.iem.at; hans then downloads it and includes it into the Pd-extended installers.
(still talking about Windows). i noticed before that GEM-93.3 needs a PthreadVC.dll which is not included in 42.5.
it's the pthread implementation used by Pd-vanilla. you could either use that or change the linker to use the pthread implementation used by PdX.
fgamsdr IOhannes
On Wed, Jan 25, 2012 at 9:25 AM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-01-24 23:05, rolf meesters wrote:
great iohannes, thanks. a few points:
-- afaik the P3 has MMX & SSE & SIMD, why take this out?
it does not come with SSE2 so you should take this out.
to make sure: i only take out SSE2
for the moment i keep going with the 'bleeding edge' source
-- don't know if i oversaw it, or something changed, anyway after all this warnings about the dll's there's a fatal error: linker cannot find "b.obj"
? rolf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-01-25 19:19, rolf meesters wrote:
don't know if i oversaw it, or something changed, anyway after all this warnings about the dll's there's a fatal error: linker cannot find "b.obj"
this is a weird error, which i don't know about.
it looks to me as if you broke your project file. could you try getting a diff between your changed Gem.vcproj file and the one in master (in case you are using TortoiseGIT, there should be a nice "git diff" tool in the context menu) watch out for any stray "b"s.
fgmasdr IOhanne
http://lists.puredata.info/pipermail/pd-list/attachments/20120126/f8fb3f1a/attachment-0001.bin
On 2012-01-25 19:19, rolf meesters wrote:
don't know if i oversaw it, or something changed, anyway after all this warnings about the dll's there's a fatal error: linker cannot find "b.obj"
this is a weird error, which i don't know about.
it looks to me as if you broke your project file. could you try getting a diff between your changed Gem.vcproj file and the one in master (in case you are using TortoiseGIT, there should be a nice "git diff" tool in the context menu) watch out for any stray "b"s.
that was a good guess, i found a stray "b" in the project file. but i didn't do it. i downloaded everything again from the git. it's in the win-vs2008 gem.vcproj
Name="VCLinkerTool" AdditionalOptions="/MACHINE:I386" AdditionalDependencies="pd.lib opengl32.lib glu32.lib b freetype235mt_D.lib FTGL.lib ws2_32.lib pthreadVC.lib"
so, taking this out (and the freetype & FTGL libs) it got again stuck with a missing pthreadVC.lib.
it was already very hard to find the needed pthread.h. (i did clean up my disc's and then it was gone). it's not in the 'regular' gits of pd-van or pd-ext. i only found something following a download advise for the Pd/sources in the page for building Pd on Windows .
but no pthreadVC.lib or pthread.lib.
googling didn't bring me useful wisdom here.
where to get, buy, borrow, steal it?
rolf
On 2012-01-26 13:28, rolf meesters wrote: ...
but no pthreadVC.lib or pthread.lib.
If you get Miller's vanilla Pd for Windows, pthreadVC.lib is in pd/bin.
See http://crca.ucsd.edu/~msp/software.html
Martin
On 01/26/12 19:28, rolf meesters wrote:
http://lists.puredata.info/pipermail/pd-list/attachments/20120126/f8fb3f1a/attachment-0001.bin
that was a good guess, i found a stray "b" in the project file. but i didn't do it. i downloaded everything again from the git. it's in the win-vs2008 gem.vcproj
confirmed (and removed). thanks,
usually i don't do "Debug" builds so i didn't notice...
mfgdasr IOhannes
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Martin Peach -
Patrice Colet -
rolf meesters