I also found that location a little odd...

I think there is a typo in the Scons script now:

TypeError: not all arguments converted during string formatting: File "SConstruct", line 29: pdwatchdog, pdsend, pdreceive, pdgui, pd, pdlib = SConscript('./src/SConscript') File "/usr/lib/scons/SCons/Script/SConscript.py", line 581: return apply(method, args, kw) File "/usr/lib/scons/SCons/Script/SConscript.py", line 508: return apply(_SConscript, [self.fs,] + files, {'exports' : exports}) File "/usr/lib/scons/SCons/Script/SConscript.py", line 239: exec _file_ in stack[-1].globals File "src/SConscript", line 144: if conf.CheckHeader('tcl8.4/tk.h' % i):

Sorry Tim!

b>

Tim Blechmann wrote:

...

Thanks for adding the sarge path /usr/include/tcl8.4 so scons can find the header files.

now it finds tcl.h but not tk.h (it is in the same directory)

wow ... what a great place to put this :-/

the scons build system should find it now ...

t

Hi Tim,

Its still doing it after cvs update -dP, and then even after removing SConstruct and then cvs update -dP

Thanks again for making these sarge changes. :)

B.

Tim Blechmann wrote:

...

if conf.CheckHeader('tcl8.4/tk.h' % i):

sorry ... please try again :-)

t

Hi Tim,

Seems scons looks but cannot find the file:

Checking for C header file tcl8.4/tk.h... no

yet:

insitu:# ls /usr/include/tcl8.4/tk.h /usr/include/tcl8.4/tk.h

Ummm?

Maybe I should take a break and compile more externals.

you know what the rest says...

Bn>

