hi federico; i, here trying the overlay for the first time tx for all those ebuilds!
have to say that the instructions for building pd under gentoo from this page by Nano Dust worked prefectly:
http://puredata.info/Members/nanodust/pd-extended-gentoo/?searchterm=gentoo
but when trying netpd i get this error:
U externals/maxlib/src/weibull.c U externals/maxlib/src/wrap.c
- Copying externals/maxlib from /usr/portage/distfiles/cvs-src/pure-data ...
- CVS module externals/maxlib is now in
/var/tmp/portage/media-plugins/maxlib-9999/work
- Fetching CVS module externals/maxlib into
/usr/portage/distfiles/cvs-src/pure-data ...
- Running cvs -q -f -z1 -d
":pserver:anonymous:@pure-data.cvs.sourceforge.net:/cvsroot/pure-data" login Logging in to :pserver:anonymous@pure-data.cvs.sourceforge.net:2401/cvsroot/pure-data
- Running cvs -q -f -z1 -d
":pserver:anonymous@pure-data.cvs.sourceforge.net:/cvsroot/pure-data" update -dP externals/maxlib
- Copying externals/maxlib from /usr/portage/distfiles/cvs-src/pure-data ...
- CVS module externals/maxlib is now in
/var/tmp/portage/media-plugins/maxlib-9999/work
Source unpacked. Compiling source in
/var/tmp/portage/media-plugins/maxlib-9999/work/externals/maxlib ... src/netrec.c: In function 'netrec_connectpoll': src/netrec.c:305: warning: pointer targets in passing argument 3 of 'accept' differ in signedness src/netserver.c: In function 'netserver_connectpoll': src/netserver.c:485: warning: pointer targets in passing argument 3 of 'accept' differ in signedness ld: warning: creating a DT_TEXTREL in object.
Source compiled. Test phase [not enabled]: media-plugins/maxlib-9999
Install maxlib-9999 into
/var/tmp/portage/media-plugins/maxlib-9999/image/ category media-plugins ACCESS DENIED mkdir: /usr/lib/pd/doc install: cannot create directory `/usr/lib/pd/doc': Permission denied make: *** [install] Error 1 /usr/portage/local/layman/pd-overlay/media-plugins/maxlib/maxlib-9999.ebuild: line 32: emake install failed: command not found
Completed installing maxlib-9999 into
/var/tmp/portage/media-plugins/maxlib-9999/image/
--------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-media-plugins_-_maxlib-9999-512.log"
mkdir: /usr/lib/pd/doc
Messages for package dev-util/cvs-1.12.12-r4:
If you want any CVS server functionality, you MUST emerge with USE=server!
Regenerating GNU info directory index...
i will get netpd and build from the main site; i know it will work like that.
/a
so what you got there with /usr/lib/pd and doc/ in there ?? who does that belong to to whatever ..check it out and emerge --resume then ..
ah, seems you got FEATURES=userpriv - so you might diasable thet .. but seems actually this a bug in the ebuild , it shouldn't try making that directory at 'install' stage. directories are made at the 'merge' stage
ACCESS DENIED mkdir: /usr/lib/pd/doc install: cannot create directory `/usr/lib/pd/doc': Permission denied make: *** [install] Error 1 /usr/portage/local/layman/pd-overlay/media-plugins/maxlib/maxlib-9999.ebuild: line 32: emake install failed: command not found
Completed installing maxlib-9999 into
/var/tmp/portage/media-plugins/maxlib-9999/image/
--------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-media-plugins_-_maxlib-9999-512.log"
mkdir: /usr/lib/pd/doc
i will get netpd and build from the main site; i know it will work like that.
/a
yeah, i think that's the ebuild which isn't very well written.
i wish i have done some ebuild .. but i only need a few externals - so compiled those manualy into my own prefix ;)
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
so what you got there with /usr/lib/pd and doc/ in there ?? who does that belong to to whatever ..check it out and emerge --resume then ..
no way-.-
ah, seems you got FEATURES=userpriv - so you might diasable thet .. but seems actually this a bug in the ebuild , it shouldn't try making that directory at 'install' stage.
CVS ebuilds (ebuilds that pull sources from VC repositories) are a hell. I promised myself to make periodically snapshots, so I wouldn't had such issues.
at te time I wrote the ebuild it worked fine.
directories are made at the 'merge' stage
ACCESS DENIED mkdir: /usr/lib/pd/doc install: cannot create directory `/usr/lib/pd/doc': Permission denied make: *** [install] Error 1
it seems that Makefile system ignored DESTDIR
DESTDIR is an environment variable for staged installs. and Gentoo does staged installs. it means it does not install directly into /usr/lib, but first does install tasks inside a sandbox, chrooted in $DESTDIR directory. if makefile tries to write directly to root / filesystem (thus, not respecting the DESTDIR directive) it raises that Access Violation error above
I'll fix as soon as I have time
thanks for reporting
the Makefiles in the pd CVS tree are very are definetly not good. they needs fixing globaly.
who is responsible for the CVS ?
i think that all of them have to be generalised ,so we can easiely build anything.
i do everything manually on my system, cause quite a few makefiles try to use -m32 in CFLAGS and many of them need -fPIC to be added.
there basic externals , which don't have any ./configure part, i think we need to work on those first , leaving Gem and DataFlow aside ..
also there is acouple of external which have duplicated objects.
i'm not totaly experienced with writing from the scratch makefiles, but i could help checking it out on amd64 (gentoo)..
and hopefully mac-ppc (obsd) soon as well.
On Tue, Nov 20, 2007 at 10:01:05AM +0100, mescalinum@gmail.com wrote:
so what you got there with /usr/lib/pd and doc/ in there ?? who does that belong to to whatever ..check it out and emerge --resume then ..
no way-.-
ah, seems you got FEATURES=userpriv - so you might diasable thet .. but seems actually this a bug in the ebuild , it shouldn't try making that directory at 'install' stage.
CVS ebuilds (ebuilds that pull sources from VC repositories) are a hell. I promised myself to make periodically snapshots, so I wouldn't had such issues.
at te time I wrote the ebuild it worked fine.
directories are made at the 'merge' stage
ACCESS DENIED mkdir: /usr/lib/pd/doc install: cannot create directory `/usr/lib/pd/doc': Permission denied make: *** [install] Error 1
it seems that Makefile system ignored DESTDIR
DESTDIR is an environment variable for staged installs. and Gentoo does staged installs. it means it does not install directly into /usr/lib, but first does install tasks inside a sandbox, chrooted in $DESTDIR directory. if makefile tries to write directly to root / filesystem (thus, not respecting the DESTDIR directive) it raises that Access Violation error above
I'll fix as soon as I have time
thanks for reporting
-- Federico Ferri
errordeveloper@gmail.com wrote:
the Makefiles in the pd CVS tree are very are definetly not good. they needs fixing globaly.
who is responsible for the CVS ?
nobody. the authors are responsible for their stuff. so: if zexy/src/Makefile is broken, it is my fault...
i think that all of them have to be generalised ,so we can easiely build anything.
i do everything manually on my system, cause quite a few makefiles try to use -m32 in CFLAGS and many of them need -fPIC to be added.
at least the pd-sources (+externs) have fixed this by now. i think the (erroneous) use of the "-m32" flag in pd-0.40 convinced several developers to add this flag to their makefiles.
there basic externals , which don't have any ./configure part, i think we need to work on those first , leaving Gem and DataFlow aside ..
GridFlow you mean?
also there is acouple of external which have duplicated objects.
what do you mean here? nameclashes? duplicated functionality? aliases?
fmga.sdr IOhannes
On Tue, Nov 20, 2007 at 01:56:19PM +0100, IOhannes m zmoelnig wrote:
errordeveloper@gmail.com wrote:
the Makefiles in the pd CVS tree are very are definetly not good. they needs fixing globaly. who is responsible for the CVS ?
nobody. the authors are responsible for their stuff. so: if zexy/src/Makefile is broken, it is my fault...
i think that all of them have to be generalised ,so we can easiely build anything. i do everything manually on my system, cause quite a few makefiles try to use -m32 in CFLAGS and many of them need -fPIC to be added.
at least the pd-sources (+externs) have fixed this by now. i think the (erroneous) use of the "-m32" flag in pd-0.40 convinced several developers to add this flag to their makefiles.
i kidda realise thatr as well .
there basic externals , which don't have any ./configure part, i think we need to work on those first , leaving Gem and DataFlow aside ..
GridFlow you mean?
ah , sure yeah :)
also there is acouple of external which have duplicated objects.
what do you mean here? nameclashes? duplicated functionality? aliases?
yeah ..i can't remenber, but when i used my strategy:
#'
foreach pde (find -iname '*.pd_linux')
ln -s $pde /opt/audio/lib/pd/ext/cvs-all/
end
#'
i found some file with the same names .., and they seemd to copy some stuff
from on external directory into anothr in order to resolvetheir little
dependency , i suppose ..
such things should be included in some guidelines may be, if we wish to have any guide lines as such .
fmga.sdr IOhannes
errordeveloper@gmail.com wrote:
also there is acouple of external which have duplicated objects.
what do you mean here? nameclashes? duplicated functionality? aliases?
yeah ..i can't remenber, but when i used my strategy: #' foreach pde (
find -iname '*.pd_linux') ln -s $pde /opt/audio/lib/pd/ext/cvs-all/ end #' i found some file with the same names .., and they seemd to copy some stuff from on external directory into anothr in order to resolvetheir little dependency , i suppose ..such things should be included in some guidelines may be, if we wish to have any guide lines as such .
there are several solutions to this (and have been discussed to death on this list before)
one of them is to use prefixes (see "libdir") another one is to avoid nameclashes in the 1st place (needs a lot of communication); a start for a centralized repository of object-names is the pdpedia project.
mfga.dsr IOhannes
the Makefiles in the pd CVS tree are very are definetly not good. they needs fixing globaly.
who is responsible for the CVS ?
i think that all of them have to be generalised ,so we can easiely build anything.
i do everything manually on my system, cause quite a few makefiles try to use -m32 in CFLAGS and many of them need -fPIC to be added.
there basic externals , which don't have any ./configure part, i think we need to work on those first , leaving Gem and DataFlow aside ..
also there is acouple of external which have duplicated objects.
i'm not totaly experienced with writing from the scratch makefiles, but i could help checking it out on amd64 (gentoo)..
and hopefully mac-ppc (obsd) soon as well.
heh, it would be a definitely GOOD THING to tidy up our build systems.
but HOW?
one solution could be modularizing and hierarchicalizing Makefiles.... perhaps pd-extended build system uses this approach (Hans, can you spend some words here?).
another approach could be auto*-tools, but I don't know anything about that. if anyone has experience with that and he thinks it is reasonable to use autoconf/automake.... it would be appreciated if he can write some lines on the wiki, describing a standardized build procedure for externals based on autotools
writing Makefiles it means much more than making a bunch of C files to compile.
the end user just use the compile part, but other environments (see the Gentoo build system) use more advanced Makefiles features.
I just mention some:
- CC, STRIP, LD, ... variables can override the default programs
- DESTDIR is used as filesystem root for staged installs
- test target is used to perform tests
- CFLAGS, CXXFLAGS *must* be honored instead of hardcoding CFLAGS
(like -march, -mcpu, -funroll-loops, -fomit-frame-pointer, -fpipe, ...) into Makefiles
I wrote very few externs (notemono, tracker) and I should admit even my makefiles are broken and don't respect all of the above features
writing a Makefile by hand is a PITA and much error-prone :|
just my 0.02 Euro
Federico Ferri
On Tue, Nov 20, 2007 at 04:59:18PM +0100, mescalinum@gmail.com wrote:
heh, it would be a definitely GOOD THING to tidy up our build systems.
but HOW?
i think of having one Makeglobal which will contain DESTDIR, CFALGS , *FLAGS ..etc all the general variebles.. and procedures (or how do you call it in make terminology ?) - ah targets may be .. i mean the way you wanna do make install and make clean .. etc i'd suggect make syminst (which will link .pd and .pd_linux) files into the path instead of copying it - save a litle space (practicaly) AND make update of the abstraction very simple! so there we set like all the abstractions to go into $libdir/abs or something that you perefere .. and the externals can go into $libdir/ext - stick to 3char convention is a good idea i think (once the situation permits)! so i'm just giving some organizational idea ..(i organize my installation in that manner actually).
so having this Makeglobal (or ..Makefile.glob if you wish), athors just add their Makelocal's which will only contain the compilation procedure definition.
one solution could be modularizing and hierarchicalizing Makefiles.... perhaps pd-extended build system uses this approach (Hans, can you spend some words here?).
another approach could be auto*-tools, but I don't know anything about that. if anyone has experience with that and he thinks it is reasonable to use autoconf/automake.... it would be appreciated if he can write some lines on the wiki, describing a standardized build procedure for externals based on autotools
i think we don't really need autoconf or any of those -
having the above structure one can just go into the external's dir and do make install or make syminst
we don't need --with-blah and --enable-foo for simple externals , i reckon
apart from massive things like GridFlow and GEM ..(which have already got it ;)
writing Makefiles it means much more than making a bunch of C files to compile.
the end user just use the compile part, but other environments (see the Gentoo build system) use more advanced Makefiles features.
I just mention some:
- CC, STRIP, LD, ... variables can override the default programs
- DESTDIR is used as filesystem root for staged installs
- test target is used to perform tests
- CFLAGS, CXXFLAGS *must* be honored instead of hardcoding CFLAGS
(like -march, -mcpu, -funroll-loops, -fomit-frame-pointer, -fpipe, ...) into Makefiles
I wrote very few externs (notemono, tracker) and I should admit even my makefiles are broken and don't respect all of the above features
writing a Makefile by hand is a PITA and much error-prone :|
i don't think it's a big deal to have some basic makefile structure like that ..
ok, well if we got any auto-tools specialist , who has a good solution now around here ..
just my 0.02 Euro
Federico Ferri
The Pd-extended Makefiles do use DESTDIR, CFLAGS, etc. but are only
somewhat hierarchical. That stuff could be greatly improved for
sure. Patches welcome :D
I think that it autoconf/config.h should be the technique for
handling libs and other dependencies. Perhaps automake would be
useful in the long run, Bryan Jurish outlined how to use it with Pd
on this list a little while ago.
.hc
On Nov 20, 2007, at 11:34 AM, errordeveloper@gmail.com wrote:
On Tue, Nov 20, 2007 at 04:59:18PM +0100, mescalinum@gmail.com wrote:
heh, it would be a definitely GOOD THING to tidy up our build
systems.but HOW?
i think of having one Makeglobal which will contain DESTDIR, CFALGS , *FLAGS ..etc all the general variebles.. and procedures (or how do you call it in make terminology ?) - ah targets may be .. i mean the way you wanna do make install and make clean .. etc i'd suggect make syminst (which will link .pd and .pd_linux) files
into the path instead of copying it - save a litle space (practicaly) AND make update of the abstraction very simple! so there we set like all the abstractions to go into $libdir/abs or something that you perefere .. and the externals can go into $libdir/ext - stick to 3char
convention is a good idea i think (once the situation permits)! so i'm just giving some organizational idea ..(i organize my installation in that manner actually).so having this Makeglobal (or ..Makefile.glob if you wish), athors just add their Makelocal's which will only contain the compilation procedure definition.
one solution could be modularizing and hierarchicalizing
Makefiles.... perhaps pd-extended build system uses this approach (Hans, can you spend some words here?).another approach could be auto*-tools, but I don't know anything
about that. if anyone has experience with that and he thinks it is reasonable to use autoconf/automake.... it would be appreciated if he can write
some lines on the wiki, describing a standardized build procedure for externals based on autotoolsi think we don't really need autoconf or any of those -
having the above structure one can just go into the external's dir and do make install or make syminst
we don't need --with-blah and --enable-foo for simple externals , i
reckonapart from massive things like GridFlow and GEM ..(which have
already got it ;)writing Makefiles it means much more than making a bunch of C
files to compile.the end user just use the compile part, but other environments (see the Gentoo build system) use more advanced Makefiles features.
I just mention some:
- CC, STRIP, LD, ... variables can override the default programs
- DESTDIR is used as filesystem root for staged installs
- test target is used to perform tests
- CFLAGS, CXXFLAGS *must* be honored instead of hardcoding CFLAGS
(like -march, -mcpu, -funroll-loops, -fomit-frame-pointer, -fpipe, ...) into Makefiles
I wrote very few externs (notemono, tracker) and I should admit even my makefiles are broken and don't respect all of the above features
writing a Makefile by hand is a PITA and much error-prone :|
i don't think it's a big deal to have some basic makefile structure
like that ..ok, well if we got any auto-tools specialist , who has a good solution now around here ..
just my 0.02 Euro
Federico Ferri
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
¡El pueblo unido jamás será vencido!
-
alejo d -
errordeveloper＠gmail.com -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
mescalinum＠gmail.com