(ups sorry - this should be for pd-dev)
Hallo Hans+list!
I just added PDContainer to the build system and have some questions:
o) I have to use g++, otherwise I cannot link the binary - is this okay for the compile farm ?
o) is it now, with the [declare] object, still necessary to make a binary out of each pd object ? (I made now one pdcontainer.pd_linux and installed it to /pd/extra/pdcontainer/ - but I think I have to split this into binaries for each object ?)
o) in externals/Makefile:
ifeq ($(OS_NAME),linux) [...] DYLIB_EXTENSION = dll [..] endif ifeq ($(OS_NAME),windows) [...] DYLIB_EXTENSION = so [...] endif
shouldn't this be exchanged ? (dll for windows and so for linux ?)
o) are there plans to make debian packages too ? (or what has to be done to make them work ?)
Thanks, LG Georg
On Jan 7, 2007, at 1:28 PM, Georg Holzmann wrote:
(ups sorry - this should be for pd-dev)
Hallo Hans+list!
I just added PDContainer to the build system and have some questions:
o) I have to use g++, otherwise I cannot link the binary - is this okay for the compile farm ?
That's fine. There are common targets for compiling .c, .cc, and .cpp files in externals/Makefile. These work on all platforms and properly handle having all the variables like CFLAGS overloaded so that we can do platform-specific builds. Look around line 88 in externals/Makefile. Above it you can see all the platform-specific build flags.
o) is it now, with the [declare] object, still necessary to make a binary out of each pd object ? (I made now one pdcontainer.pd_linux and installed it to /pd/extra/pdcontainer/ - but I think I have to split this into binaries for each object ?)
If you want to be able to load each class individually, then they need to be separate files, no matter which version of Pd. Everything in Pd-extended except Gem, PDP, and PiDiP are compiled this way (Cyrille recently converted pmpd). The namespace stuff won't work with multiple classes in one file, but you can still use such a library in Pd-extended, its just less than ideal.
o) in externals/Makefile:
ifeq ($(OS_NAME),linux) [...] DYLIB_EXTENSION = dll [..] endif ifeq ($(OS_NAME),windows) [...] DYLIB_EXTENSION = so [...] endif
shouldn't this be exchanged ? (dll for windows and so for linux ?)
Yup, thanks for spotting that. That stuff is not used yet. That will be for compiling shared code as a separate dynamic library, so that things like Gem and PDP can be built as one-class-per-file libdir format. If you have a lot of shared code in PDContainer, then maybe you could try to get this working. Basically, you would build all the shared code into a pdcontainer.(so|dylib|dll), then each class as my_class.pd_extension. Each class would have to know how to find the shared library, but that shouldn't be too hard. Thomas Grill has built Flext like this.
o) are there plans to make debian packages too ? (or what has to be done to make them work ?)
That would be lovely. A number of people have talked about making Debian packges from the Pd-extended build system, I don't think it would be that hard. But so far no one has done it. I would happily assist.
.hc
Thanks, LG Georg
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
There is no way to peace, peace is the way. -A.J. Muste
Hallo!
o) I have to use g++, otherwise I cannot link the binary - is this okay for the compile farm ?
That's fine. There are common targets for compiling .c, .cc, and .cpp files in externals/Makefile. These work on all platforms and properly handle having all the variables like CFLAGS overloaded so that we can do platform-specific builds. Look around line 88 in externals/Makefile. Above it you can see all the platform-specific build flags.
Ah thanks - I have overlooked that ...
If you want to be able to load each class individually, then they need to be separate files, no matter which version of Pd. Everything in
okay - so now I have a c++ question:
when I try to link the single externals, I always get the error (e.g.)
load_object: Symbol "h_vector_setup" not found
but I link against the object with this funcion (and it's no problem if I compile it as a pd-library) - has anyone an idea what can be wrong here ?
Because I also added adaptive to the buildsys, which is plain C, and there I link the objects in the same way and it works ...
LG Georg
On Sun, 7 Jan 2007, Georg Holzmann wrote:
okay - so now I have a c++ question: when I try to link the single externals, I always get the error (e.g.) load_object: Symbol "h_vector_setup" not found but I link against the object with this funcion (and it's no problem if I compile it as a pd-library) - has anyone an idea what can be wrong here ? Because I also added adaptive to the buildsys, which is plain C, and there I link the objects in the same way and it works ...
Are you really sure that it's not a question of using extern "C" {...}; declarations to turn off overloading of names so that it stays compatible with C ?
Maybe you added the h_vector_setup() decl within a big extern "C" block and didn't notice?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo!
Are you really sure that it's not a question of using extern "C" {...}; declarations to turn off overloading of names so that it stays compatible with C ?
Thanks Marhieu, that's it!
I have to use extern "C" with all the setup functions!
(And I only had one extern "C" to call the whole library ...)
LG Georg
Hallo!
Yup, thanks for spotting that. That stuff is not used yet. That will be for compiling shared code as a separate dynamic library, so that things like Gem and PDP can be built as one-class-per-file libdir format. If you have a lot of shared code in PDContainer, then maybe you could try to get this working. Basically, you would build all the shared code into a pdcontainer.(so|dylib|dll), then each class as my_class.pd_extension. Each class would have to know how to find the shared library, but that shouldn't be too hard. Thomas Grill has built Flext like this.
Okay, I build now a shared library because I have a lot of shared code - it will be installed in the same directory as the pd externals.
But I am curious, if this also will compile on other platforms (now only tested on linux) ... ;)
LG Georg
Hallo!
Okay, I build now a shared library because I have a lot of shared code - it will be installed in the same directory as the pd externals.
Hm - I just noted that the shared library can't be found now...
Where do I have to install them now on all the platforms ? E.g. on linux do I have to install it now to /usr/lib or something similar - or is it also possible to install it somewhere relative to the pd binary ?
Thanks, LG Georg
On Jan 8, 2007, at 1:21 PM, Georg Holzmann wrote:
Hallo!
Okay, I build now a shared library because I have a lot of shared code - it will be installed in the same directory as the pd externals.
Hm - I just noted that the shared library can't be found now...
Where do I have to install them now on all the platforms ? E.g. on linux do I have to install it now to /usr/lib or something similar - or is it also possible to install it somewhere relative to the pd binary ?
Wow, that's great that you have a shared library already! Since Pd- extended is built with gcc on all platforms, porting the build process to other platforms isn't too difficult, its mostly a matter of getting the right flags, which are listed in externals/Makefile.
As for using the shared library, I think that you have to explicitly load it in each external. You can look at pd/src/s_loader.c to see how Pd does it. An external is just a shared libray that Pd loads, so its the same mechanism.
.hc
Thanks, LG Georg
------------------------------------------------------------------------
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
On Mon Jan 08, 2007 at 04:30:20PM -0500, Hans-Christoph Steiner wrote:
On Jan 8, 2007, at 1:21 PM, Georg Holzmann wrote:
Hallo!
Okay, I build now a shared library because I have a lot of shared code - it will be installed in the same directory as the pd externals.
Hm - I just noted that the shared library can't be found now...
Where do I have to install them now on all the platforms ? E.g. on linux do I have to install it now to /usr/lib or something similar - or is it also possible to install it somewhere relative to the pd binary ?
Wow, that's great that you have a shared library already! Since Pd-extended is built with gcc on all platforms, porting the build process to other platforms isn't too difficult, its mostly a matter of getting the right flags, which are listed in externals/Makefile.
As for using the shared library, I think that you have to explicitly load it in each external. You can look at pd/src/s_loader.c to see how Pd does it. An external is just a shared libray that Pd loads, so its the same mechanism.
maybe the dlopen part. the library search part is hand-rolled. so putting things in /usr/lib won't get youa nything..
.hc
Thanks, LG Georg
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo!
Wow, that's great that you have a shared library already! Since Pd-extended is built with gcc on all platforms, porting the build process to other platforms isn't too difficult, its mostly a matter of getting the right flags, which are listed in externals/Makefile.
It (should) build already on all platform - but it doesn't find the library ...
As for using the shared library, I think that you have to explicitly load it in each external. You can look at pd/src/s_loader.c to see how Pd does it. An external is just a shared libray that Pd loads, so its the same mechanism.
Hm ... can't this be made easier ? E.g. if I link the externals to the shared library with the hardcoded path it works - but I cant' do that of course and so the externals can't finde the library.
So is there a way how the externals can find the shared library, whithout copying it into a global library path like /usr/lib/ ?
Thanks, LG Georg
On Jan 8, 2007, at 4:52 PM, Georg Holzmann wrote:
Hallo!
Wow, that's great that you have a shared library already! Since Pd-extended is built with gcc on all platforms, porting the build process to other platforms isn't too difficult, its mostly a matter of getting the right flags, which are listed in externals/ Makefile.
It (should) build already on all platform - but it doesn't find the library ...
As for using the shared library, I think that you have to explicitly load it in each external. You can look at pd/src/ s_loader.c to see how Pd does it. An external is just a shared libray that Pd loads, so its the same mechanism.
Hm ... can't this be made easier ? E.g. if I link the externals to the shared library with the hardcoded path it works - but I cant' do that of course and so the externals can't finde the library.
So is there a way how the externals can find the shared library, whithout copying it into a global library path like /usr/lib/ ?
I think you can link to it using a relative path, or even better, just the same dir, i.e. "." Mac OS X has handy tools for managing library paths (otool -L and install_name_tool), I don't know about other platforms.
.hc
Thanks, LG Georg
------------------------------------------------------------------------
All information should be free. - the hacker ethic
Hallo!
So is there a way how the externals can find the shared library, whithout copying it into a global library path like /usr/lib/ ?
It seems that the only way is, to add the /full/path/to/installed/library/directory to the LD_LIBRARY_PATH variable before starting pd ...
I think you can link to it using a relative path, or even better, just the same dir, i.e. "." Mac OS X has handy tools for managing library paths (otool -L and install_name_tool), I don't know about other platforms.
"." does not work on linux - I would have to install the library first and then link it to the full path where I have it installed.
So it seems that the only way is to use dlopen() - where I have to modify the source (and handle it seperate for all platforms in the source file ...). I think it's not worth to do that for PDContainer - but we can continue to think about it if we can also use it for other externals ;)
LG Georg
On Tue Jan 09, 2007 at 12:03:14AM +0100, Georg Holzmann wrote:
Hallo!
So is there a way how the externals can find the shared library, whithout copying it into a global library path like /usr/lib/ ?
It seems that the only way is, to add the /full/path/to/installed/library/directory to the LD_LIBRARY_PATH variable before starting pd ...
I think you can link to it using a relative path, or even better, just the same dir, i.e. "." Mac OS X has handy tools for managing library paths (otool -L and install_name_tool), I don't know about other platforms.
"." does not work on linux - I would have to install the library first and then link it to the full path where I have it installed.
So it seems that the only way is to use dlopen() - where I have to modify the source (and handle it seperate for all platforms in the source file ...). I think it's not worth to do that for PDContainer - but we can continue to think about it if we can also use it for other externals ;)
how about modifying s_loader to also check in system paths for externals.. then you could reuse the same method regardless of whether its external to PD, or external to PD externals..
LG Georg
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
carmen -
Georg Holzmann -
Hans-Christoph Steiner -
Mathieu Bouchard