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/dire
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
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, whic
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
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
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 th
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
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 tr
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 whol
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-libr
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 over
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. T
(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
binar
13 matches
Mail list logo
