Pd-dev August 2009

pd-dev@lists.iem.at

23 participants
81 discussions

UTF-8 for pd-devel (again)
by Bryan Jurish 20 Jan '10

20 Jan '10

moin folks, I believe I've finally got pd-devel 0.41-4 using UTF-8 across the board. So far, I've tested message boxes & comments (g_rtext), as well as symbol atoms, and all seems good. I think we can still expect goofiness if someone names an abstraction using a multibyte character when the filesystem isn't UTF-8 encoded (raw 8-bit works for me here too), but I really don't want to open that particular can of worms. So I guess I have 2 questions: (1) what should I call the generic UTF-8 source files? (see my other post) (2) shall I commit these changes to pd-devel/0.41-4, or somewhere else, or just post a diff (ca. 33k, ought to be easier to read now; I've tried to follow the indentation conventions of the source files I modified)? marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jurish(a)ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology

5 13

[declare] bug (id 2251387)
by Roman Haefeli 26 Dec '09

26 Dec '09

hi everyone i once posted a bug to the tracker and it still appears to be there in version 0.42.3. since this bug is kind of viral, so that it corrupts patches invisibly and without being noticed by the author, and also since quite some of my own patches got affected by that bug, i would like to ask to raise the priority of this one. BEWARE: everyone, who was working on patches in 0.42.X, that contain abstractions containing [declare]'s is most likely affected, or i should rather say: infected. read the description here: http://sourceforge.net/tracker/index.php?func=detail&aid=2251387&group_id=5… roman ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

3 3

ATI + GridFlow + Gem + C++ + Linux = BOOM
by Mathieu Bouchard 15 Oct '09

15 Oct '09

Hi Hans, Could we please get Pd-extended to link the "pd" executable to libstdc++.so ? Afaik, this is a fix for a possibly wide category of problems but that is currently only "known" to affect GridFlow when loading GEM while the driver named "fglrx" is in use (ATI video). AFAIK, this problem affects any lib that uses the "throw" keyword in C++ code, whenever the ATI driver is loaded _before_ the standard library of C++, in which case it will provide its own version of a portion of the C++ standard library, which is incompatible (sort of like the DLL Hell on Windows). This driver is typically loaded by anything linked to OpenGL directly or indirectly (usually GEM, but could also be 3DP, OpenSceneGraph, etc) So, what I'm asking, is to link Pd itself to a library that it doesn't need, in order to force the bug out, so that this problem doesn't have to be addressed anywhere else. I believe that it is far easier to prevent this bug from the Pd executable than to make any kind of elaborate circus with the loading-order of pdsettings and pdrc and a little dummy .pd_linux (which has -lstdc++ without using it, and has an empty _setup). If you want, you can think of it as the first step for putting GridFlow in pd-extended. diff from Claude: ------------------8<--------cut-here--------8<------------------ --- pd-0.41-4/src/makefile.in.orig 2008-03-15 00:03:00.000000000 +0000 +++ pd-0.41-4/src/makefile.in 2009-08-23 18:55:35.000000000 +0100 -121,7 +121,7 @@ $(CC) $(CFLAGS) $(STRIPFLAG) -o $(BIN_DIR)/pdreceive u_pdreceive.c $(PDEXEC): $(OBJ) $(BIN_DIR) - cd ../obj; $(CC) $(LDFLAGS) $(DBG_CFLAGS) -o $(PDEXEC) $(OBJ) $(LIB) + cd ../obj; $(CC) $(LDFLAGS) $(DBG_CFLAGS) -o $(PDEXEC) $(OBJ) $(LIB) -lstdc++ $(BIN_DIR)/pd-gui: $(GOBJ) $(GSRC) cd ../obj; $(CC) $(INCLUDE) -o $(BIN_DIR)/$(GUINAME) $(GOBJ) $(GLIB) ------------------8<--------cut-here--------8<------------------ _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

4 12

[ pure-data-Patches-1654666 ] sending a cut message to an "invisible" subpatch makes crash
by SourceForge.net 10 Sep '09

10 Sep '09

Patches item #1654666, was opened at 2007-02-07 15:08 Message generated for change (Settings changed) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1654666&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None >Status: Pending >Resolution: Fixed Priority: 7 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Miller Puckette (millerpuckette) Summary: sending a cut message to an "invisible" subpatch makes crash Initial Comment: If you have a subpatch, and send a "cut" message to it when it is not in "visible" state (i.e. it is not open), pd crashes. This may happen when using scripting, if for example you send a "find foo" message followed by a "cut" message. If the object does not exist (and the subpatch hasn't been made explicitly visible), the cut message will reach the canvas when it is invisible. See the attached example. Tested on 0.40.2 on Windows XP. Matteo Sisti Sette matteo dot sistisette at email dot it ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2009-08-30 15:34 Message: fixed this slightly differently. (Hannes -- the vis/invis editor allocation and deallocation code is so complicated I'm afraid to try to enable "edits" on invis windows. Instead I want to write a "delete-in-rectangle" message optimized for scripting. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-01-28 10:09 Message: raised priority since this bothers me right now! miller: any chance to get selection/copy/paste/... to work with closed patches? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1654666&group_…

2 1

Re: [PD-dev] Malloc Error occuring with PD 0.41.4
by james murray 31 Aug '09

31 Aug '09

Well, It steadily creeps up in memory used until I have approx 140 mb of free memory on the computer. And although I noticed that it occasionally flashed all the way down to only 6 - 9 MB of free memory at some points for a flickering moment, when it finally crashed it was listing free memory at around 133 mb. It took almost two hours for this to occur. I should note that the Pd-extended 0.41.4 version that is running the camera input/record/pix_share_write runs steadily at 139 MB both during and after the crash. In fact nothing but the version of Pure Data running video playback crashes.... So, not really sure where things can go from here. I'm really frustrated that this is happening since PD has always been my go to performer. J On Fri, Aug 28, 2009 at 1:13 PM, Hans-Christoph Steiner <hans(a)at.or.at>wrote: > > Check it right before it crashes. If its not close to 3gb, then its not > the 32/64-bit issue that I mentioned. Since the error mentions std::bad_alloc, > which points to C++. I'm guessing it might be a Gem bug then. > > .hc > > On Aug 28, 2009, at 12:10 PM, james murray wrote: > > Hi, > > I'm generally around 1.34 GB real memory for PD-Extended running video > playback and 139.81 MB real memory for the camera input patch. (which of > course means that I have two versions of PD-Extended running, both are > 0.41.4 PD-Extended). I should note that I've got pix_share_read and write > objects moving video from one copy of PD to the other... running it into a > buffer on the playback patch. > > Virtual memory is 1.52 GB for one version of PD, while the other is at 1.19 > GB VM... I'm running one version of PD for the camera and one for the > playback. If other info is needed, I'm happy to supply it. > > Thanks > J > > On Fri, Aug 28, 2009 at 10:56 AM, Hans-Christoph Steiner <hans(a)at.or.at>wrote: > >> >> Did you run Activity Monitor to see how much memory 'pd' is using? >> >> .hc >> >> On Aug 28, 2009, at 10:48 AM, james murray wrote: >> >> I let PD-extended 0.41.4 run again the programming with a reduction from 4 >> GB of memory to 2 GM of memory... and it returned the same error on both >> machines... I'm still getting the malloc error.... I'm not really sure what >> options there are.... Does anyone have ideas about this being a 64 bit to >> 32 bit issue? Is there something else to try? I'm at wits end with PD >> constantly crashing and while competent in programming, malloc errors are >> definitely beyond my scope of expertise or knowledge. Any help would be >> huge. >> >> Again, I'm running PD Extended 0.41.4 on It happens every time without >> variation... I've tried it on two machines, one is: >> >> MacPro Quad-Core Intel Xeon, 2.93 GHz processor, 4 GB memory, ATI Radeon >> 4870 (the apple tweaked version, not the ATI version), BlackMagic Intensity >> Pro video card... and it's mac 10.5.8. >> >> The other computer is identical, but is running on 10.5.6. >> >> The error I get is: >> >> 8/25/09 1:38:48 PM [0x0-0x18018].org.puredata.pd.wish[271] >> pd(272,0xa03ce720) malloc: *** mmap(size=4149248) failed (error code=12) >> 8/25/09 1:38:48 PM [0x0-0x18018].org.puredata.pd.wish[271] *** >> error: can't allocate region >> 8/25/09 1:38:48 PM [0x0-0x18018].org.puredata.pd.wish[271] *** set a >> breakpoint in malloc_error_break to debug >> 8/25/09 1:38:48 PM [0x0-0x18018].org.puredata.pd.wish[271] terminate >> called after throwing an instance of 'std::bad_alloc' >> >> >> Thanks in advance >> J >> >> >> On Thu, Aug 27, 2009 at 5:46 PM, Hans-Christoph Steiner <hans(a)at.or.at>wrote: >> >>> >>> FYI, you'll want to keep this on the pd-dev list. There are others there >>> who know more about it than me. >>> >>> .hc >>> >>> On Aug 27, 2009, at 4:16 PM, james murray wrote: >>> >>> Hi, >>> >>> I switched out the RAM and replaced the 4 GB with two 1 GB modules. >>> Unfortunately the same crash happen with the same malloc error. So, not >>> sure what that means entirely, but, unfortunately it appears to still be an >>> issue. >>> >>> J >>> >>> On Thu, Aug 27, 2009 at 12:53 PM, james murray <james.n.murray(a)gmail.com >>> > wrote: >>> >>>> That makes sense... I'll give it a try and sort it out and see what >>>> happens... Thanks for the insight and clarity. >>>> >>>> J >>>> >>>> >>>> On Thu, Aug 27, 2009 at 12:45 PM, Hans-Christoph Steiner <hans(a)at.or.at >>>> > wrote: >>>> >>>>> >>>>> A 32-bit computer can only handle 3 gigs of RAM. That's the big deal >>>>> with 64-bit computers, they handle a lot more. While your computer is >>>>> 64-bit and your OS is 64-bit, the build of Pd you are running is 32-bit. >>>>> That means that your Pd cannot use more than 3 gigs of RAM no matter how >>>>> much is in the machine. >>>>> >>>>> My guess is that your Pd patch wants to use more than 3gb of RAM, then >>>>> crashes. Try running Activity Monitor and seeing how much memory 'pd' is >>>>> using. >>>>> >>>>> I could be wrong that this is the cuase of hte problem tho... >>>>> >>>>> .hc >>>>> >>>>> On Aug 27, 2009, at 1:41 PM, james murray wrote: >>>>> >>>>> >>>>> Okay... I'd run across this before when trying to research this >>>>> issue... Sorry to be so dull-witted about this, but does this mean a >>>>> physical reduction of my RAM itself from 4 GB to 3 GB? Or am I missing the >>>>> point and I need to do something else? >>>>> >>>>> >>>>> Thanks again for looking into this so quickly, I really appreciate it, >>>>> getting confirmation about all of this is really huge. >>>>> >>>>> J >>>>> >>>>> On Thu, Aug 27, 2009 at 12:27 PM, Hans-Christoph Steiner < >>>>> hans(a)at.or.at> wrote: >>>>> >>>>>> >>>>>> So it is not the GUI, but 'pd' itself having the issue: >>>>>> pd(272,0xa03ce720) My guess is that maybe its a 32-bi/64-bit issue. I >>>>>> think that a 32-bit app can only address 3 gigs of RAM. Pd is buildable has >>>>>> 64-bit, but there isn't a release for Mac OS X built as 64-bit yet. >>>>>> >>>>>> .hc >>>>>> >>>>>> >>>>>> On Aug 27, 2009, at 12:53 PM, james murray wrote: >>>>>> >>>>>> It happens every time without variation... I've tried it on two >>>>>> machines, one is: >>>>>> >>>>>> MacPro Quad-Core Intel Xeon, 2.93 GHz processor, 4 GB memory, ATI >>>>>> Radeon 4870 (the apple tweaked version, not the ATI version), BlackMagic >>>>>> Intensity Pro video card... and it's mac 10.5.8. >>>>>> >>>>>> The other computer is identical, but is running on 10.5.6. >>>>>> >>>>>> Thanks for getting back to me s quickly... I've been definitely >>>>>> hitting my head on this for a few days. >>>>>> >>>>>> J >>>>>> >>>>>> On Thu, Aug 27, 2009 at 11:42 AM, Hans-Christoph Steiner < >>>>>> hans(a)at.or.at> wrote: >>>>>> >>>>>>> >>>>>>> Hmm, never seen that one. Can you reproduce it, does it happen every >>>>>>> time? The "org.puredata.pd.wish" part makes me think that make its the >>>>>>> Tcl/Tk GUI side that's crashing. >>>>>>> >>>>>>> Which exact version of mac os x are you running? Which hardware? >>>>>>> >>>>>>> .hc >>>>>>> >>>>>>> On Aug 27, 2009, at 12:27 PM, james murray wrote: >>>>>>> >>>>>>> Hi List, >>>>>>> >>>>>>> I'm currently running into issues with getting PD Extended 0.41.4 to >>>>>>> run on Leopard 10.5. If I let the software run for an extended period of >>>>>>> time (say, 30 minutes to a couple of hours) PD/Gem crashes without an error >>>>>>> report. I'm running 1920 x 1080 video playback when this happens and I've >>>>>>> tested the programming with both two and three layers of video running. >>>>>>> >>>>>>> This is happening on a quad core Intel-Xeon Mac with 4 GB of memory >>>>>>> (although the same issue is happening if I cannibalize an additional 4 GB), >>>>>>> an ATI Radeon card and Blackmagic Intensity for capture. While I can't get >>>>>>> an error report from PD/Gem, Console is giving me the following: >>>>>>> >>>>>>> 8/25/09 1:38:48 PM [0x0-0x18018].org.puredata.pd.wish[271] >>>>>>> pd(272,0xa03ce720) malloc: *** mmap(size=4149248) failed (error code=12) >>>>>>> 8/25/09 1:38:48 PM [0x0-0x18018].org.puredata.pd.wish[271] *** >>>>>>> error: can't allocate region >>>>>>> 8/25/09 1:38:48 PM [0x0-0x18018].org.puredata.pd.wish[271] *** >>>>>>> set a breakpoint in malloc_error_break to debug >>>>>>> 8/25/09 1:38:48 PM [0x0-0x18018].org.puredata.pd.wish[271] >>>>>>> terminate called after throwing an instance of 'std::bad_alloc' >>>>>>> >>>>>>> This is definitely not an area that I'm overly familiar/confident >>>>>>> about and would really love to have at least some sort of idea of what could >>>>>>> be causing this to happen. This error is the only error I get with my >>>>>>> programming and it's frustrating since I can't downgrade to Leopard or run >>>>>>> it on another operating system. Any insight into this issue would be >>>>>>> greatly appreciated. I've altered my programming dramatically and stripped >>>>>>> it down to the bare bones and still, I have this error occuring. >>>>>>> >>>>>>> So, I suppose my question is this... is this a PD/Gem issue with >>>>>>> Leopard? Or something on my side that I'm just not seeing... Any insight >>>>>>> into this would be hugely appreciated.... >>>>>>> >>>>>>> Thank you, >>>>>>> J >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pd-dev mailing list >>>>>>> Pd-dev(a)iem.at >>>>>>> http://lists.puredata.info/listinfo/pd-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------------------- >>>>>>> >>>>>>> News is what people want to keep hidden and everything else is >>>>>>> publicity. - Bill Moyers >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------------- >>>>>> >>>>>> ¡El pueblo unido jamás será vencido! >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------------- >>>>> >>>>> I have the audacity to believe that peoples everywhere can have three >>>>> meals a day for their bodies, education and culture for their minds, and >>>>> dignity, equality and freedom for their spirits. - Martin Luther >>>>> King, Jr. >>>>> >>>>> >>>>> >>>> >>> >>> >>> >>> >>> ---------------------------------------------------------------------------- >>> >>> If nature has made any one thing less susceptible than all others of >>> exclusive property, it is the action of the thinking power called an idea, >>> which an individual may exclusively possess as long as he keeps it to >>> himself; but the moment it is divulged, it forces itself into the possession >>> of everyone, and the receiver cannot dispossess himself of it. - >>> Thomas Jefferson >>> >>> >>> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev(a)iem.at >> http://lists.puredata.info/listinfo/pd-dev >> >> >> >> >> >> ---------------------------------------------------------------------------- >> >> Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's >> about as sensible to say we declare war on night attacks and expect we're >> going to win that war. We're not going to win the war on terrorism. >> - retired U.S. Army general, William Odom >> >> >> > > > > > ---------------------------------------------------------------------------- > > Looking at things from a more basic level, you can come up with a more > direct solution... It may sound small in theory, but it in practice, it can > change entire economies. - Amy Smith > > >

3 2

[ pure-data-Bugs-2836261 ] "Find" Application Error - PD 0.42.5-extended-20090803 (XP)
by SourceForge.net 31 Aug '09

31 Aug '09

Bugs item #2836261, was opened at 2009-08-12 14:36 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2836261&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: v0.42 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Hans-Christoph Steiner (eighthave) Summary: "Find" Application Error - PD 0.42.5-extended-20090803 (XP) Initial Comment: using "find" from the menu or typing "ctrl+f" in PD 0.42.5-extended-20090803 (Windows XP) results in this error: Application Error Error: invalid command name "x" Details: invalid command name "x" invalid command name "x" while executing "x" (procedure "find_ok" line 1) invoked from within "find_ok .find1" invoked from within ".find1.button invoke" ("uplevel" body line 1) invoked from within "uplevel #0 [list $w invoke]" (procedure "tk::ButtonUp" line 24) invoked from within "tk::ButtonUp .find1.button" (command bound to event) ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-08-29 02:21 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2009-08-14 15:34 Message: doh, it was a stupid typo. Fixed with this commit: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=119… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2836261&group_…

1 0

new GUI rewrite branch
by Hans-Christoph Steiner 31 Aug '09

31 Aug '09

Just in any I didn't get the word out, the GUI rewrite stuff is now merged with Miller's 0.43 beginnings in trunk and in a new branch: https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rew… So this branch should be considered frozen in the past: https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-devel/0… .hc ---------------------------------------------------------------------------- I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler

2 1

[ pure-data-Patches-1515177 ] pd crashes on loading bogus patcher file
by SourceForge.net 31 Aug '09

31 Aug '09

Patches item #1515177, was opened at 2006-06-30 07:59 Message generated for change (Settings changed) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1515177&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Thomas Grill (xovo) Assigned to: Miller Puckette (millerpuckette) Summary: pd crashes on loading bogus patcher file Initial Comment: this is a small patch avoiding a crash on loading something like <<<<<<< .mine #N canvas 735 22 869 1052 10; #X obj 92 438 s pd; ... ... etc. this only cures the symptoms - there should probably be a more refined way of checking patcher file integrity.... ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2009-08-30 15:37 Message: I think this is OK now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1515177&group_…

1 0

[ pure-data-Patches-1654666 ] sending a cut message to an "invisible" subpatch makes crash
by SourceForge.net 31 Aug '09

31 Aug '09

Patches item #1654666, was opened at 2007-02-07 15:08 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1654666&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Miller Puckette (millerpuckette) Summary: sending a cut message to an "invisible" subpatch makes crash Initial Comment: If you have a subpatch, and send a "cut" message to it when it is not in "visible" state (i.e. it is not open), pd crashes. This may happen when using scripting, if for example you send a "find foo" message followed by a "cut" message. If the object does not exist (and the subpatch hasn't been made explicitly visible), the cut message will reach the canvas when it is invisible. See the attached example. Tested on 0.40.2 on Windows XP. Matteo Sisti Sette matteo dot sistisette at email dot it ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2009-08-30 15:34 Message: fixed this slightly differently. (Hannes -- the vis/invis editor allocation and deallocation code is so complicated I'm afraid to try to enable "edits" on invis windows. Instead I want to write a "delete-in-rectangle" message optimized for scripting. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-01-28 10:09 Message: raised priority since this bothers me right now! miller: any chance to get selection/copy/paste/... to work with closed patches? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1654666&group_…

1 0

[ pure-data-Patches-1621153 ] set env var MACOSX_DEPLOYMENT_TARGET = 10.3
by SourceForge.net 31 Aug '09

31 Aug '09

Patches item #1621153, was opened at 2006-12-22 23:16 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1621153&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: set env var MACOSX_DEPLOYMENT_TARGET = 10.3 Initial Comment: On Mac OS X, this needs to be defined to enable dlopen and weak linking support. Its safe on other platforms since gcc only checks this env var on Apple's gcc. <hans(a)at.or.at> export MACOSX_DEPLOYMENT_TARGET = 10.3 ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2009-08-30 15:22 Message: happy to take your word for it :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1621153&group_…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev August 2009