[PD] fat binaries or not, on OSX (was: 'Pd 64 bits' for OSX is i386 + ppc)

[katja]

On Tue, Dec 15, 2015 at 1:00 PM, IOhannes m zmoelnig  wrote:
> 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
>

Today I could test the same on OSX 10.5 with Xcode 3.1.4 installed and
it seems to work fine here as well (__i386__ resp. __x86_64__ defined
in the case of fat binaries).

$ sw_vers
ProductName:Mac OS X
ProductVersion:10.5.8
BuildVersion:9L31a

$ cc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)

Only thing I can't test now is with gcc < 4 but so far my 'issue'
couldn't be reproduced, fortunately.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] fat binaries or not, on OSX (was: 'Pd 64 bits' for OSX is i386 + ppc)

[Dan Wilcox]

Hah point taken. Let’s just say I’m playing a little devil’s advocate after 
fielding open source support requests for free the last week …


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Dec 15, 2015, at 5:26 PM, katja  wrote:
> 
> If Pd externals could be built for PDP11, I would support it in
> Makefile.pdlibbuilder.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] fat binaries or not, on OSX (was: 'Pd 64 bits' for OSX is i386 + ppc)

[katja]

If Pd externals could be built for PDP11, I would support it in
Makefile.pdlibbuilder.

Even when very few people still use Apple ppc it's nice to be able to
support it. But not at the expense of other platforms of course. If
you (or anyone else) encounter specific problems when building on OSX
10.5 because of the ppc target architecture, please report on
https://github.com/pure-data/pd-lib-builder. On later OSX versions it
won't try to build for ppc so for most people this goes unnoticed.

If instead you object to the distribution of combined ppc/intel
binaries via deken, that is a different matter going beyond discussion
of the makefile.

Katja

On Tue, Dec 15, 2015 at 7:57 PM, Dan Wilcox  wrote:
> My 2 cents:
>
> Honestly, I *really* wouldn’t bother with maintaining ppc support anymore.
> 10.5 was released in Oct of 2007, that’s 6 versions ago and 99.9% of people
> running OSX are not running ppc. I understand the desire to support it, but
> those people can use older versions of Pd. Without going down the “Apple
> forces planned obsolesce, blah blah” fest again, the practical matter is
> that the need for OSX ppc is so small I feel developer effort is best spent
> elsewhere. Besides, if I were resurrecting an old Power PC G5 Mac Pro, I’d
> install Debian on it anyway.
>
> OTOH, if you personally have an old Powerbook and want to keep Pd on it up
> to date, go for it! I’m just suggesting, if that’s not the case, it may not
> be worth the extra time and effort.
>
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
> On Dec 15, 2015, at 4:00 AM, pd-list-requ...@lists.iem.at wrote:
>
> 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.
>
>

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] fat binaries or not, on OSX (was: 'Pd 64 bits' for OSX is i386 + ppc)

[Dan Wilcox]

My 2 cents:

Honestly, I *really* wouldn’t bother with maintaining ppc support anymore. 10.5 
was released in Oct of 2007, that’s 6 versions ago and 99.9% of people running 
OSX are not running ppc. I understand the desire to support it, but those 
people can use older versions of Pd. Without going down the “Apple forces 
planned obsolesce, blah blah” fest again, the practical matter is that the need 
for OSX ppc is so small I feel developer effort is best spent elsewhere. 
Besides, if I were resurrecting an old Power PC G5 Mac Pro, I’d install Debian 
on it anyway.

OTOH, if you personally have an old Powerbook and want to keep Pd on it up to 
date, go for it! I’m just suggesting, if that’s not the case, it may not be 
worth the extra time and effort.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Dec 15, 2015, at 4:00 AM, pd-list-requ...@lists.iem.at wrote:
> 
> 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.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] fat binaries or not, on OSX (was: 'Pd 64 bits' for OSX is i386 + ppc)

[IOhannes m zmoelnig]

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



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] fat binaries or not, on OSX (was: 'Pd 64 bits' for OSX is i386 + ppc)

[katja]

On Tue, Dec 15, 2015 at 9:56 AM, IOhannes m zmoelnig  wrote:
> On 2015-12-13 23:16, katja wrote:
>> iven 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.
>
> ?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 < #include 
> 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
>

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] fat binaries or not, on OSX (was: 'Pd 64 bits' for OSX is i386 + ppc)

[IOhannes m zmoelnig]

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







signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] fat binaries or not, on OSX (was: 'Pd 64 bits' for OSX is i386 + ppc)

[IOhannes m zmoelnig]

On 2015-12-13 23:16, katja wrote:
> iven 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.

?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 <
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



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] fat binaries or not, on OSX (was: 'Pd 64 bits' for OSX is i386 + ppc)

[katja]

On Sun, Dec 13, 2015 at 6:56 PM, Miller Puckette  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  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

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] fat binaries or not, on OSX (was: 'Pd 64 bits' for OSX is i386 + ppc)

[Miller Puckette]

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  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

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] fat binaries or not, on OSX (was: 'Pd 64 bits' for OSX is i386 + ppc)

[katja]

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  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