On May 11, 2005, at 2:34 PM, Hans-Christoph Steiner wrote:
On May 11, 2005, at 12:25 AM, james tittle wrote:
...so I just changed references to "pdtcl" in the makefile & pd.tk to "pdtcl.dylib", and then changed the following in the makefile:
#this is for Max OSX only... $(BIN_DIR)/pdtcl.dylib: $(GOBJ) $(GSRC) cd ../obj; gcc -dynamiclib -o $(BIN_DIR)/pdtcl.dylib $(GOBJ) \ /Library/Frameworks/Tk.framework/Versions/Current/Tk \ /Library/Frameworks/Tcl.framework/Versions/Current/Tcl \ /usr/lib/libSystem.B.dylib
...also note that it's much better to refer things like above than "../../whatever", because that is dependent on whatever dev setup order you have (and doesn't work for me and many others)...also, we had a laugh about the "Max OSX" typo: just can't shake yr teacher, eh? ;-)
The "../../Frameworks" path is necessary for building Pd using the TclTkStandalone Wish.app, unless you have found another way to build the Pd.app. If so, that would be awesome. Please enlighten us.
If not, its easy enough to have autoconf choose between "/Library/ Frameworks" and "../../Frameworks".
...please enlighten me, then, as to how autoconf would choose this...perhaps we need a flag for choosing to build the app or the cli? In any event, the frameworks are now there in 10.4, tho I like relative frameworks because that means we can upgrade tcl/tk more easily/transparently...
...also note that I've now been contacted by an apple engineer who says that the "-read_only_relocs suppress" should probably be "- read_only_relocs warning", because this is still something to fix...it may be that it's linking with non-PIC objects, but that'd only take a performance hit on each launch of whatever uses the pdtcl.dylib...
still searching, jamie