Thanks for your explanation. I checked the "real" programs in Pd-0.46-7-64bit/Contents/Resources/bin/pd, they are x86_64 indeed. Those in Pd-0.46-7/Contents/Resources/bin/pd are i386 and ppc.
Also I noticed the externals extension (for bonk~ etc.) is .d_fat in both cases. Will that be your default extension for OSX? Do you consider distributing Pd for OSX as 32 / 64 bit fat binary in the future? Or even ppc + i386 + x86_64 (which can be built conveniently on OSX 10.5)?
I'm trying to figure out what sort of binaries Makefile.pdlibbuider should best build by default on OSX, hence these questions. We need a strategy to maximize chances that distributed Pd's and externals are compatible.
cheers, Katja
On Sun, Dec 13, 2015 at 3:17 AM, Miller Puckette msp@ucsd.edu wrote:
The "GUI" program (Pd.../Contents/MacOS/Pd) is a copy of the wish shell, and is i386/ppc... but the "real" programs in Pd.../Contents/Resources/bin/pd seem to me to be x86_64 - if not I must have distributed the wrong file somehow.
cheers Miller
On Sat, Dec 12, 2015 at 10:16:56PM +0100, katja wrote:
Hello,
From Miller's site I downloaded "Pd version 0.46-7, 64 bits, compiled for Macintosh OSX 10.8 or later (4 Megabytes)". Checking for target architecture with command 'file', it is reported to be a fat binary for i386 and ppc. Though the application will load all right, it doesn't seem to be the build that is advertised.
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
At the moment, my best idea is to have "fat" externs (i386 and ia64) that can be loaded by either 32 or 64-bit versions of Pd. But I'd like to be able to do two other things I don't know how to do yet:
Have a single version of Pd that can run in 32 or 64 bits
simultaneously enable 64 bit versions with 32 or 64 bit floating samples
The second thing would complicate loading of externs since I don't know how to make a fat binary with two different alternative code sections that are chosen according to the directions of the loading program - at the moment loading is on the basis of architcture (and which code segment to load os chosen automatically by the OS on that basis).
cheers Miller
On Sun, Dec 13, 2015 at 11:37:35AM +0100, katja wrote:
Thanks for your explanation. I checked the "real" programs in Pd-0.46-7-64bit/Contents/Resources/bin/pd, they are x86_64 indeed. Those in Pd-0.46-7/Contents/Resources/bin/pd are i386 and ppc.
Also I noticed the externals extension (for bonk~ etc.) is .d_fat in both cases. Will that be your default extension for OSX? Do you consider distributing Pd for OSX as 32 / 64 bit fat binary in the future? Or even ppc + i386 + x86_64 (which can be built conveniently on OSX 10.5)?
I'm trying to figure out what sort of binaries Makefile.pdlibbuider should best build by default on OSX, hence these questions. We need a strategy to maximize chances that distributed Pd's and externals are compatible.
cheers, Katja
On Sun, Dec 13, 2015 at 3:17 AM, Miller Puckette msp@ucsd.edu wrote:
The "GUI" program (Pd.../Contents/MacOS/Pd) is a copy of the wish shell, and is i386/ppc... but the "real" programs in Pd.../Contents/Resources/bin/pd seem to me to be x86_64 - if not I must have distributed the wrong file somehow.
cheers Miller
On Sat, Dec 12, 2015 at 10:16:56PM +0100, katja wrote:
Hello,
From Miller's site I downloaded "Pd version 0.46-7, 64 bits, compiled for Macintosh OSX 10.8 or later (4 Megabytes)". Checking for target architecture with command 'file', it is reported to be a fat binary for i386 and ppc. Though the application will load all right, it doesn't seem to be the build that is advertised.
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, Dec 13, 2015 at 6:56 PM, Miller Puckette msp@ucsd.edu wrote:
At the moment, my best idea is to have "fat" externs (i386 and ia64) that can be loaded by either 32 or 64-bit versions of Pd. But I'd like to be able to do two other things I don't know how to do yet:
Have a single version of Pd that can run in 32 or 64 bits
Currently Makefile.pdlibbuilder (which isn't used much yet) tries to build fat binaries by default. OSX 10.5 with Xcode 3.1 can build the fattest (ppc and Intel, 32 and 64 bit). Later configurations can build for Intel 32 and 64 bit. In that case the following flags must be given to both compiler and linker:
-arch i386 -arch x86_64 -mmacosx-version-min=10.5
One thing I noticed when building fat binaries: gcc doesn't define __i386__ or __x86_64__ which we use to conditionally compile bithacks. For this reason I'm now thinking that single-architecture should be the default in a generic build system, and fat binary an option.
simultaneously enable 64 bit versions with 32 or 64 bit floating samples
The second thing would complicate loading of externs since I don't know how to make a fat binary with two different alternative code sections that are chosen according to the directions of the loading program - at the moment loading is on the basis of architcture (and which code segment to load os chosen automatically by the OS on that basis).
IOhannes has suggested ideas about loading 'phat' (fat precision) binaries in a pd-dev thread starting here:
http://lists.puredata.info/pipermail/pd-dev/2015-02/020073.html (and further)
Katja
cheers Miller
On Sun, Dec 13, 2015 at 11:37:35AM +0100, katja wrote:
Thanks for your explanation. I checked the "real" programs in Pd-0.46-7-64bit/Contents/Resources/bin/pd, they are x86_64 indeed. Those in Pd-0.46-7/Contents/Resources/bin/pd are i386 and ppc.
Also I noticed the externals extension (for bonk~ etc.) is .d_fat in both cases. Will that be your default extension for OSX? Do you consider distributing Pd for OSX as 32 / 64 bit fat binary in the future? Or even ppc + i386 + x86_64 (which can be built conveniently on OSX 10.5)?
I'm trying to figure out what sort of binaries Makefile.pdlibbuider should best build by default on OSX, hence these questions. We need a strategy to maximize chances that distributed Pd's and externals are compatible.
cheers, Katja
On Sun, Dec 13, 2015 at 3:17 AM, Miller Puckette msp@ucsd.edu wrote:
The "GUI" program (Pd.../Contents/MacOS/Pd) is a copy of the wish shell, and is i386/ppc... but the "real" programs in Pd.../Contents/Resources/bin/pd seem to me to be x86_64 - if not I must have distributed the wrong file somehow.
cheers Miller
On Sat, Dec 12, 2015 at 10:16:56PM +0100, katja wrote:
Hello,
From Miller's site I downloaded "Pd version 0.46-7, 64 bits, compiled for Macintosh OSX 10.8 or later (4 Megabytes)". Checking for target architecture with command 'file', it is reported to be a fat binary for i386 and ppc. Though the application will load all right, it doesn't seem to be the build that is advertised.
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2015-12-13 23:16, katja wrote:
iven to both compiler and linker:
-arch i386 -arch x86_64 -mmacosx-version-min=10.5One thing I noticed when building fat binaries: gcc doesn't define __i386__ or __x86_64__ which we use to conditionally compile bithacks.
?are you sure?
$ cc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) $ cat > testarch.c <<EOL #include <stdio.h> int main() { #ifdef __i386__ printf("i386\n"); #endif #ifdef __x86_64__ printf("x86_64\n"); #endif return 0; } EOL $ make testarch CFLAGS="-arch i386 -arch x86_64 -mmacosx-version-min=10.5" $ ./testarch x86_64 $ arch -i386 ./testarch i386 $ arch -x86_64 ./testarch x86_64 $
For this reason I'm now thinking that single-architecture should be the default in a generic build system, and fat binary an option.
dunno. i think that the default should be to just use the system-defaults (don't tell the compiler which architecture it should build for). this is driven by the experience with tehe template/Makefile: there are a number of externals out there that don't build on recent OSX, because the original template-Makefile would build for PowerPC and apple dropped out-of-the-box support for ppc.
otoh. it's obviously of utmost importance that any thus-compiled external loads correctly under a "default" Pd installation.
so for practical reasons it's probably best to use i386/x86_64 (and don't enable PPC by default)
fgmadr IOhannes
On Tue, Dec 15, 2015 at 9:56 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2015-12-13 23:16, katja wrote:
iven to both compiler and linker:
-arch i386 -arch x86_64 -mmacosx-version-min=10.5One thing I noticed when building fat binaries: gcc doesn't define __i386__ or __x86_64__ which we use to conditionally compile bithacks.
?are you sure?
$ cc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) $ cat > testarch.c <<EOL #include <stdio.h> int main() { #ifdef __i386__ printf("i386\n"); #endif #ifdef __x86_64__ printf("x86_64\n"); #endif return 0; } EOL $ make testarch CFLAGS="-arch i386 -arch x86_64 -mmacosx-version-min=10.5" $ ./testarch x86_64 $ arch -i386 ./testarch i386 $ arch -x86_64 ./testarch x86_64 $
This looks good, thanks for proving me wrong. Which OSX version is this? I've had troubles with denormals in fat binaries in the past (OSX 10.5). It turned out that the preprocessor didn't pass architecture defines when preprocessing for multiple architectures. The behavior has apparently changed with compiler version. I'll look into this matter again.
For this reason I'm now thinking that single-architecture should be the default in a generic build system, and fat binary an option.
dunno. i think that the default should be to just use the system-defaults (don't tell the compiler which architecture it should build for). this is driven by the experience with tehe template/Makefile: there are a number of externals out there that don't build on recent OSX, because the original template-Makefile would build for PowerPC and apple dropped out-of-the-box support for ppc.
otoh. it's obviously of utmost importance that any thus-compiled external loads correctly under a "default" Pd installation.
so for practical reasons it's probably best to use i386/x86_64 (and don't enable PPC by default)
On 'recent' OSX (>= 10.6) Makefile.pdlibbuilder builds i386 / x86_64 by default, no ppc. For OSX 10.5 the default includes ppc which was still supported at that time. OSX 10.5 can build the fattest binaries out of the box. But I didn't include ppc 64 bit (yet) as I've never had an opportunity to test that.
fgmadr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2015-12-15 11:07, katja wrote:
This looks good, thanks for proving me wrong. Which OSX version is this? I've had troubles with denormals in fat binaries in the past (OSX 10.5). It turned out that the preprocessor didn't pass architecture defines when preprocessing for multiple architectures.
tested on both 10.6 and 10.9
$ sw_vers ProductName: Mac OS X ProductVersion: 10.6.8 BuildVersion: 10K549 $ cc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
resp.
$ sw_vers ProductName: Mac OS X ProductVersion: 10.9.5 BuildVersion: 13F34 $ cat vers.txt Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin13.4.0 Thread model: posix
gfda,sr IOhannes
On 2015-12-13 23:16, katja wrote:
The second thing would complicate loading of externs since I don't know how to make a fat binary with two different alternative code sections that are chosen according to the directions of the loading program - at the moment loading is on the basis of architcture (and which code segment to load os chosen automatically by the OS on that basis).
IOhannes has suggested ideas about loading 'phat' (fat precision) binaries in a pd-dev thread starting here:
http://lists.puredata.info/pipermail/pd-dev/2015-02/020073.html (and further)
i still think that this is a sane plan (though it could probably be simplified a bit more). if there is interest, i could provide a patch to implement that.
lately i was thinking about the possibilities to allow loading/using of externals with the "wrong" precision, e.g. a legacy mode, that would run old (single precision) externals in a double precision runtime.
most likely it's possible as long as the external doesn't use any heap-allocated numbers (tables), but it's probably not wort the effort.
i *guess* that max7 would allow to run single-precision DSP code (even though by now, max uses double precision signals), but might be totally wrong.
fgmasdr IOhannes
-
IOhannes m zmoelnig -
katja -
Miller Puckette