On 7 Mar 2006, at 21:24, Hans-Christoph Steiner wrote:
You need to download portaudio V19 and get the missing files from there. Miller forgot to check them in, and he's been too busy to get to it.
Hmm it's not going all that well. V19 is available in CVS or snapshot only. I downloaded pa_snapshot_v19.tar.gz and after copying file by file for a bit, just substituted the 'portaudio' entirely. That worked well (e.g. compilation proceeded), and I saw compilation scroll for the darwin_app package.
However, it stops here:
/usr/bin/ld: multiple definitions of symbol _RingBuffer_AdvanceReadIndex s_audio_paring.o definition of _RingBuffer_AdvanceReadIndex in section (__TEXT,__text)
So. Linking problems? Is LD just playing with me?
I can't find anything that would've gotten mixed up, but I'll start from a fresh cvs checkout if I need to.
Hans?
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
On 8 Mar 2006, at 11:24, David Plans Casal wrote:
/usr/bin/ld: multiple definitions of symbol _RingBuffer_AdvanceReadIndex s_audio_paring.o definition of _RingBuffer_AdvanceReadIndex in section (__TEXT,__text)
So. Linking problems? Is LD just playing with me?
I can't find anything that would've gotten mixed up, but I'll start from a fresh cvs checkout if I need to.
I have just done a fresh, complete checkout using checkout-developer- layout.sh
Then added the portaudio v19 missing sources in the pd/src dir, and the TclTkAquaStandalone-8.4.9.dmg in packages/darwin_app
However, I'm getting exactly the same error as above, again.
Anyone else getting this? I don't have the portaudio fink package installed anymore, so can't see what ld is complaining about...
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
On Mar 8, 2006, at 6:24 AM, David Plans Casal wrote:
On 7 Mar 2006, at 21:24, Hans-Christoph Steiner wrote:
You need to download portaudio V19 and get the missing files from there. Miller forgot to check them in, and he's been too busy to get to it.
Hmm it's not going all that well. V19 is available in CVS or snapshot only. I downloaded pa_snapshot_v19.tar.gz and after copying file by file for a bit, just substituted the 'portaudio' entirely. That worked well (e.g. compilation proceeded), and I saw compilation scroll for the darwin_app package.
However, it stops here:
/usr/bin/ld: multiple definitions of symbol _RingBuffer_AdvanceReadIndex s_audio_paring.o definition of _RingBuffer_AdvanceReadIndex in section (__TEXT,__text)
So. Linking problems? Is LD just playing with me?
I can't find anything that would've gotten mixed up, but I'll start from a fresh cvs checkout if I need to.
Hans?
I haven't seen this error, maybe that's caused by a newer version of portaudio V19? Maybe its related to the fix that Thomas recently announced, where Pd has the same function names as portaudio in some places.
This is not specific to Pd-extended but anyone trying to build Pd from Miller's sources.
.hc
________________________________________________________________________ ____
There is no way to peace, peace is the way. -A.J. Muste
On Thu, 2006-03-09 at 22:55 -0500, Hans-Christoph Steiner wrote:
/usr/bin/ld: multiple definitions of symbol _RingBuffer_AdvanceReadIndex s_audio_paring.o definition of _RingBuffer_AdvanceReadIndex in section (__TEXT,__text)
So. Linking problems? Is LD just playing with me?
I can't find anything that would've gotten mixed up, but I'll
start
from a fresh cvs checkout if I need to.
Hans?
I haven't seen this error, maybe that's caused by a newer version of portaudio V19? Maybe its related to the fix that Thomas recently announced, where Pd has the same function names as portaudio in some places.
this issue is caused, because miller's sources use function names, that are already used by portaudio ... lovely nameclash ... iirc it's a problem since 0.37...
tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
I had nothing to offer anybody except my own confusion Jack Kerouac
On 10 Mar 2006, at 08:40, Tim Blechmann wrote:
On Thu, 2006-03-09 at 22:55 -0500, Hans-Christoph Steiner wrote:
I haven't seen this error, maybe that's caused by a newer version of portaudio V19? Maybe its related to the fix that Thomas recently announced, where Pd has the same function names as portaudio in some places.
this issue is caused, because miller's sources use function names, that are already used by portaudio ... lovely nameclash ... iirc it's a problem since 0.37...
How do you get around it?
Hans, could we not include portaudio in the new 'imports' section you propose, and include a patch that changes those functions' names? I can help with that (I think) if the idea makes sense.
But for now, I guess I just need to be able to compile ;-) , since I'm trying to build standalone pd apps using pd-extended...
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
On 10 Mar 2006, at 03:55, Hans-Christoph Steiner wrote:
/usr/bin/ld: multiple definitions of symbol _RingBuffer_AdvanceReadIndex s_audio_paring.o definition of _RingBuffer_AdvanceReadIndex in section (__TEXT,__text)
So. Linking problems? Is LD just playing with me?
I haven't seen this error, maybe that's caused by a newer version of portaudio V19? Maybe its related to the fix that Thomas recently announced, where Pd has the same function names as portaudio in some places.
This is not specific to Pd-extended but anyone trying to build Pd from Miller's sources.
It is indeed not specific to Pd-extended at all. It's just that Pd- extended tries to build Miller's sources and that process comes up with this error.
How do I circumvent it? Build without portaudio?
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
On Fri, 10 Mar 2006, David Plans Casal wrote:
How do I circumvent it? Build without portaudio?
I checked in the missing files, seems that Miller has removed them by mistake. It should work now, if not, let me know. Be sure you undo all your changes, or start from new. If you use anonymous access you have to wait a day or so.
I am normaly not doing changes on Millers source, but I figured that adding these missing files can not do too much harm. At least it works now on linux, somone should check if it is ok on macs too.
Guenter
On 10 Mar 2006, at 11:12, geiger wrote:
On Fri, 10 Mar 2006, David Plans Casal wrote:
How do I circumvent it? Build without portaudio?
I checked in the missing files, seems that Miller has removed them by mistake. It should work now, if not, let me know.
Hi Guenter!
Ok have checkout the portaudio directory again now, and compilation gets a lot further.
At least it works now on linux, somone should check if it is ok on macs too.
Compilation now works on darwin too. Well, at least the .app package gets built.
However, externals compilation stops with:
/Users/dc/dev/pure-data/packages/darwin_app/../../externals/build/ src/../../iem/iemmatrix/src/mtx_pow.c:120: warning: unused parameter ‘s’ make[2]: *** [/Users/dc/dev/pure-data/packages/darwin_app/../../ externals/build/src/mtx_.^.o] Error 1 make[1]: *** [externals_install] Error 2 make: *** [extended_install] Error 2 waldorf:~/dev/pure-data/packages/darwin_app dc$
Anyone?
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
On 10 Mar 2006, at 11:55, David Plans Casal wrote:
However, externals compilation stops with:
/Users/dc/dev/pure-data/packages/darwin_app/../../externals/build/ src/../../iem/iemmatrix/src/mtx_pow.c:120: warning: unused parameter ‘s’ make[2]: *** [/Users/dc/dev/pure-data/packages/darwin_app/../../ externals/build/src/mtx_.^.o] Error 1 make[1]: *** [externals_install] Error 2 make: *** [extended_install] Error 2 waldorf:~/dev/pure-data/packages/darwin_app dc$
Actually, I believe the error (as opposed to warning) comes from a little above that, at:
/Users/dc/dev/pure-data/packages/darwin_app/../../externals/build/ src/../../iem/iemmatrix/src/mtx_pow.c: At top level: /Users/dc/dev/pure-data/packages/darwin_app/../../externals/build/ src/../../iem/iemmatrix/src/mtx_pow.c:22: error: static declaration of ‘powf’ follows non-static declaration
So I guess that's from the recent IEM checkin? Don't know what to do about this...
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
David Plans Casal wrote:
On 10 Mar 2006, at 11:55, David Plans Casal wrote:
However, externals compilation stops with:
/Users/dc/dev/pure-data/packages/darwin_app/../../externals/build/ src/../../iem/iemmatrix/src/mtx_pow.c:120: warning: unused parameter ‘s’ make[2]: *** [/Users/dc/dev/pure-data/packages/darwin_app/../../ externals/build/src/mtx_.^.o] Error 1 make[1]: *** [externals_install] Error 2 make: *** [extended_install] Error 2 waldorf:~/dev/pure-data/packages/darwin_app dc$
Actually, I believe the error (as opposed to warning) comes from a little above that, at:
/Users/dc/dev/pure-data/packages/darwin_app/../../externals/build/ src/../../iem/iemmatrix/src/mtx_pow.c: At top level: /Users/dc/dev/pure-data/packages/darwin_app/../../externals/build/ src/../../iem/iemmatrix/src/mtx_pow.c:22: error: static declaration of ‘powf’ follows non-static declaration
So I guess that's from the recent IEM checkin? Don't know what to do about this...
now, the proble comes from the way apple declares (or not) math.h... since powf() used to be non-existant on older releases of os-X, a lot of workarounds have been introduced.
anyhow, if your deployment thing does not work, try: entirely removing the block of lines19-25 (that's the __APPLE__ ifdef) in mtx_pow.c OR (if this doesn't work), replace this block with #define powf pow
and report back :-)
mfg.adr. IOhannes
On 10 Mar 2006, at 12:10, IOhannes m zmoelnig wrote:
anyhow, if your deployment thing does not work, try: entirely removing the block of lines19-25 (that's the __APPLE__ ifdef) in mtx_pow.c OR (if this doesn't work), replace this block with #define powf pow
and report back :-)
Private Darwin reporting ;-)
Ok removing the __APPLE__ ifdef completely gets me past iemlib compilation...I assume this means it isn't needed anymore...so this should probably be commited?
However, I now see compilation stop further down the externals process, at:
/Users/dc/dev/pure-data/packages/darwin_app/../../externals/loaders/ import.c: In function ‘import_load_lib’: /Users/dc/dev/pure-data/packages/darwin_app/../../externals/loaders/ import.c:27: error: too few arguments to function ‘sys_load_lib’ /Users/dc/dev/pure-data/packages/darwin_app/../../externals/loaders/ import.c:28: warning: implicit declaration of function ‘sys_load_lib_dir’ /Users/dc/dev/pure-data/packages/darwin_app/../../externals/loaders/ import.c: In function ‘import_new’: /Users/dc/dev/pure-data/packages/darwin_app/../../externals/loaders/ import.c:80: warning: unused parameter ‘s’ make[2]: *** [/Users/dc/dev/pure-data/packages/darwin_app/../../ externals/loaders/import.o] Error 1 make[1]: *** [externals_install] Error 2 make: *** [extended_install] Error 2
Anyone? No idea what that loader does, even.
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
On 10 Mar 2006, at 12:38, David Plans Casal wrote:
and report back :-)
Private Darwin reporting ;-)
/Users/dc/dev/pure-data/packages/darwin_app/../../externals/loaders/ import.c:27: error: too few arguments to function ‘sys_load_lib’
<snip> Anyone? No idea what that loader does, even.
Is it just me, or does this mean packages/darwin_app compilation is broken?
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
David Plans Casal wrote:
On 10 Mar 2006, at 12:38, David Plans Casal wrote:
and report back :-)
Private Darwin reporting ;-)
/Users/dc/dev/pure-data/packages/darwin_app/../../externals/loaders/ import.c:27: error: too few arguments to function ‘sys_load_lib’
<snip> Anyone? No idea what that loader does, even.
Is it just me, or does this mean packages/darwin_app compilation is broken?
The Pd-extended stuff usually relies on patches to the Pd core. These patches are then submitted to Miller, which he mostly has been accepting. The patches which you need to apply vary based on which version you are trying to compile.
Right now, if you go to "packages/" and run "make patch_pd", it will apply the patches needed for 0.39.2. If you are using the latest version in CVS, then a lot of these patches are already included, and then you'll have to include a couple patches by hand.
For example, import.c relies on packages/patches/libdir-0.38-4.patch, which should apply cleanly to both 0.39.2 and the latest in CVS.
Also, as a rule of thumb when trying to build the whole Pd-extended package, just remove the offending file and it will then continue building from there. So in this case, if you "rm externals/loaders/import.c", it will continue building.
Also, I find it easier to build "externals" first to find these problems, then when you can get a clean build from "externals", then try packages/darwin_app. So just "cd externals && make" then when that works, "cd ../packages/darwin_app && make install".
.hc
On 13 Mar 2006, at 19:31, Hans-Christoph Steiner wrote:
The Pd-extended stuff usually relies on patches to the Pd core. These patches are then submitted to Miller, which he mostly has been accepting. The patches which you need to apply vary based on which version you are trying to compile.
Right now, if you go to "packages/" and run "make patch_pd", it will apply the patches needed for 0.39.2. If you are using the latest version in CVS, then a lot of these patches are already included, and then you'll have to include a couple patches by hand.
cvs update -d -P is my friend ;-)
could you point at the patches I should have to apply by hand?
For example, import.c relies on packages/patches/ libdir-0.38-4.patch, which should apply cleanly to both 0.39.2 and the latest in CVS.
ok oh I see. Well I just removed import.c, as you point out below.
Also, as a rule of thumb when trying to build the whole Pd-extended package, just remove the offending file and it will then continue building from there. So in this case, if you "rm externals/loaders/ import.c", it will continue building Also, I find it easier to build "externals" first to find these problems, then when you can get a clean build from "externals", then try packages/darwin_app. So just "cd externals && make" then when that works, "cd ../packages/darwin_app && make install".
thanks, that's very helpful actually!
but, could you point out what you do about 'broken' externals compilation, such as this (which happens on latest checkout):
/usr/bin/ld: warning -L: directory name (/Users/dc/dev/pure-data/ externals/../externals/hcs/hid/HID Utilities Source/build) does not exist /usr/bin/ld: can't locate file for: -lHIDUtilities collect2: ld returned 1 exit status make: *** [/Users/dc/dev/pure-data/externals/../externals/hcs/hid/ hid.pd_darwin] Error 1
When it tries to compile hid?
I can see it's makefile tests for existing of the build directory and libHIDUtilities.a in there here:
hid_utilities: test -f ./HID\ Utilities\ Source/build/libHIDUtilities.a || \ ( cd ./HID\ Utilities\ Source && pbxbuild )
I mean so far, I've had to remove markex, speex (wanted lame, I didn't want to bother), and now I should have to remove hid, but it seems like a pity, because I'm going to need hid soon, so I'll just end up there again.
Do you usually remove whatever won' t compile?
d
-- David Casal Researcher, Department of Computing Goldsmiths College, University of London Office : +44 020 7078 5151 Mob : +44 07803 173959
On Tue, 14 Mar 2006, David Plans Casal wrote:
Do you usually remove whatever won' t compile?
Normally it should be sufficient to call "make -k", that how it was done in the old build system. This way you do not have to remove sources, and still have a reminder that there is something that has to be fixed.
I don't know if this still works with the new build system, though. Would be a nicer solution IMO.
Guenter
d
-- David Casal Researcher, Department of Computing Goldsmiths College, University of London Office : +44 020 7078 5151 Mob : +44 07803 173959
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Mar 14, 2006, at 11:21 AM, geiger wrote:
On Tue, 14 Mar 2006, David Plans Casal wrote:
Do you usually remove whatever won' t compile?
Normally it should be sufficient to call "make -k", that how it was done in the old build system. This way you do not have to remove sources, and still have a reminder that there is something that has to be fixed.
I don't know if this still works with the new build system, though. Would be a nicer solution IMO.
That still works, but can lead to trouble down the line if you miss other errors. There is so much building going on with the whole package, that errors are easily missed when compiling with make -k, and then you might wonder why certain things are missing...
.hc
Guenter
d
-- David Casal Researcher, Department of Computing Goldsmiths College, University of London Office : +44 020 7078 5151 Mob : +44 07803 173959
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
On Mar 14, 2006, at 10:18 AM, David Plans Casal wrote:
On 13 Mar 2006, at 19:31, Hans-Christoph Steiner wrote:
The Pd-extended stuff usually relies on patches to the Pd core. These patches are then submitted to Miller, which he mostly has been accepting. The patches which you need to apply vary based on which version you are trying to compile.
Right now, if you go to "packages/" and run "make patch_pd", it will apply the patches needed for 0.39.2. If you are using the latest version in CVS, then a lot of these patches are already included, and then you'll have to include a couple patches by hand.
cvs update -d -P is my friend ;-)
could you point at the patches I should have to apply by hand?
That varies as Miller accepts them. But right now, I think it would be these:
alsa_adddev_proto_with_alsa_only-0.40-pre.patch bang_method_for_clip-0.40.pre.patch complete_version_defines-0.39.2.patch libdir-0.38-4.patch put_version_into_aboutpd_page-0.40-pre.patch remove_dotdot_from_guidir-0.39.2.patch special_character_support.patch windows_env_vars-0.40-pre.patch
For example, import.c relies on packages/patches/ libdir-0.38-4.patch, which should apply cleanly to both 0.39.2 and the latest in CVS.
ok oh I see. Well I just removed import.c, as you point out below.
Also, as a rule of thumb when trying to build the whole Pd- extended package, just remove the offending file and it will then continue building from there. So in this case, if you "rm externals/loaders/import.c", it will continue building Also, I find it easier to build "externals" first to find these problems, then when you can get a clean build from "externals", then try packages/darwin_app. So just "cd externals && make" then when that works, "cd ../packages/darwin_app && make install".
thanks, that's very helpful actually!
but, could you point out what you do about 'broken' externals compilation, such as this (which happens on latest checkout):
/usr/bin/ld: warning -L: directory name (/Users/dc/dev/pure-data/ externals/../externals/hcs/hid/HID Utilities Source/build) does not exist /usr/bin/ld: can't locate file for: -lHIDUtilities collect2: ld returned 1 exit status make: *** [/Users/dc/dev/pure-data/externals/../externals/hcs/hid/ hid.pd_darwin] Error 1
When it tries to compile hid?
I can see it's makefile tests for existing of the build directory and libHIDUtilities.a in there here:
hid_utilities: test -f ./HID\ Utilities\ Source/build/libHIDUtilities.a || \ ( cd ./HID\ Utilities\ Source && pbxbuild )
On Mac OS X, [hid] requires libHIDUtilities.a, so it needs to be compiled with "make hid_utilities" or "cd ./HID\ Utilities\ Source && pbxbuild" if its not working...
The [hid] build stuff is annoyingly complicated because of the dependencies and needs work.
I mean so far, I've had to remove markex, speex (wanted lame, I didn't want to bother), and now I should have to remove hid, but it seems like a pity, because I'm going to need hid soon, so I'll just end up there again.
Do you usually remove whatever won' t compile?
The best option is to try to fix it, but that means digging into it. Trying to compile against the latest CVS version will be a lot more digging. Right now, Pd-extended is targetted at 0.39.2, so that will be much easier.
.hc
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
On Mar 10, 2006, at 7:10 AM, IOhannes m zmoelnig wrote:
now, the proble comes from the way apple declares (or not) math.h... since powf() used to be non-existant on older releases of os-X, a lot of workarounds have been introduced.
anyhow, if your deployment thing does not work, try: entirely removing the block of lines19-25 (that's the __APPLE__ ifdef) in mtx_pow.c OR (if this doesn't work), replace this block with #define powf pow
and report back :-)
...which means we should change the __APPLE__ to something that tests for the specific versions of OSX that required the hack in the first place....something like:
#ifdef __APPLE__ # include <AvailabilityMacros.h> # if defined (MAC_OS_X_VERSION_10_3) && MAC_OS_X_VERSION_MAX_ALLOWED
= MAC_OS_X_VERSION_10_3
# else //float intrinsics not in math.h, so we define them here #define sqrtf(v) (float)sqrt((double)(v)) ...etc... #endif
...now, I guess it's time to go back and figure where to commit this ;-)
jamie
Hans,
In the current darwin_app Makefile, I see:
export MACOSX_DEPLOYMENT_TARGET = 10.3
Should this be 10.4? May I change and commit if that's the case?
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
No, it should be 10.3, otherwise the builds will probably only work on 10.4. Right now, you won't gain anything (that I know of) by changing that from 10.3 to 10.4, but we need at least 10.3 for a couple of things.
.hc
David Plans Casal wrote:
Hans,
In the current darwin_app Makefile, I see:
export MACOSX_DEPLOYMENT_TARGET = 10.3
Should this be 10.4? May I change and commit if that's the case?
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On 13 Mar 2006, at 19:33, Hans-Christoph Steiner wrote:
No, it should be 10.3, otherwise the builds will probably only work on 10.4. Right now, you won't gain anything (that I know of) by changing that from 10.3 to 10.4, but we need at least 10.3 for a couple of things.
Oh ok so that's -minimum- version, of course.
Thanks,
David
-- David Casal Researcher, Department of Computing Goldsmiths College, University of London Office : +44 020 7078 5151 Mob : +44 07803 173959
-
David Plans Casal -
geiger -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
james tittle -
Tim Blechmann