hiya,
...well, poked around on it tonight and fixed the earlier error...I'll make a proper diff, but there are a coupla things to note:
1. according to the following link, since it's a dynamic library, it should be suffixed as such (important at compile time, not so much so at runtime): http://developer.apple.com/qa/qa2001/qa1101.html
2. everyone says not to use libtool directly!
...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? ;-)
...I'm assuming this will also work on earlier os x's (and earlier versions of gcc), but won't be able to try until tommorrow...
l8r, jamie
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? ;-)
...I'm assuming this will also work on earlier os x's (and earlier versions of gcc), but won't be able to try until tommorrow...
...ok, now I've tried it on 10.3.9, and it seems to require something else, because ld produces the error "has local relocation entries in non-writable section"...a quick search thru "man ld" later, and that something is: "-read_only_relocs suppress"
...so to sum up, the command is "gcc -dynamiclib -read_only_relocs suppress" plus the rest...I'll get this into devel_pd cvs today...
jamie
On May 11, 2005, at 12:25 AM, james tittle wrote:
hiya,
...well, poked around on it tonight and fixed the earlier error...I'll make a proper diff, but there are a coupla things to note:
- according to the following link, since it's a dynamic library, it
should be suffixed as such (important at compile time, not so much so at runtime): http://developer.apple.com/qa/qa2001/qa1101.html
- everyone says not to use libtool directly!
...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".
.hc
...I'm assuming this will also work on earlier os x's (and earlier versions of gcc), but won't be able to try until tommorrow...
l8r, jamie
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
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
On May 11, 2005, at 2:46 PM, james tittle wrote:
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...
Checkout packages/darwin_app/patches/darwin_build-0.38.patch. It patches makefile.in and configure.in and includes this change.
.hc
...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
________________________________________________________________________ ____
"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