Hello Everyone
So, after all the fussm the other day about compiling Pd on Fedra Core 4, I fonally managed to get Pd working. I am not sure I remember how I did it, but it involved a somhat intuitive, somewhat logical shifting of directories containing the relevant .h files.
Now I want to compile GEM to run with Pd on Linux (yikes!), and I expect plenty of fudging around, to make sure that all the proper libraries are installed &c. I do have a simple question that I hope will speed up the compilation process, though. When the GemLibs documentation says:
put the GemLibs near your Gem-src path. something like: <src>/GemLibs/ <src>/gem-<version>/src
... then, by "Gem-src path", do they mean the location within the Pd directory where the source code for GEM resides? (i.e. /home/david/pd/extra/gem/src) Or would the GemLibs source reside in a location closer to the libraries upon which gem/pd are dependent? (i.e. /lib/src/GemLibs)
I understand that I will have to feel around to figure out exactly where all of my .h files should go. But if I can know to put the source code within the Pd directory, or near more general source libraries, then I think the process of figuring ou whre everything goes would be a lot simpler.
As always, thanks in advance, and apologies if I am being dense here. ;-)
David
David Kendall wrote:
Hello Everyone
So, after all the fussm the other day about compiling Pd on Fedra Core 4, I fonally managed to get Pd working. I am not sure I remember how I did it, but it involved a somhat intuitive, somewhat logical shifting of directories containing the relevant .h files.
Now I want to compile GEM to run with Pd on Linux (yikes!), and I expect plenty of fudging around, to make sure that all the proper libraries are installed &c. I do have a simple question that I hope will speed up the compilation process, though. When the GemLibs documentation says:
put the GemLibs near your Gem-src path. something like: <src>/GemLibs/ <src>/gem-<version>/src
... then, by "Gem-src path", do they mean the location within the Pd directory where the source code for GEM resides? (i.e. /home/david/pd/extra/gem/src) Or would the GemLibs source reside in a location closer to the libraries upon which gem/pd are dependent? (i.e. /lib/src/GemLibs)
it doesn't need to be somewhere near pd (though m_pd.h should be in an accesible path, like /usr/local/include or the like)
what i meant in the docs is: if GemLibs are here: /path/to/wherever/GemLibs/ then Gem's config.h-file should be here: /path/to/wherever/Gem/src/Base/config.h (or, alternatively, if the gem-sources come with version-number) /path/to/wherever/gem-0.90/src/Base/config.h
anyhow, it might well be that the GemLibs are not needed altogether on your distribution (i'm no specialist with fedora)
provided by GemLibs are following libraries: libjpeg libtiff GLTT + freetype but all of them are most probably outdated
if it is an option for you, i would try to install (at least) the following development-packages from your distribution (probably the names are not 100% correct) libjpeg-devel libtiff-devel libftgl-devel + freetype2-devel
hint: try to not use GLTT, but rather FTGL!
hint: if you are using the CVS-version of Gem (i'd recommend this), you can additionally use ImageMagick++-devel AND all of the image-libraries (jpeg, tiff, imagemagick) are _optional_ (this is: Gem will still compile and run (with limited functionality though) if you don't have any or one of this libraries)
please report back which packages did work for you.
mfg.asd.r IOhannes
Thanks for the advice Iohannes. I think I will give the CVS version of GEM a shot. I have not yet used a CVS, but I would imagine everything I need to know is documented clearly enough to make that process relatively straightfoward.
Then I suppose I will go to rpmfinder.net, and download libjpeg-devel, libtiff-devel, libftgl-devel, freetype2-devel and ImageMagick++-devel. If any of those libraries are installed in my OS, then I think that the OS will notify me, and I can skip installation for those libraries.
As I install, I will make sure to pay attention to the config.h file, so I can know where GEM is looking for its libraries.
I will report back to you with exactly what libraries I end up using in the install process.
cheers,
David K.
it doesn't need to be somewhere near pd (though m_pd.h should be in an accesible path, like /usr/local/include or the like)
what i meant in the docs is: if GemLibs are here: /path/to/wherever/GemLibs/ then Gem's config.h-file should be here: /path/to/wherever/Gem/src/Base/config.h (or, alternatively, if the gem-sources come with version-number) /path/to/wherever/gem-0.90/src/Base/config.h
anyhow, it might well be that the GemLibs are not needed altogether on your distribution (i'm no specialist with fedora)
provided by GemLibs are following libraries: libjpeg libtiff GLTT + freetype but all of them are most probably outdated
if it is an option for you, i would try to install (at least) the following development-packages from your distribution (probably the names are not 100% correct) libjpeg-devel libtiff-devel libftgl-devel + freetype2-devel
hint: try to not use GLTT, but rather FTGL!
hint: if you are using the CVS-version of Gem (i'd recommend this), you can additionally use ImageMagick++-devel AND all of the image-libraries (jpeg, tiff, imagemagick) are _optional_ (this is: Gem will still compile and run (with limited functionality though) if you don't have any or one of this libraries)
please report back which packages did work for you.
mfg.asd.r IOhannes
Hi Iohannes
I have finally managed the time to install a few rpm packages, hoping to make it possible for GEM to compile on my Fedora Core 4 OS. So far, I have managed to go through my install disks to find and install these rpms:
ImageMagick-c++-devel-6.2.2.0-2.i386.rpm freeglut-2.2.0-16.i386.rpm freeglut-devel-2.2.0-16.i386.rpm freetype-2.1.9-2.i386.rpm freetype-demos-2.1.9-2.i386.rpm freetype-utils-2.1.9-2.i386.rpm gltt-devel-2.5.2-2.i386.rpm
I have confirmed that libjpeg and libtiff are installed on my system, as well. I think that this leaves only libftgl, which is a package that I have not managed to locate, or determine if it is installed on my system at all. Anyway, when I go to gem-0.90.0/src/Gnu and I type ./makeauxlibs, I get a quick confirmation that my auxlibs are built. When I type ./configure, I get the following messages, and then the configure fails.
Judging from the messages below, would there be any way to understand which libraries are missing that Gem might be looking for? Any ideas would be greatly appreciated. I know that I am quickly running out of them, myself.
Thanks in advance.
David Kendall
[root@localhost Gnu]# ./configure loading cache ./config.cache HEAD: /usr/include /usr/local/include ../../../GemLibs/ LIBS: ../../../GemLibs/ /usr/local/lib /usr/local/src checking host system type... i686-pc-linux-gnu Configuring for Gem.pd_linux checking for gnu make... yes checking for c++... c++ checking whether the C++ compiler (c++ ) works... yes checking whether the C++ compiler (c++ ) is a cross-compiler... no checking whether we are using GNU C++... yes checking whether c++ accepts -g... yes checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for a BSD compatible install... /usr/bin/install -c checking whether make sets ${MAKE}... yes checking for sh... sh checking how to run the C preprocessor... gcc -E checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include checking for dnet_ntoa in -ldnet... no checking for dnet_ntoa in -ldnet_stub... no checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for MMX... checking MMX found... Building Auxilliary Libraries =============================
Finished building Auxilliary Libraries
checking for main in -lX11... yes checking for main in -lXext... yes checking for XF86VidModeGetAllModeLines in -lXxf86vm... yes checking for sin in -lm... no checking for main in -lz... no checking for glInitNames in -lGL... no checking for glInitNames in -lMesaGL... no OpenGL is mandatory
David Kendall wrote:
Hi Iohannes
checking for glInitNames in -lGL... no checking for glInitNames in -lMesaGL... no OpenGL is mandatory
ähm. Gem is heavily based on openGL, so you need openGL(-devel) (and glu-devel) installed on your system. actually this is the only dependency of Gem that is an absolute must (well, apart from pd of course)
mfg.ads.r IOhannes
Thanks for the advice, but I think my problem may come from somewhere else. I have re-installed XFree86 now, and I have installed glu-devel, and OpenGLContext-2.0.0b1-1.src.rpm, which apears to have little or nothing to do with my particular OpenGL needs. I think I can assume I have all of the OpenGL tools that I need, installed as part of FC4.
This makes me wonder if perhaps the compiler is looking in the wrong places for the headers and includes. I notice at the beginning of compilation there is this message:
HEAD: /usr/include /usr/local/include ../../../GemLibs/ LIBS: ../../../GemLibs/ /usr/local/lib /usr/local/src
... perhaps if I can figure out exactly which files Gem is looking for, and I place these files in one or more of the above directories, then I may be able to compile successfully. what might the filenames be, that Gem is looking for when it compiles?
I hate to admit failure, but I am starting to suspect that Gem is incompatible with FC4 at this moment. Perhaps a different linux distro might prove more useful than FC4 in this endeavor. Still, if there is anything else I can try short of installing Debian or Suse, I would very much appreciate any remaining advice.
Thanks, David K.
On Sat, 2005-07-02 at 22:46 +0200, IOhannes m zmoelnig wrote:
David Kendall wrote:
Hi Iohannes
checking for glInitNames in -lGL... no checking for glInitNames in -lMesaGL... no OpenGL is mandatory
ähm. Gem is heavily based on openGL, so you need openGL(-devel) (and glu-devel) installed on your system. actually this is the only dependency of Gem that is an absolute must (well, apart from pd of course)
mfg.ads.r IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
David Kendall wrote:
Thanks for the advice, but I think my problem may come from somewhere else. I have re-installed XFree86 now, and I have installed glu-devel, and OpenGLContext-2.0.0b1-1.src.rpm, which apears to have little or nothing to do with my particular OpenGL needs. I think I can assume I have all of the OpenGL tools that I need, installed as part of FC4.
This makes me wonder if perhaps the compiler is looking in the wrong places for the headers and includes. I notice at the beginning of compilation there is this message:
HEAD: /usr/include /usr/local/include ../../../GemLibs/ LIBS: ../../../GemLibs/ /usr/local/lib /usr/local/src
this means nothing, it is just some information where Gem will do a deep search for requested headers/libraries. lik
... perhaps if I can figure out exactly which files Gem is looking for, and I place these files in one or more of the above directories, then I may be able to compile successfully. what might the filenames be, that Gem is looking for when it compiles?
I hate to admit failure, but I am starting to suspect that Gem is incompatible with FC4 at this moment. Perhaps a different linux distro might prove more useful than FC4 in this endeavor. Still, if there is anything else I can try short of installing Debian or Suse, I would very much appreciate any remaining advice.
this is very unlikely. until now, i have managed to compile Gem quite on every distro i ever got hands on (and where people asked me to compile Gem)
checking for glInitNames in -lGL... no checking for glInitNames in -lMesaGL... no OpenGL is mandatory
this just means that configure cannot link against libGL (do you have /usr/lib/libGL.{a,so} ?)
but this reminds me on a bug that was found with Gem on FC (so you are right: there is an issue with compiling Gem on your platform)
it has been fixed long ago in the CVS so i didn't remember it instantenously : i guess you are using the gem-0.90-0.tgz sources ??
either use the CVS-version of Gem or search the gem-dev archives http://lists.puredata.info/pipermail/gem-dev for "fedora" this should help you fix the problem.
mfg.a.dsr IOhannes
this just means that configure cannot link against libGL (do you have /usr/lib/libGL.{a,so} ?)
I will check for that file when I get back to that computer. I am a little embarrassed to admit that I did not use the CVS version like you suggested earlier. I will definitely install from the CVS version for my next attempt. In the meantime I will search the pd-list archives for earlier problems with fedora.
The problem above, where Gem is looking for an openGL header where Fedora Core may keep none, is related to my suspicions. I do hope that the CVS version will fix my problem. But I shall not give up, in any case. ;-)
Thanks again for all your help. I will report back to you with my progress as soon as I can get back to my linux box.
David
but this reminds me on a bug that was found with Gem on FC (so you are right: there is an issue with compiling Gem on your platform)
it has been fixed long ago in the CVS so i didn't remember it instantenously : i guess you are using the gem-0.90-0.tgz sources ??
either use the CVS-version of Gem or search the gem-dev archives http://lists.puredata.info/pipermail/gem-dev for "fedora" this should help you fix the problem.
mfg.a.dsr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, Jul 03, 2005 at 08:50:02AM -0700, David Kendall wrote:
this just means that configure cannot link against libGL (do you have /usr/lib/libGL.{a,so} ?)
I will check for that file when I get back to that computer. I am a little embarrassed to admit that I did not use the CVS version like you suggested earlier. I will definitely install from the CVS version for my next attempt. In the meantime I will search the pd-list archives for earlier problems with fedora.
The problem above, where Gem is looking for an openGL header where Fedora Core may keep none, is related to my suspicions. I do hope that the CVS version will fix my problem. But I shall not give up, in any case. ;-)
yeah, i posted about this problem months ago and got no response. configure fails even when libGL and such are there, perhaps its due to some ancient/conflicting version of autotools or a wacky .m4 file? in any case i reimplemented HSV2RGB as an abstraction since i couldnt figure it out either...
ix@replic.net wrote:
yeah, i posted about this problem months ago and got no response. configure fails even when libGL and such are there, perhaps its due to some ancient/conflicting version of autotools or a wacky .m4 file? in any case i reimplemented HSV2RGB as an abstraction since i couldnt figure it out either...
sorry if i didn't answered this before (i am sure, it has been discussed a dozen times though, but on gem-dev) the problem is due to a linker-flag that shouldn't be there searching the gem-dev archives for fedora i found (admittedly after a bit of digging) http://lists.puredata.info/pipermail/gem-dev/2005-03/000915.html
which quotes mike with the following: Change the following line in the ./configure script: LIBS="-Wl,-shared -Wl,-export-dynamic $LIBS" to: LIBS="-shared -Wl,-export-dynamic $LIBS"
this should do the trick
mfg.ad.r IOhannes
-
David Kendall -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
ix＠replic.net