I am guessing that you mean x86 Mac OS X when you say iMac. If so,
then actually, all of Apple's new computers will be x86 based, not
just the iMac. I personally don't see any benefit to having
different file extensions for different platforms. .so and .a are
cross-platform and cross-architecture, for example. .dll and .dylib
are OS-specific, but not architecture specific.
I think something like .pdclass for all platforms would work best.
Or maybe just use platform-native for each platform, like Thomas
suggested:
http://lists.puredata.info/pipermail/pd-dev/2006-01/005720.html
.hc
On May 27, 2006, at 6:53 PM, Miller Puckette wrote:
I've got an experimental version of Pd compiled for imac available on http://crca.ucsd.edu/~msp/software.html ... unfortunately, since it seemed advisable to update portaudio to the new, completely
rewritten one, it would be unwise to retrofit this to Pd 0.39 (might change latencies or other things for pre-existing platforms).I made up a new file extension for externs (pd_imac) ... we could
always go to a "sensible" naming convention in the future and stay back
compatible, if people think it's too ad hoc. In the long term, the set of
architectures/ OSes seems set to stay at around hald a dozen active ones, so
there's no big problem just making up names unsystematically.The only other policy implication is this: I'm using files from the supplied "Wish shell.app" on Imac, which seems a reasonable thing to do, but strictly speaking it's probably more correct to download a bsd-licensed wish shell or recompile it from source. That shouldn't be too difficult to do, I hope.
cheers Miller
PD-announce mailing list PD-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
"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
Yep... I thought 'imac' meant 'intel-mac' but I guess it doesn't.
Anyway, I think that if someone wants to publish an extern that works on either mips or i86 macs, they would have to include both "dylib"s... unless there's a way to make a fat dylib with binaries for both architectures. Even so, it's easier to figure out what's what if the name reflects the architecture so you know what targets the extern is compiled for. So perhaps on intel macs, it should just be "pd_macintel" (more mellifluous than "pd_intelmac"?)
cheers Miller
On Sun, May 28, 2006 at 12:05:12AM +0200, Hans-Christoph Steiner wrote:
I am guessing that you mean x86 Mac OS X when you say iMac. If so,
then actually, all of Apple's new computers will be x86 based, not
just the iMac. I personally don't see any benefit to having
different file extensions for different platforms. .so and .a are
cross-platform and cross-architecture, for example. .dll and .dylib
are OS-specific, but not architecture specific.I think something like .pdclass for all platforms would work best.
Or maybe just use platform-native for each platform, like Thomas
suggested:http://lists.puredata.info/pipermail/pd-dev/2006-01/005720.html
.hc
On May 27, 2006, at 6:53 PM, Miller Puckette wrote:
I've got an experimental version of Pd compiled for imac available on http://crca.ucsd.edu/~msp/software.html ... unfortunately, since it seemed advisable to update portaudio to the new, completely
rewritten one, it would be unwise to retrofit this to Pd 0.39 (might change latencies or other things for pre-existing platforms).I made up a new file extension for externs (pd_imac) ... we could
always go to a "sensible" naming convention in the future and stay back
compatible, if people think it's too ad hoc. In the long term, the set of
architectures/ OSes seems set to stay at around hald a dozen active ones, so
there's no big problem just making up names unsystematically.The only other policy implication is this: I'm using files from the supplied "Wish shell.app" on Imac, which seems a reasonable thing to do, but strictly speaking it's probably more correct to download a bsd-licensed wish shell or recompile it from source. That shouldn't be too difficult to do, I hope.
cheers Miller
PD-announce mailing list PD-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
"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-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On May 28, 2006, at 12:22 AM, Miller Puckette wrote:
Yep... I thought 'imac' meant 'intel-mac' but I guess it doesn't.
Anyway, I think that if someone wants to publish an extern that works on either mips or i86 macs, they would have to include both
"dylib"s... unless there's a way to make a fat dylib with binaries for both
architectures.
Apple provides two mechanisms for this, one is fat binaries, which
have been supported since NeXTSTEP 3.2 (Mac OS X 10.4 == NeXTSTEP
6.4), and the other is Rosetta, which runs PPC code in emulation.
NeXTSTEP/Apple uses gcc for everything, so building fat binaries is
just a matter of figuring out the gcc options.
Even so, it's easier to figure out what's what if the name reflects
the architecture so you know what targets the extern is compiled for. So perhaps on intel macs, it should just be "pd_macintel" (more
mellifluous than "pd_intelmac"?)
The .pd_linux extension has been working fine for 10+ architectures,
I don't see why Mac OS X needs more than one. If people want to
distribute binaries for the different architectures, I think it will
be easier to just put the files in properly labeled directories (ie.
x86/object.pd_darwin ppc/object.pd_darwin).
Having more file extensions will mean I will have to modify the Pd-
extended build system quite a bit to make it work for that new
extension. This will take a lot of time, and probably introduce some
bugs, and I can't see any benefit.
.hc
cheers Miller
On Sun, May 28, 2006 at 12:05:12AM +0200, Hans-Christoph Steiner
wrote:I am guessing that you mean x86 Mac OS X when you say iMac. If so, then actually, all of Apple's new computers will be x86 based, not just the iMac. I personally don't see any benefit to having different file extensions for different platforms. .so and .a are cross-platform and cross-architecture, for example. .dll and .dylib are OS-specific, but not architecture specific.
I think something like .pdclass for all platforms would work best. Or maybe just use platform-native for each platform, like Thomas suggested:
http://lists.puredata.info/pipermail/pd-dev/2006-01/005720.html
.hc
On May 27, 2006, at 6:53 PM, Miller Puckette wrote:
I've got an experimental version of Pd compiled for imac
available on http://crca.ucsd.edu/~msp/software.html ... unfortunately, since it seemed advisable to update portaudio to the new, completely rewritten one, it would be unwise to retrofit this to Pd 0.39 (might change
latencies or other things for pre-existing platforms).I made up a new file extension for externs (pd_imac) ... we could always go to a "sensible" naming convention in the future and stay back compatible, if people think it's too ad hoc. In the long term, the set of architectures/ OSes seems set to stay at around hald a dozen active ones, so there's no big problem just making up names unsystematically.
The only other policy implication is this: I'm using files from the supplied "Wish shell.app" on Imac, which seems a reasonable thing to do, but strictly speaking it's probably more correct to download a bsd-licensed wish shell or recompile it from source. That shouldn't be too difficult to do, I hope.
cheers Miller
PD-announce mailing list PD-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
"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-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"The arc of history bends towards justice."
- Dr. Martin Luther King,
Jr.
OK, sounds like I have to figure out how to make fat binaries... (I don't think the subdirectory idea is all that great because I'd have to change Pd to look in them and then new externs wouldn't work in old versions of Pd.)
On the other hand, if I can figure out fat binaries I can get away without releasing separate "apps" for the two architectures. So this would be a Good Thing.
cheers Miller
On Sun, May 28, 2006 at 12:34:57AM +0200, Hans-Christoph Steiner wrote:
On May 28, 2006, at 12:22 AM, Miller Puckette wrote:
Yep... I thought 'imac' meant 'intel-mac' but I guess it doesn't.
Anyway, I think that if someone wants to publish an extern that works on either mips or i86 macs, they would have to include both
"dylib"s... unless there's a way to make a fat dylib with binaries for both
architectures.Apple provides two mechanisms for this, one is fat binaries, which
have been supported since NeXTSTEP 3.2 (Mac OS X 10.4 == NeXTSTEP
6.4), and the other is Rosetta, which runs PPC code in emulation.
NeXTSTEP/Apple uses gcc for everything, so building fat binaries is
just a matter of figuring out the gcc options.Even so, it's easier to figure out what's what if the name reflects
the architecture so you know what targets the extern is compiled for. So perhaps on intel macs, it should just be "pd_macintel" (more
mellifluous than "pd_intelmac"?)The .pd_linux extension has been working fine for 10+ architectures,
I don't see why Mac OS X needs more than one. If people want to
distribute binaries for the different architectures, I think it will
be easier to just put the files in properly labeled directories (ie.
x86/object.pd_darwin ppc/object.pd_darwin).Having more file extensions will mean I will have to modify the Pd- extended build system quite a bit to make it work for that new
extension. This will take a lot of time, and probably introduce some
bugs, and I can't see any benefit..hc
cheers Miller
On Sun, May 28, 2006 at 12:05:12AM +0200, Hans-Christoph Steiner
wrote:I am guessing that you mean x86 Mac OS X when you say iMac. If so, then actually, all of Apple's new computers will be x86 based, not just the iMac. I personally don't see any benefit to having different file extensions for different platforms. .so and .a are cross-platform and cross-architecture, for example. .dll and .dylib are OS-specific, but not architecture specific.
I think something like .pdclass for all platforms would work best. Or maybe just use platform-native for each platform, like Thomas suggested:
http://lists.puredata.info/pipermail/pd-dev/2006-01/005720.html
.hc
On May 27, 2006, at 6:53 PM, Miller Puckette wrote:
I've got an experimental version of Pd compiled for imac
available on http://crca.ucsd.edu/~msp/software.html ... unfortunately, since it seemed advisable to update portaudio to the new, completely rewritten one, it would be unwise to retrofit this to Pd 0.39 (might change
latencies or other things for pre-existing platforms).I made up a new file extension for externs (pd_imac) ... we could always go to a "sensible" naming convention in the future and stay back compatible, if people think it's too ad hoc. In the long term, the set of architectures/ OSes seems set to stay at around hald a dozen active ones, so there's no big problem just making up names unsystematically.
The only other policy implication is this: I'm using files from the supplied "Wish shell.app" on Imac, which seems a reasonable thing to do, but strictly speaking it's probably more correct to download a bsd-licensed wish shell or recompile it from source. That shouldn't be too difficult to do, I hope.
cheers Miller
PD-announce mailing list PD-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
"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-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"The arc of history bends towards justice." - Dr. Martin Luther King,Jr.
On 5/27/06, Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
OK, sounds like I have to figure out how to make fat binaries... (I don't think the subdirectory idea is all that great because I'd have to change Pd to look in them and then new externs wouldn't work in old versions of Pd.)
On the other hand, if I can figure out fat binaries I can get away without releasing separate "apps" for the two architectures. So this would be a Good Thing.
man lipo
Bascially make a PPC executable and a x86 one and join them.
As I already stated that doesn't help the externals issue at all. I think the solution to that is to clearly mark what works for what platform and have some patience for both the developers and end users. 'Why doesn't <external>.pd_darwin work on my Mac?' will probably be a common question.
On May 28, 2006, at 12:54 AM, Miller Puckette wrote:
OK, sounds like I have to figure out how to make fat binaries... (I don't think the subdirectory idea is all that great because I'd have to change Pd to look in them and then new externs wouldn't work in
old versions of Pd.)
I mean just for distributing them. People would just copy them in
the current directory layout. That's how I've distributed
multiple .pd_linux files in the past.
On the other hand, if I can figure out fat binaries I can get away
without releasing separate "apps" for the two architectures. So this would be a Good Thing.
This is a much better solution than making .pd_imac or whatever. To
reiterate, .pd_linux has worked fine on that platform with many
archs, I see no reason why Mac OS X needs two file extensions.
.hc
cheers Miller
On Sun, May 28, 2006 at 12:34:57AM +0200, Hans-Christoph Steiner
wrote:On May 28, 2006, at 12:22 AM, Miller Puckette wrote:
Yep... I thought 'imac' meant 'intel-mac' but I guess it doesn't.
Anyway, I think that if someone wants to publish an extern that
works on either mips or i86 macs, they would have to include both "dylib"s... unless there's a way to make a fat dylib with binaries for both architectures.Apple provides two mechanisms for this, one is fat binaries, which have been supported since NeXTSTEP 3.2 (Mac OS X 10.4 == NeXTSTEP 6.4), and the other is Rosetta, which runs PPC code in emulation. NeXTSTEP/Apple uses gcc for everything, so building fat binaries is just a matter of figuring out the gcc options.
Even so, it's easier to figure out what's what if the name reflects the architecture so you know what targets the extern is compiled for. So perhaps on intel macs, it should just be "pd_macintel" (more mellifluous than "pd_intelmac"?)
The .pd_linux extension has been working fine for 10+ architectures, I don't see why Mac OS X needs more than one. If people want to distribute binaries for the different architectures, I think it will be easier to just put the files in properly labeled directories (ie. x86/object.pd_darwin ppc/object.pd_darwin).
Having more file extensions will mean I will have to modify the Pd- extended build system quite a bit to make it work for that new extension. This will take a lot of time, and probably introduce some bugs, and I can't see any benefit.
.hc
cheers Miller
On Sun, May 28, 2006 at 12:05:12AM +0200, Hans-Christoph Steiner wrote:
I am guessing that you mean x86 Mac OS X when you say iMac. If so, then actually, all of Apple's new computers will be x86 based, not just the iMac. I personally don't see any benefit to having different file extensions for different platforms. .so and .a are cross-platform and cross-architecture, for example. .dll
and .dylib are OS-specific, but not architecture specific.I think something like .pdclass for all platforms would work best. Or maybe just use platform-native for each platform, like Thomas suggested:
http://lists.puredata.info/pipermail/pd-dev/2006-01/005720.html
.hc
On May 27, 2006, at 6:53 PM, Miller Puckette wrote:
I've got an experimental version of Pd compiled for imac available on http://crca.ucsd.edu/~msp/software.html ... unfortunately,
since it seemed advisable to update portaudio to the new, completely rewritten one, it would be unwise to retrofit this to Pd 0.39 (might change latencies or other things for pre-existing platforms).I made up a new file extension for externs (pd_imac) ... we could always go to a "sensible" naming convention in the future and stay back compatible, if people think it's too ad hoc. In the long term, the set of architectures/ OSes seems set to stay at around hald a dozen active ones, so there's no big problem just making up names unsystematically.
The only other policy implication is this: I'm using files from
the supplied "Wish shell.app" on Imac, which seems a reasonable
thing to do, but strictly speaking it's probably more correct to download a bsd-licensed wish shell or recompile it from source. That
shouldn't be too difficult to do, I hope.cheers Miller
PD-announce mailing list PD-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
__ ___ ____
"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-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"The arc of history bends towards justice." - Dr. Martin Luther King,Jr.
¡El pueblo unido jamás será vencido!
On 5/27/06, Hans-Christoph Steiner hans@eds.org wrote:
On May 28, 2006, at 12:22 AM, Miller Puckette wrote:
Yep... I thought 'imac' meant 'intel-mac' but I guess it doesn't.
Anyway, I think that if someone wants to publish an extern that works on either mips or i86 macs, they would have to include both "dylib"s... unless there's a way to make a fat dylib with binaries for both architectures.
Apple provides two mechanisms for this, one is fat binaries, which have been supported since NeXTSTEP 3.2 (Mac OS X 10.4 == NeXTSTEP 6.4), and the other is Rosetta, which runs PPC code in emulation. NeXTSTEP/Apple uses gcc for everything, so building fat binaries is just a matter of figuring out the gcc options.
A fat binary only solves the executable problem. The externals are just as much a headache to deal with as the Pd app - maybe more.
The catch with Rosetta is that you cannot load a PPC lib into an Intel application or vice versa. This is going to become slightly tricky to make sure people get the proper OSX externals that match their CPU type.
I don't think fat dylibs exist -it would be a useful thing to have though.
On May 28, 2006, at 1:07 AM, chris clepper wrote:
On 5/27/06, Hans-Christoph Steiner hans@eds.org wrote:
On May 28, 2006, at 12:22 AM, Miller Puckette wrote:
Yep... I thought 'imac' meant 'intel-mac' but I guess it doesn't.
Anyway, I think that if someone wants to publish an extern that
works
on either mips or i86 macs, they would have to include both "dylib"s... unless there's a way to make a fat dylib with binaries for both architectures.
Apple provides two mechanisms for this, one is fat binaries, which have been supported since NeXTSTEP 3.2 (Mac OS X 10.4 == NeXTSTEP 6.4), and the other is Rosetta, which runs PPC code in emulation. NeXTSTEP/Apple uses gcc for everything, so building fat binaries is just a matter of figuring out the gcc options.
A fat binary only solves the executable problem. The externals are
just as much a headache to deal with as the Pd app - maybe more.
If its just a matter of giving some flags to gcc, which I think it
is, then it would be _much_ easier to add those flags to the relevant
makefiles than to deal with a new file extension.
The catch with Rosetta is that you cannot load a PPC lib into an
Intel application or vice versa. This is going to become slightly
tricky to make sure people get the proper OSX externals that match
their CPU type.I don't think fat dylibs exist -it would be a useful thing to have
though.
I think fat dylibs do exist (from a Slashdot thread): http://apple.slashdot.org/article.pl?sid=05/08/24/2114232
OS X 10.4 uses fat binaries. For example, Apple recently botched a
security update by failing to ship a fat binary for the BSD layer.
This is what it's supposed to look like:
$ file /usr/lib/libSystem.B.dylib
/usr/lib/libSystem.B.dylib: Mach-O fat file with 2 architectures
/usr/lib/libSystem.B.dylib (for architecture ppc): Mach-O
dynamically linked shared library ppc /usr/lib/libSystem.B.dylib (for architecture ppc64): Mach-O 64- bit dynamically linked shared library ppc64
Apple's GCC has built-in support for fat binaries:
$ gcc -o hello hello.m -arch ppc -arch ppc64
$ file hello
hello: Mach-O fat file with 2 architectures
hello (for architecture ppc): Mach-O executable ppc
hello (for architecture ppc64): Mach-O 64-bit executable ppc64
If I had the right SDK installed, I could have added -arch i386.
Building fat binaries with GCC and ICC will probably require the use
of lipo(1).
.hc
"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.
Looks like it works, for dylibs and execs both. I'll start making fat-binary externs for mac (not sure if I can get Pd itself to work as a fat binary but the externs are the really essential thing.)
cheers Miller
On Sun, May 28, 2006 at 01:20:57AM +0200, Hans-Christoph Steiner wrote:
On May 28, 2006, at 1:07 AM, chris clepper wrote:
On 5/27/06, Hans-Christoph Steiner hans@eds.org wrote:
On May 28, 2006, at 12:22 AM, Miller Puckette wrote:
Yep... I thought 'imac' meant 'intel-mac' but I guess it doesn't.
Anyway, I think that if someone wants to publish an extern that
works
on either mips or i86 macs, they would have to include both "dylib"s... unless there's a way to make a fat dylib with binaries for both architectures.
Apple provides two mechanisms for this, one is fat binaries, which have been supported since NeXTSTEP 3.2 (Mac OS X 10.4 == NeXTSTEP 6.4), and the other is Rosetta, which runs PPC code in emulation. NeXTSTEP/Apple uses gcc for everything, so building fat binaries is just a matter of figuring out the gcc options.
A fat binary only solves the executable problem. The externals are
just as much a headache to deal with as the Pd app - maybe more.If its just a matter of giving some flags to gcc, which I think it
is, then it would be _much_ easier to add those flags to the relevant
makefiles than to deal with a new file extension.The catch with Rosetta is that you cannot load a PPC lib into an
Intel application or vice versa. This is going to become slightly
tricky to make sure people get the proper OSX externals that match
their CPU type.I don't think fat dylibs exist -it would be a useful thing to have
though.I think fat dylibs do exist (from a Slashdot thread): http://apple.slashdot.org/article.pl?sid=05/08/24/2114232
OS X 10.4 uses fat binaries. For example, Apple recently botched a
security update by failing to ship a fat binary for the BSD layer.
This is what it's supposed to look like:$ file /usr/lib/libSystem.B.dylib /usr/lib/libSystem.B.dylib: Mach-O fat file with 2 architectures /usr/lib/libSystem.B.dylib (for architecture ppc): Mach-Odynamically linked shared library ppc /usr/lib/libSystem.B.dylib (for architecture ppc64): Mach-O 64- bit dynamically linked shared library ppc64
Apple's GCC has built-in support for fat binaries:
$ gcc -o hello hello.m -arch ppc -arch ppc64 $ file hello hello: Mach-O fat file with 2 architectures hello (for architecture ppc): Mach-O executable ppc hello (for architecture ppc64): Mach-O 64-bit executable ppc64If I had the right SDK installed, I could have added -arch i386.
Building fat binaries with GCC and ICC will probably require the use
of lipo(1)..hc
"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.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 5/27/06, Hans-Christoph Steiner hans@eds.org wrote:
I think fat dylibs do exist
They do. I was not thinking clearly.
If I had the right SDK installed, I could have added -arch i386. Building
fat binaries with GCC and ICC will probably require the use of lipo(1).
lipo is needed for making any fat binaries. You will have to add it to the end of all of the build scripts. This will make Pd-extended quite large on the Mac.
On May 28, 2006, at 2:47 AM, chris clepper wrote:
On 5/27/06, Hans-Christoph Steiner hans@eds.org wrote:
I think fat dylibs do exist
They do. I was not thinking clearly.
If I had the right SDK installed, I could have added -arch i386.
Building fat binaries with GCC and ICC will probably require the
use of lipo(1).lipo is needed for making any fat binaries. You will have to add
it to the end of all of the build scripts. This will make Pd- extended quite large on the Mac.
I think its even easier than that when using gcc. You just add the -
arch flags to your gcc compilation, and it takes care of the rest.
lipo would only be needed if using other compilers, like ICC.
.hc
"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.
Hans-Christoph Steiner wrote:
OS X 10.4 uses fat binaries.
Might be this question is silly, but is fat binaries the key to make (so called) Universial applications [1]?
best, steffen
On May 28, 2006, at 9:32 PM, Steffen wrote:
Hans-Christoph Steiner wrote:
OS X 10.4 uses fat binaries.
Might be this question is silly, but is fat binaries the key to
make (so called) Universial applications [1]?best, steffen
Yes. In typical Apple style, they put their marketing team on it to
come up with a slick name. So fat == universal.
.hc
http://at.or.at/hans/
-
chris clepper -
chris clepper -
Hans-Christoph Steiner -
Miller Puckette -
Steffen