[Cc'd to pd-dev in case other people can teach us the proper way to strip(1).]
Hans-Christoph Steiner said this at Mon, 10 Feb 2003 10:36:22 -0500:
These tips were very helpful. I am on my way to porting my first external: ext13. autoconf is quite straight forward. After I clear it with Dieter, I'll commit my porting changes.
I have a related question, is this needed?: strip --strip-unneeded ext13.pd_darwin strip: unrecognized option: --strip-unneeded
And if so, what's the MacOS X equivalent? My first hacked together ext13.pd_darwin lib works though.
Hallo Hans-Christoph,
I'm glad those suggestions were a help.
I have no idea about "strip". I haven't used it, and I'm 95% sure it's not a necessary step. Looking at the Mac man page alone doesn't make it any clearer. However, from the Linux man page:
--strip-unneeded Strip all symbols that are not needed for relocation processing.
and now from the start of strip(1) in darwin-land:
strip no longer removes relocation entries under any con- dition. Instead, it updates the external relocation entries (and indirect symbol table entries) to reflect the resulting symbol table.
...so it sounds like strip, as used here in Pd-land, is not terribly useful, but further on in strip(1)-darwin:
When strip is used with no options on an executable file, it checks that file to see if it uses the dynamic link editor. If it does, the effect of the strip command is the same as using the -u and -r options.
... so that sounds to me like you might like to _experiment_ with strip using no options, and see if the default behaviour yields something that's still usable. :)
Otherwise, if others know better about using strip, especially on Mac OS X, please chime in.
Cheers, adam
On Tuesday, Jan 28, 2003, at 08:16 America/New_York, Adam Lindsay wrote:
Michael McGonagle said this at Mon, 27 Jan 2003 13:04:19 -0600:
I have been working with some externals for PD over the past few days, and having noticed that most makefiles do not have targets for Mac OS X (Darwin), it made me wonder if there is a "Universal" makefile that contains the needed code as a starting point for all externals.
Hi Michael.
When compiling for MacOSX, I started out using the makefile for expr~ as my model. There are a few refinements that have evolved. A linux makefile will typically get you 95% of the way there. The final 5% is best done by example, as I just learned this stuff empirically:
LINUXCFLAGS = -DPD -DUNIX -O6 -funroll-loops -fomit-frame-pointer \ -Wall -W -Wshadow -Wstrict-prototypes -Werror \ -Wno-unused -Wno-parentheses -Wno-switch
would translate to:
MACOSXCFLAGS = -DPD -DUNIX -DMACOSX -O3 \ -Wall -W -Wstrict-prototypes \ -Wno-unused -Wno-parentheses -Wno-switch
and...
LINUXLDFLAGS = -export_dynamic -shared
MACOSXLDFLAGS = -bundle -bundle_loader /path/to/pd/bin/pd -flat_namespace
(often you will find "-undefined suppress" in the place of "- bundle_loader", but explicitly telling the linker about Pd's symbols is better.)
Hope that's some help.
I'd love to make this a non-issue for most externals, and offer them pre- compiled, but it's hard to figure out how to package them so that a user's installation is trivial.
cheers, adam
--
Adam T. Lindsay atl@comp.lancs.ac.uk Computing Dept, Lancaster University +44(0)1524/594.537 Lancaster, LA1 4YR, UK Fax:+44(0)1524/593.608 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Otherwise, if others know better about using strip, especially on Mac OS X, please chime in.
well, i suppose that a lot of functions are added to the object file from the library in the linking process. strip removes all the symbols that refer to functions (and the functions) that are never called. so i suppose it is just reduces the size of the object. the i suppose that if you compile an external without the strip step, your file will work, but it will be much larger...
Tim mailto:TimBlechmann@gmx.net ICQ: 96771783 http://www.nyds-exp-discogs.tk -- The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww!" Jack Kerouac
On Monday, Feb 10, 2003, at 12:04 America/New_York, Adam Lindsay wrote:
MACOSXLDFLAGS = -bundle -bundle_loader /path/to/pd/bin/pd -flat_namespace
(often you will find "-undefined suppress" in the place of "- bundle_loader", but explicitly telling the linker about Pd's symbols is better.)
One other question which will hopefully benefit other budding Darwin porters like me: if I use the -bundle_loader /path/to/pd/bin/pd flag instead of -undefined suppress, will it tie that executable to pd being install in that path? So if I install that binary into a PD install that's in /local/path/to/pd/bin/pd, will that binary still work?
Here is the man page section on this, I read it, but I want to make sure I understand:
When creating bundles (MH_BUNDLE outputs) with the static link editor when two-level namespace is in effect (now the default) and the bundle has references to symbols expected to be defined in the pro- gram loading the bundle, then the -bundle_loader executable must be used.
...
-bundle_loader executable This specifies the executable that will be loading the bundle output file being linked. Unde- fined symbols from the bundle are checked against the specified executable like it was one of the dynamic libraries the bundle was linked with. If the bundle being created with -twolevel_namespace in effect then the searching of the executable for symbols is based on the placement of the -bundle_loader flag relative to the dynamic libraries. If the the bundle being created with -flat_namespace then the searching of the executable is done before all dynamic libraries.
.hc
Hans-Christoph Steiner said this at Mon, 10 Feb 2003 23:49:54 -0500:
On Monday, Feb 10, 2003, at 12:04 America/New_York, Adam Lindsay wrote:
MACOSXLDFLAGS = -bundle -bundle_loader /path/to/pd/bin/pd -flat_namespace
(often you will find "-undefined suppress" in the place of "- bundle_loader", but explicitly telling the linker about Pd's symbols is better.)
One other question which will hopefully benefit other budding Darwin porters like me: if I use the -bundle_loader /path/to/pd/bin/pd flag instead of -undefined suppress, will it tie that executable to pd being install in that path? So if I install that binary into a PD install that's in /local/path/to/pd/bin/pd, will that binary still work?
I've been able to use externals made in that way with any Pd.
What I (think I) understand is happening is that -bundle_loader just tells the linker to look at the Pd executable first for missing symbols, before throwing up an error as an undefined symbol. This way it doesn't actually *ignore* undefined symbols, which could make for difficult debugging.
adam
Here is the man page section on this, I read it, but I want to make sure I understand:
When creating bundles (MH_BUNDLE outputs) with the static linkeditor when two-level namespace is in effect (now the default) and the bundle has references to symbols expected to be defined in the pro- gram loading the bundle, then the -bundle_loader executable must be used.
...
-bundle_loader executable This specifies the executable that will be loading thebundle output file being linked. Unde- fined symbols from the bundle are checked against the specified executable like it was one of the dynamic libraries the bundle was linked with. If the bundle being created with -twolevel_namespace in effect then the searching of the executable for symbols is based on the placement of the -bundle_loader flag relative to the dynamic libraries. If the the bundle being created with -flat_namespace then the searching of the executable is done before all dynamic libraries.
.hc
-
Adam Lindsay -
Hans-Christoph Steiner -
Tim Blechmann