src/t_main.c:18:16: tk.h: No such file or directory src/t_main.c:38: error: syntax error before '*' token src/t_main.c: In function `main': src/t_main.c:59: error: `Tcl_AppInit' undeclared (first use in this function) src/t_main.c:59: error: (Each undeclared identifier is reported only once src/t_main.c:59: error: for each function it appears in.) src/t_main.c: At top level: src/t_main.c:86: error: syntax error before "Tcl_Interp" src/t_main.c:86: warning: data definition has no type or storage class src/t_main.c:87: error: syntax error before '{' token src/t_main.c:99: warning: parameter names (without types) in function declaration src/t_main.c:99: error: conflicting types for `pdgui_startup' src/t_main.c:38: error: previous declaration of `pdgui_startup' src/t_main.c:99: warning: data definition has no type or storage class src/t_main.c:112: error: syntax error before "return" scons: *** [src/t_main.o] Error 1 scons: building terminated because of errors.

yet

Tim Blechmann wrote:

...

Its still doing it after cvs update -dP, and then even after removing SConstruct and then cvs update -dP

argh ... seems i committed it to my local svn instead to the cvs ... should be in there, now ...

t

just for the record, i get the same problem, unless i say ./configure --prefix=/usr/lib/

which is kinda annoying. thanks

On 7/9/05, Tim Blechmann TimBlechmann@gmx.net wrote:

...

Checking for C header file tcl8.4/tk.h... no

now this is really weird ...

...

src/t_main.c:18:16: tk.h: No such file or directory

well, this is even stranger ... if tcl.h has been found in /usr/include/tcl8.4, this path should be in your include paths ... so tk.h should be found by the preprocessor ... if it's not, something is really going wrong on your machine ... can you actually open the tk.h file?

t

-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk

latest mp3: kMW.mp3 http://mattin.org/mp3.html

latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/

After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

Hi Tim,

Well I did a little digging. for some reason (I'm not sure what I changed) the autoconf build for devel 0_38 works now. Using this PD compiles fine, but will not load any of my externals. (Do externals have to be compiled against devel to work in devel, meaning I need a mirror of all externals compiled for devel?

On to scons.

scons tries to compile t_main.c with:

gcc -O3 -fprefetch-loop-arrays -mfpmath=sse -mmmx -msse -msse2 -DDL_OPEN -DNEWHASH -DLOCKFREE -DUNISTD -DUNIX -DUSEAPI_OSS -DINSTALL_PREFIX="/usr/lib" -DUSEAPI_ALSA -DUSEAPI_JACK -DUSEAPI_PORTAUDIO -DPA19 -Isrc -Iportaudio/pa_common -Iportaudio/pablio -c -o src/t_main.o src/t_main.c

the old build system tries to compile t_main.c with:

cc -O3 -funroll-loops -fomit-frame-pointer -DPD -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -O3 -funroll-loops -fomit-frame-pointer -DDONTUSESIMD -DDONTUSESIMD -DPA_USE_OSS -DPA_LITTLE_ENDIAN -DUNIX -DUNISTD -DUNIX -DUNISTDo -DUSEAPI_OSS -I../portaudio/pa_common -I../portaudio/pablio -I../portaudio/portmidi-macosx -fno-strict-aliasing -DPA_USE_ALSA -DUSEAPI_ALSA -DINSTALL_PREFIX="/usr/local" -I. -I/usr/include/tcl8.4 -c -o ../obj/t_main.o t_main.c

t_main.c says #include "tk.h" but only the old build system specifically says: -I/usr/include/tcl8.4

I think this is the reason everything but the scons build is working for me. I still can't explain why scons does not see tk.h in include/tcl8.4/ though it seems Miller's ./configure script doesn't even try to look for it, only searching for tcl.h and then main() in -ltk:

checking tcl.h usability... yes checking tcl.h presence... yes checking for tcl.h... yes checking for main in -ltcl8.7... no checking for main in -ltcl8.6... no checking for main in -ltcl8.5... no checking for main in -ltcl8.4... yes checking for main in -ltk8.7... no checking for main in -ltk8.6... no checking for main in -ltk8.5... no checking for main in -ltk8.4... yes

I hope this sheds some light on whats going on....

Thanks again Tim for all your patience.

Tim Blechmann wrote:

...

just for the record, i get the same problem, unless i say ./configure --prefix=/usr/lib/

not sure, if it's the same problem ... ben is using scons, you're using configure (which i basically stopped maintaining)

anyway, if you set the prefix to /usr/lib, where is your tk.h located (/usr/lib/include seems to be a really strange place)

cheers ... tim

including the ones that come with pd (fiddle~,...) which were definitely compiled with the devel-version.

there is no reason, why externals shouldn't load ... there's no reason in the code ... just try to get rid of the old pd binary ... and make sure, you run the new one ... (installing it is the most secure way)

anyhow, what normally helped was a complete check out of the pd-directory /cvsroot/pure-data/pd and not just /cvsroot/pure-data/pd/src. make sure you are calling the bootstrap-script and each other step (configure, make) from .../pd and NOT from .../pd/src

well, i didn't really want to abandon miller's build system ... maybe that was a bad idea ...

but i don't want to write on in order to not start a flame war again. probably i am just thinking of volunteering to do the autoconf support for pd-devel.

what a wonderful idea :-) ... although the scons system is nearly finished and it would be a waste of resources to maintain two build systems ... during this time, it would be possible to enter tool tips for all pd internals ;-)

tim

Any solutions if I want to run both? I'm currently using the debian package of PD (38-4) thanks to Guenter, so installing the devel version will mess up my packages, unless I uninstall the pd package and recompile from source, and then use both from their non-search-path binaries?

it should be possible to use the the debian package in /usr/ and install devel to /usr/local ... you just have to take care that you run the binaries from the absolute path ...

I'm about to throw out a bunch of compiling work to use more PD packages, so its unlikely I'm going to blow away miller's PD (packaged) for devel.

well, iirc the debian package doesn't include pd's private headers (i.e. m_imp.h and g_canvas.h) ... you will be able to compile most externals, but no externals requiring these header files (e.g. cyclone, toxy, flext)

Since this is clearly not intensional anything I could contribute to to help debugging the fact that devel is not loading externals? I did checkout the whole pd/ module, not just pd/src for one. I've not even yet looked at -verbose output...

well, i'd be curious about the -verbose output ... anyway, just make sure, not to mix the build systems and to clean all old pd binaries and object files ...

I've been doing everything from pd/ and not pd/src so I'll try a third time to compile, but I have a feeling devel will still not load externals, even if only because I have Miller's installed in /usr/bin/pd .

well, i doubt that is the reason ...

t

Anyhow devel still does not load any externals, does look in the right place but cannot find any of the *_setup functions. Nothing else

well, this is exactly the problem that thomas grill described as "one of the meanest bugs in pd history"

see: http://lists.puredata.info/pipermail/pd-list/2005-03/026278.html and the related thread ...

tim

Tim Blechmann wrote:

...

Anyhow devel still does not load any externals, does look in the right place but cannot find any of the *_setup functions. Nothing else stands out in the -verbose output. I've been doing "./bootstrap.sh && autoconf && ./configure && make clean && make" each time...

well, rethinking what i said and rereading thomas's mail ... maybe you can't run both stable and devel on a machine, that has one of the

well stable is in my PATH (/usr/local/bin) and i can run instances of pd-devil and pd-angel simultaneously at the same time. both are able to load externals compiled against some stable version (not entirely sure which, but i guess it was as recent as 0.38-4)

putting devel in the path didn't work out of the box (not finding the correct pd-gui), so i haven't tested this combination.

binaries in the search path ... since the externals link back to the pd binary ... possibly to the wrong one ...

wow, real magic!

#>ldd zexy.pd_linux libm.so.6 => /lib/tls/libm.so.6 (0xb7fa8000) libc.so.6 => /lib/tls/libc.so.6 (0xb7e73000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

so what do you mean exactly by "linking back to (the wrong) pd" ?

just a guess, though ... tim

ok, the external-loading problem has been the same for me, now that i tried to get into it again.

what i finally did was: #> cd .../pd #> mv src src.bak #> cvs up -d #> bootstrap %note: i changed the hardcoded versions of aclocal and automake to match the ones i installed onmy machine (to be precise, i changed them to "aclocal" instead of "aclocal-1.9" (and similar for automake); see below) #> ./convigure #> make #> ./bin/pd

and i really tried to remove each leftover from older configures/builds.

i have automake1.7 installed on my system.

my advice for now is to do a complete fresh checkout of pd.

mfg.asd.r IOhannes

Tim Blechmann wrote:

...

...

pd binary ... possibly to the wrong one ...

sorry, can't answer with a zexy example, since the symbols are stripped ... but i'd suggest to run "nm zexy.pd_linux | grep U" to see the undefined symbols ... most of them are exported from the pd binary: U atom_string U binbuf_add U binbuf_addbinbuf U binbuf_addsemi U binbuf_addv U binbuf_clear

these symbols are resolved at runtime ... if you'd like to use zexy in an application not providing these symbols, you'll get some undefined symbol messages ... if these symbols are resolved in the wrong way, anything can happen ;-)

yes of course. but the external does not go and load another library to resolve these symbols but the parent application (whichever pd) has to provide them. so imo the 2 pd's cannot interfere in that way. if an application provides "atom_string" (either because it defines them itself or it imports a dynamic library that provides them _prior_ to opening the external) then zexy can use them no matter what other binaries are installed on the machine. if an application does not provide those symbols, then loading an external that depends on them will miserably fail, but you'll get an error about undefined symbols (and which ones) i have experienced this a lot :-)

the only thing that does not work without magic, is that an external depends on external symbols but does not explicitely define where to look for them (via linking against those dynamically!) and those symbols are not defined by pd (or a library that has been loaded _beforehand_). it will definitely not start to search random libraries (like pd-stable) installed on your harddisk.

mfg.ad.sr IOhannes

Anyhow devel still does not load any externals, does look in the right place but cannot find any of the *_setup functions. Nothing else stands out in the -verbose output. I've been doing "./bootstrap.sh && autoconf && ./configure && make clean && make" each time...

ok ... since the scons build system is working on debian now (ugly hack, though), i'd ask you to try it again... and please make sure to check out the latest devel_0_39 to a new folder to make sure, you have no old object files lying around ... i changed the location of the binaries back to ./bin ... to avoid confusion ... i don't have any problems on this machine to load externals, although both the debian package and devel are installed, so i think, it _is_ a user bug (sorry) or a build problem (flamewar) ...

<flamewar>i also enabled the scons compile cache to improve build speed if you compile devel regularly</flamewar>

cheers .... tim

agree..3 times ive been unable to load externals and each time it was due to incorrect user settings or build problems: specifying an audio interface that wasnt compiled in (build issue) building pd with a different compiler than the externals (build issue) and pd getting confused by the commented items in .pdrc (branch desynch issue)

well, i think, this time, it another issue ... still, afaict a user bug :-/

t

IMO, building should consist of 2-3 steps: ./configure && make and optionally "make install"

well, this depends if you see the ./configure file as a binary or a source file ...

since it is a generated file containing between 5000 to 10000 lines, i'd consider it as a binary, that shouldn't be placed in a cvs repository (but that should be generated for source-tarballs)

although i thought, it' pretty easy to generate the autoconf file, i wrote the bootstrap stript ...

anyway, it might be a waste of resources, to have python installed to build pd, the advantage of scons is the dependency tracking that is advanced compared to the autotools ... if you compile a lot, you will start to like the features ...

cheers, tim, who feels like being in the middle of a flamewar ;-)

Well I did a little digging. for some reason (I'm not sure what I changed) the autoconf build for devel 0_38 works now. Using this PD compiles fine, but will not load any of my externals. (Do externals have to be compiled against devel to work in devel, meaning I need a mirror of all externals compiled for devel?

no ... externals compiled against stable will work with devel ... externals compiled against devel might work with stable (they won't if they implement günter's tool tips, the idle callbacks or simd functions ... afaik the only externals doing that are mine and flext-based)

i head rumors that externals won't load, if stable and devel are both running on the same machine ... in that case a make / scons install should do it ...

I think this is the reason everything but the scons build is working for me. I still can't explain why scons does not see tk.h in include/tcl8.4/ though it seems Miller's ./configure script doesn't even try to look for it, only searching for tcl.h and then main() in -ltk:

well, this might be a workaround ...

Thanks again Tim for all your patience.

thanks for _your_ patience ...

tim