yes! I've gotten just that error when recompiling an external with the wrong source/bin configuration. And I did use make install.
Thomas Grill wrote:
Hi all, that could turn out to be one of the meanest bugs in pd history. Vincent, Ian, Ben, did you also "make install" your built pd, or just run it from the bin folder? The thing is that with the preferred autoconf build method, the pd binary resides in the _src_ folder after compilation. So, most probably, you linked your externals (flext-based, but also others) against the new version (in src), but ran it with an old one in bin. This produces the described error for me, too.
best greetings, Thomas
vincent rioux schrieb:
currently you are the only one who both experiences and debugs this problem ...
the only idea i have at the moment the only idea i have is to make look for older versions of devel_0_38 and try to figure out the date when devel_0_38 started with this behaviour ... i know, this is a lot of work, but you would do the devel_ branch a big favor ... use cvs update -D date to check out a certain date (see man cvs for details) and start a binary search during the last few monthes ...
ouch! this sounds quite heavy i might give a try but do you think i should recompile flext and/or externals each time i make a cvs update?
otherwise, Thomas, i finally came back to flext 4.7, dyn and py from your website and everything worked like a charm with pd-038-4 (miller's site) it sounds like i don't manage to use the new system you came with to install flext and your externals on cvs if you wish you can send me your latest py version (tarred), compatible with the previous build system and i will for sure give it a try :-)
vincent
i'm really sorry, that i can't help you at the moment, but with your help, i'm pretty sure, we can find this bug ...
thanks ... tim