Hi everyone,

just started looking at a 10.6 build. I have actually just looked at  
some essential dependencies, and here are some points and questions.

1. libsndfile: it builds and runs fine with ./configure using no  
options. Code built for x86_64 seems to link to it OK.
However, ./configure reports  architecture as i386. So I am actually  
puzzled. If I configure with --build=x86_64, it then reports
that architecture, but fails to build sndfile-play, because it says  
"Carbon.h" is missing. That makes a bit of sense, since apparently  
Carbon has been discontinued in that architecture. But how come   
x86_64 code links to i386 lib? Is this what is called a 'fat-binary'  
with both architectures?

2.portmidi: it appears that portmidi only builds i386 binaries. You  
can't link to it with x86_64 code. This might be related to missing C  
APIs. I have sent an e-mail to Roger Dannenberg to see if he knows why  
this is.

3.portaudio: this actually seems fine. Interestingly, while a version  
of libsndfile built on 10.6 will not work with Csound built on 10.5,  
portaudio seems to be OK, no complaints of wrong architecture.


4. FLTK: I was able to build it only with -arch i386 (vers. 1.1.10).  
So I guess this will be another headache.


I have not actually tried to build Csound, this will be next on the  
list. I don't remember having so many issues when moving to new  
versions of Linux or Windows. Apple is just terrible with the  
compatibility thing.


Regards.

Victor

  

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Victor,

This is unrelated but now that you are at it. I think the new macbook  
pros use 64bit hardware so it would probably make sense to have an  
option on the snowleopard installer to only install the double version.

Best,

P

On 3 Jun 2010, at 13:41, Victor Lazzarini wrote:

> Hi everyone,
>
> just started looking at a 10.6 build. I have actually just looked at
> some essential dependencies, and here are some points and questions.
>
> 1. libsndfile: it builds and runs fine with ./configure using no
> options. Code built for x86_64 seems to link to it OK.
> However, ./configure reports  architecture as i386. So I am actually
> puzzled. If I configure with --build=x86_64, it then reports
> that architecture, but fails to build sndfile-play, because it says
> "Carbon.h" is missing. That makes a bit of sense, since apparently
> Carbon has been discontinued in that architecture. But how come
> x86_64 code links to i386 lib? Is this what is called a 'fat-binary'
> with both architectures?
>
> 2.portmidi: it appears that portmidi only builds i386 binaries. You
> can't link to it with x86_64 code. This might be related to missing C
> APIs. I have sent an e-mail to Roger Dannenberg to see if he knows why
> this is.
>
> 3.portaudio: this actually seems fine. Interestingly, while a version
> of libsndfile built on 10.6 will not work with Csound built on 10.5,
> portaudio seems to be OK, no complaints of wrong architecture.
>
>
> 4. FLTK: I was able to build it only with -arch i386 (vers. 1.1.10).
> So I guess this will be another headache.
>
>
> I have not actually tried to build Csound, this will be next on the
> list. I don't remember having so many issues when moving to new
> versions of Linux or Windows. Apple is just terrible with the
> compatibility thing.
>
>
> Regards.
>
> Victor
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

yes, I think the 10.6 installer will be doubles-only. That'll also  
facilitate things for me.

Victor

On 3 Jun 2010, at 13:47, Peiman Khosravi wrote:

> Hi Victor,
>
> This is unrelated but now that you are at it. I think the new macbook
> pros use 64bit hardware so it would probably make sense to have an
> option on the snowleopard installer to only install the double  
> version.
>
> Best,
>
> P
>
> On 3 Jun 2010, at 13:41, Victor Lazzarini wrote:
>
>> Hi everyone,
>>
>> just started looking at a 10.6 build. I have actually just looked at
>> some essential dependencies, and here are some points and questions.
>>
>> 1. libsndfile: it builds and runs fine with ./configure using no
>> options. Code built for x86_64 seems to link to it OK.
>> However, ./configure reports  architecture as i386. So I am actually
>> puzzled. If I configure with --build=x86_64, it then reports
>> that architecture, but fails to build sndfile-play, because it says
>> "Carbon.h" is missing. That makes a bit of sense, since apparently
>> Carbon has been discontinued in that architecture. But how come
>> x86_64 code links to i386 lib? Is this what is called a 'fat-binary'
>> with both architectures?
>>
>> 2.portmidi: it appears that portmidi only builds i386 binaries. You
>> can't link to it with x86_64 code. This might be related to missing C
>> APIs. I have sent an e-mail to Roger Dannenberg to see if he knows  
>> why
>> this is.
>>
>> 3.portaudio: this actually seems fine. Interestingly, while a version
>> of libsndfile built on 10.6 will not work with Csound built on 10.5,
>> portaudio seems to be OK, no complaints of wrong architecture.
>>
>>
>> 4. FLTK: I was able to build it only with -arch i386 (vers. 1.1.10).
>> So I guess this will be another headache.
>>
>>
>> I have not actually tried to build Csound, this will be next on the
>> list. I don't remember having so many issues when moving to new
>> versions of Linux or Windows. Apple is just terrible with the
>> compatibility thing.
>>
>>
>> Regards.
>>
>> Victor
>>
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Yes it makes sense (I don't know when I'll be migrating myself as I  
might just move to linux after my computer dies).

Thanks

Peiman

On 3 Jun 2010, at 14:08, Victor Lazzarini wrote:

> yes, I think the 10.6 installer will be doubles-only. That'll also
> facilitate things for me.
>
> Victor
>
> On 3 Jun 2010, at 13:47, Peiman Khosravi wrote:
>
>> Hi Victor,
>>
>> This is unrelated but now that you are at it. I think the new macbook
>> pros use 64bit hardware so it would probably make sense to have an
>> option on the snowleopard installer to only install the double
>> version.
>>
>> Best,
>>
>> P
>>
>> On 3 Jun 2010, at 13:41, Victor Lazzarini wrote:
>>
>>> Hi everyone,
>>>
>>> just started looking at a 10.6 build. I have actually just looked at
>>> some essential dependencies, and here are some points and questions.
>>>
>>> 1. libsndfile: it builds and runs fine with ./configure using no
>>> options. Code built for x86_64 seems to link to it OK.
>>> However, ./configure reports  architecture as i386. So I am actually
>>> puzzled. If I configure with --build=x86_64, it then reports
>>> that architecture, but fails to build sndfile-play, because it says
>>> "Carbon.h" is missing. That makes a bit of sense, since apparently
>>> Carbon has been discontinued in that architecture. But how come
>>> x86_64 code links to i386 lib? Is this what is called a 'fat-binary'
>>> with both architectures?
>>>
>>> 2.portmidi: it appears that portmidi only builds i386 binaries. You
>>> can't link to it with x86_64 code. This might be related to  
>>> missing C
>>> APIs. I have sent an e-mail to Roger Dannenberg to see if he knows
>>> why
>>> this is.
>>>
>>> 3.portaudio: this actually seems fine. Interestingly, while a  
>>> version
>>> of libsndfile built on 10.6 will not work with Csound built on 10.5,
>>> portaudio seems to be OK, no complaints of wrong architecture.
>>>
>>>
>>> 4. FLTK: I was able to build it only with -arch i386 (vers. 1.1.10).
>>> So I guess this will be another headache.
>>>
>>>
>>> I have not actually tried to build Csound, this will be next on the
>>> list. I don't remember having so many issues when moving to new
>>> versions of Linux or Windows. Apple is just terrible with the
>>> compatibility thing.
>>>
>>>
>>> Regards.
>>>
>>> Victor
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi all,

Since I had this kind of (unsuccesful) headache some time ago, let me 
share part of my experience, hope it may save some of your time:
	
> 1. libsndfile: it builds and runs fine with ./configure using no
> options. Code built for x86_64 seems to link to it OK.
> However, ./configure reports  architecture as i386. So I am actually
> puzzled. If I configure with --build=x86_64, it then reports
> that architecture, but fails to build sndfile-play, because it says
> "Carbon.h" is missing. That makes a bit of sense, since apparently
> Carbon has been discontinued in that architecture. But how come
> x86_64 code links to i386 lib? Is this what is called a 'fat-binary'
> with both architectures?
>

I had no problem with building libsndfile version 1.0.21 as universal 
using macports ("port install libsndfile +universal"). I remembered also 
that before that, I tried to build it directly from sources in x86_64 
only, and it worked. However maybe it's a good idea to build it as a 
universal, so that you can build i386 and x86_64 versions of csound easier.


> 2.portmidi: it appears that portmidi only builds i386 binaries. You
> can't link to it with x86_64 code. This might be related to missing C
> APIs. I have sent an e-mail to Roger Dannenberg to see if he knows why
> this is.

Are you sure ? With the sources I have (19Oct09 as it seems from the 
changelog), without any option flags, it creates a mach-o with 3 
architectures (X86_64, i386, and ppc7400), that so far seem to work on 
my machine... strange. I can provide my portmidi sources if needed.


>
> 4. FLTK: I was able to build it only with -arch i386 (vers. 1.1.10).
> So I guess this will be another headache.
>

The main issue as far as I understand is that FLTK relies on Carbon, 
which is not working on 64bit architectures. The development branch 1.3 
started porting code on Cocoa, but it's still unfinished. All the 
examples provided with fltk work, but Fluid does not build. I guess 
we'll have to be patient.

Also, the building scripts for csound will have to be changed, and 
include Cocoa instead of Carbon.

Alexis

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

You might want to check out fink . They already provide packages for
libsndfile, portaudio and fltk (although only the X11 version is
available for x86_64). Portmidi is missing, though. The fink project
seems interesting.

http://www.finkproject.org/

On Thu, Jun 3, 2010 at 11:09, Alexis Baskind  wrote:
> Hi all,
>
> Since I had this kind of (unsuccesful) headache some time ago, let me
> share part of my experience, hope it may save some of your time:
>
>> 1. libsndfile: it builds and runs fine with ./configure using no
>> options. Code built for x86_64 seems to link to it OK.
>> However, ./configure reports  architecture as i386. So I am actually
>> puzzled. If I configure with --build=x86_64, it then reports
>> that architecture, but fails to build sndfile-play, because it says
>> "Carbon.h" is missing. That makes a bit of sense, since apparently
>> Carbon has been discontinued in that architecture. But how come
>> x86_64 code links to i386 lib? Is this what is called a 'fat-binary'
>> with both architectures?
>>
>
> I had no problem with building libsndfile version 1.0.21 as universal
> using macports ("port install libsndfile +universal"). I remembered also
> that before that, I tried to build it directly from sources in x86_64
> only, and it worked. However maybe it's a good idea to build it as a
> universal, so that you can build i386 and x86_64 versions of csound easier.
>
>
>> 2.portmidi: it appears that portmidi only builds i386 binaries. You
>> can't link to it with x86_64 code. This might be related to missing C
>> APIs. I have sent an e-mail to Roger Dannenberg to see if he knows why
>> this is.
>
> Are you sure ? With the sources I have (19Oct09 as it seems from the
> changelog), without any option flags, it creates a mach-o with 3
> architectures (X86_64, i386, and ppc7400), that so far seem to work on
> my machine... strange. I can provide my portmidi sources if needed.
>
>
>>
>> 4. FLTK: I was able to build it only with -arch i386 (vers. 1.1.10).
>> So I guess this will be another headache.
>>
>
> The main issue as far as I understand is that FLTK relies on Carbon,
> which is not working on 64bit architectures. The development branch 1.3
> started porting code on Cocoa, but it's still unfinished. All the
> examples provided with fltk work, but Fluid does not build. I guess
> we'll have to be patient.
>
> Also, the building scripts for csound will have to be changed, and
> include Cocoa instead of Carbon.
>
> Alexis
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.

Well, I picked up a zip from sourceforge today, installed cmake and  
ran make:

make -f pm_mac/Makefile.osx

then I tried to build a little program using it, but could only link  
if I compiled it
with -arch i386

Maybe you can send me your sources.

Victor

On 3 Jun 2010, at 16:09, Alexis Baskind wrote:

>>
>> 2.portmidi: it appears that portmidi only builds i386 binaries. You
>> can't link to it with x86_64 code. This might be related to missing C
>> APIs. I have sent an e-mail to Roger Dannenberg to see if he knows  
>> why
>> this is.
>
> Are you sure ? With the sources I have (19Oct09 as it seems from the
> changelog), without any option flags, it creates a mach-o with 3
> architectures (X86_64, i386, and ppc7400), that so far seem to work on
> my machine... strange. I can provide my portmidi sources if needed.


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

yes, but given the fact that I package all these in the installer, I  
generally prefer to build them myself from upstream sources, so I know  
what to expect.
But maybe it's something to consider if all else fails.

Victor
On 3 Jun 2010, at 16:20, Felipe Sateler wrote:

> You might want to check out fink . They already provide packages for
> libsndfile, portaudio and fltk (although only the X11 version is
> available for x86_64). Portmidi is missing, though. The fink project
> seems interesting.
>
> http://www.finkproject.org/
>
> On Thu, Jun 3, 2010 at 11:09, Alexis Baskind  
>  wrote:
>> Hi all,
>>
>> Since I had this kind of (unsuccesful) headache some time ago, let me
>> share part of my experience, hope it may save some of your time:
>>
>>> 1. libsndfile: it builds and runs fine with ./configure using no
>>> options. Code built for x86_64 seems to link to it OK.
>>> However, ./configure reports  architecture as i386. So I am actually
>>> puzzled. If I configure with --build=x86_64, it then reports
>>> that architecture, but fails to build sndfile-play, because it says
>>> "Carbon.h" is missing. That makes a bit of sense, since apparently
>>> Carbon has been discontinued in that architecture. But how come
>>> x86_64 code links to i386 lib? Is this what is called a 'fat-binary'
>>> with both architectures?
>>>
>>
>> I had no problem with building libsndfile version 1.0.21 as universal
>> using macports ("port install libsndfile +universal"). I remembered  
>> also
>> that before that, I tried to build it directly from sources in x86_64
>> only, and it worked. However maybe it's a good idea to build it as a
>> universal, so that you can build i386 and x86_64 versions of csound  
>> easier.
>>
>>
>>> 2.portmidi: it appears that portmidi only builds i386 binaries. You
>>> can't link to it with x86_64 code. This might be related to  
>>> missing C
>>> APIs. I have sent an e-mail to Roger Dannenberg to see if he knows  
>>> why
>>> this is.
>>
>> Are you sure ? With the sources I have (19Oct09 as it seems from the
>> changelog), without any option flags, it creates a mach-o with 3
>> architectures (X86_64, i386, and ppc7400), that so far seem to work  
>> on
>> my machine... strange. I can provide my portmidi sources if needed.
>>
>>
>>>
>>> 4. FLTK: I was able to build it only with -arch i386 (vers. 1.1.10).
>>> So I guess this will be another headache.
>>>
>>
>> The main issue as far as I understand is that FLTK relies on Carbon,
>> which is not working on 64bit architectures. The development branch  
>> 1.3
>> started porting code on Cocoa, but it's still unfinished. All the
>> examples provided with fltk work, but Fluid does not build. I guess
>> we'll have to be patient.
>>
>> Also, the building scripts for csound will have to be changed, and
>> include Cocoa instead of Carbon.
>>
>> Alexis
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> -- 
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

But one thing has to be considered, is that a 64bit-only version won't 
work when using CsoundLib directly with a 32-bit binary. For instance, 
csound~ on Max/MSP is 32 bits (it can't be 64bits since Max/MSP isn't), 
and it does not accept to link to a x86_64 csound lib (I tried).

Why not making a universal i386/x86_64 distribution of csound ? It 
shouldn't be that hard to make, and it's easier than having to maintain 
two installers (one for <10.6, one for 10.6), since it will at least 
work on 10.5 also.

alexis

Le 03/06/10 15:08, Victor Lazzarini a écrit :
> yes, I think the 10.6 installer will be doubles-only. That'll also
> facilitate things for me.
>
> Victor
>
> On 3 Jun 2010, at 13:47, Peiman Khosravi wrote:
>
>> Hi Victor,
>>
>> This is unrelated but now that you are at it. I think the new macbook
>> pros use 64bit hardware so it would probably make sense to have an
>> option on the snowleopard installer to only install the double
>> version.
>>
>> Best,


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Alexis,

There is a 64bit version of csound~ (which uses csound64) and can be  
used within maxmsp even on a 32bit machine.

Best

P

On 3 Jun 2010, at 16:35, Alexis Baskind wrote:

> But one thing has to be considered, is that a 64bit-only version won't
> work when using CsoundLib directly with a 32-bit binary. For instance,
> csound~ on Max/MSP is 32 bits (it can't be 64bits since Max/MSP  
> isn't),
> and it does not accept to link to a x86_64 csound lib (I tried).
>
> Why not making a universal i386/x86_64 distribution of csound ? It
> shouldn't be that hard to make, and it's easier than having to  
> maintain
> two installers (one for <10.6, one for 10.6), since it will at least
> work on 10.5 also.
>
> alexis
>
> Le 03/06/10 15:08, Victor Lazzarini a écrit :
>> yes, I think the 10.6 installer will be doubles-only. That'll also
>> facilitate things for me.
>>
>> Victor
>>
>> On 3 Jun 2010, at 13:47, Peiman Khosravi wrote:
>>
>>> Hi Victor,
>>>
>>> This is unrelated but now that you are at it. I think the new  
>>> macbook
>>> pros use 64bit hardware so it would probably make sense to have an
>>> option on the snowleopard installer to only install the double
>>> version.
>>>
>>> Best,
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The csound sample size is different from architecture. You cannot link
32bit binaries to 64bit binaries. The MYFLT size (Which is what csound
refers to as float or double version) has no relation to this.

On Thu, Jun 3, 2010 at 11:38, Peiman Khosravi  wrote:
> Hi Alexis,
>
> There is a 64bit version of csound~ (which uses csound64) and can be
> used within maxmsp even on a 32bit machine.
>
> Best
>
> P
>
> On 3 Jun 2010, at 16:35, Alexis Baskind wrote:
>
>> But one thing has to be considered, is that a 64bit-only version won't
>> work when using CsoundLib directly with a 32-bit binary. For instance,
>> csound~ on Max/MSP is 32 bits (it can't be 64bits since Max/MSP
>> isn't),
>> and it does not accept to link to a x86_64 csound lib (I tried).
>>
>> Why not making a universal i386/x86_64 distribution of csound ? It
>> shouldn't be that hard to make, and it's easier than having to
>> maintain
>> two installers (one for <10.6, one for 10.6), since it will at least
>> work on 10.5 also.
>>
>> alexis
>>
>> Le 03/06/10 15:08, Victor Lazzarini a écrit :
>>> yes, I think the 10.6 installer will be doubles-only. That'll also
>>> facilitate things for me.
>>>
>>> Victor
>>>
>>> On 3 Jun 2010, at 13:47, Peiman Khosravi wrote:
>>>
>>>> Hi Victor,
>>>>
>>>> This is unrelated but now that you are at it. I think the new
>>>> macbook
>>>> pros use 64bit hardware so it would probably make sense to have an
>>>> option on the snowleopard installer to only install the double
>>>> version.
>>>>
>>>> Best,
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lis

Because I think a universal version is going to be difficult to get  
right. Also it will require universal versions of all dependencies and  
plugin opcodes. But I am willing to try. How do you do one?

Victor
On 3 Jun 2010, at 16:35, Alexis Baskind wrote:

> But one thing has to be considered, is that a 64bit-only version won't
> work when using CsoundLib directly with a 32-bit binary. For instance,
> csound~ on Max/MSP is 32 bits (it can't be 64bits since Max/MSP  
> isn't),
> and it does not accept to link to a x86_64 csound lib (I tried).
>
> Why not making a universal i386/x86_64 distribution of csound ? It
> shouldn't be that hard to make, and it's easier than having to  
> maintain
> two installers (one for <10.6, one for 10.6), since it will at least
> work on 10.5 also.
>
> alexis
>
> Le 03/06/10 15:08, Victor Lazzarini a écrit :
>> yes, I think the 10.6 installer will be doubles-only. That'll also
>> facilitate things for me.
>>
>> Victor
>>
>> On 3 Jun 2010, at 13:47, Peiman Khosravi wrote:
>>
>>> Hi Victor,
>>>
>>> This is unrelated but now that you are at it. I think the new  
>>> macbook
>>> pros use 64bit hardware so it would probably make sense to have an
>>> option on the snowleopard installer to only install the double
>>> version.
>>>
>>> Best,
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I see OK. thanks.

On 3 Jun 2010, at 16:41, Felipe Sateler wrote:

> The csound sample size is different from architecture. You cannot link
> 32bit binaries to 64bit binaries. The MYFLT size (Which is what csound
> refers to as float or double version) has no relation to this.
>
> On Thu, Jun 3, 2010 at 11:38, Peiman Khosravi  > wrote:
>> Hi Alexis,
>>
>> There is a 64bit version of csound~ (which uses csound64) and can be
>> used within maxmsp even on a 32bit machine.
>>
>> Best
>>
>> P
>>
>> On 3 Jun 2010, at 16:35, Alexis Baskind wrote:
>>
>>> But one thing has to be considered, is that a 64bit-only version  
>>> won't
>>> work when using CsoundLib directly with a 32-bit binary. For  
>>> instance,
>>> csound~ on Max/MSP is 32 bits (it can't be 64bits since Max/MSP
>>> isn't),
>>> and it does not accept to link to a x86_64 csound lib (I tried).
>>>
>>> Why not making a universal i386/x86_64 distribution of csound ? It
>>> shouldn't be that hard to make, and it's easier than having to
>>> maintain
>>> two installers (one for <10.6, one for 10.6), since it will at least
>>> work on 10.5 also.
>>>
>>> alexis
>>>
>>> Le 03/06/10 15:08, Victor Lazzarini a écrit :
>>>> yes, I think the 10.6 installer will be doubles-only. That'll also
>>>> facilitate things for me.
>>>>
>>>> Victor
>>>>
>>>> On 3 Jun 2010, at 13:47, Peiman Khosravi wrote:
>>>>
>>>>> Hi Victor,
>>>>>
>>>>> This is unrelated but now that you are at it. I think the new
>>>>> macbook
>>>>> pros use 64bit hardware so it would probably make sense to have an
>>>>> option on the snowleopard installer to only install the double
>>>>> version.
>>>>>
>>>>> Best,
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> -- 
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I just checked (the OSX 10.6 machine is not in my office and is not  
currently on network, so I had to go over there)
and:

1. portmidi: Fat binary but only with PPC & i386
2. libsndfile: only x86_64.

portaudio (here and there) has all four cpus intel & ppc, 32 and 64.  
This is the ideal scenario. What is the command-line option to create  
this, does anyone know?

Victor



On 3 Jun 2010, at 16:35, Alexis Baskind wrote:

> But one thing has to be considered, is that a 64bit-only version won't
> work when using CsoundLib directly with a 32-bit binary. For instance,
> csound~ on Max/MSP is 32 bits (it can't be 64bits since Max/MSP  
> isn't),
> and it does not accept to link to a x86_64 csound lib (I tried).
>
> Why not making a universal i386/x86_64 distribution of csound ? It
> shouldn't be that hard to make, and it's easier than having to  
> maintain
> two installers (one for <10.6, one for 10.6), since it will at least
> work on 10.5 also.
>
> alexis
>
> Le 03/06/10 15:08, Victor Lazzarini a écrit :
>> yes, I think the 10.6 installer will be doubles-only. That'll also
>> facilitate things for me.
>>
>> Victor
>>
>> On 3 Jun 2010, at 13:47, Peiman Khosravi wrote:
>>
>>> Hi Victor,
>>>
>>> This is unrelated but now that you are at it. I think the new  
>>> macbook
>>> pros use 64bit hardware so it would probably make sense to have an
>>> option on the snowleopard installer to only install the double
>>> version.
>>>
>>> Best,
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I just looked at Macports and I don't think I can use it, it will just  
mess up my packaging. Unfortunately, it's been problematic to get  
libsndfile to build for more than one architecture. There is a gcc  
option that cannnot be used with multiple architectures in the  
Makefile and I can't get rid of it. I'll keep trying.

Victor


On 3 Jun 2010, at 16:09, Alexis Baskind wrote:

> Hi all,
>
> Since I had this kind of (unsuccesful) headache some time ago, let me
> share part of my experience, hope it may save some of your time:
> 	
>> 1. libsndfile: it builds and runs fine with ./configure using no
>> options. Code built for x86_64 seems to link to it OK.
>> However, ./configure reports  architecture as i386. So I am actually
>> puzzled. If I configure with --build=x86_64, it then reports
>> that architecture, but fails to build sndfile-play, because it says
>> "Carbon.h" is missing. That makes a bit of sense, since apparently
>> Carbon has been discontinued in that architecture. But how come
>> x86_64 code links to i386 lib? Is this what is called a 'fat-binary'
>> with both architectures?
>>
>
> I had no problem with building libsndfile version 1.0.21 as universal
> using macports ("port install libsndfile +universal"). I remembered  
> also
> that before that, I tried to build it directly from sources in x86_64
> only, and it worked. However maybe it's a good idea to build it as a
> universal, so that you can build i386 and x86_64 versions of csound  
> easier.
>
>
>> 2.portmidi: it appears that portmidi only builds i386 binaries. You
>> can't link to it with x86_64 code. This might be related to missing C
>> APIs. I have sent an e-mail to Roger Dannenberg to see if he knows  
>> why
>> this is.
>
> Are you sure ? With the sources I have (19Oct09 as it seems from the
> changelog), without any option flags, it creates a mach-o with 3
> architectures (X86_64, i386, and ppc7400), that so far seem to work on
> my machine... strange. I can provide my portmidi sources if needed.
>
>
>>
>> 4. FLTK: I was able to build it only with -arch i386 (vers. 1.1.10).
>> So I guess this will be another headache.
>>
>
> The main issue as far as I understand is that FLTK relies on Carbon,
> which is not working on 64bit architectures. The development branch  
> 1.3
> started porting code on Cocoa, but it's still unfinished. All the
> examples provided with fltk work, but Fluid does not build. I guess
> we'll have to be patient.
>
> Also, the building scripts for csound will have to be changed, and
> include Cocoa instead of Carbon.
>
> Alexis
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I should have read the FAQ. The way to do this is to build the library  
for different architectures and then use lipo to merge the binaries.
I will try this later.

Victor
On 3 Jun 2010, at 22:40, Victor Lazzarini wrote:

> I just looked at Macports and I don't think I can use it, it will just
> mess up my packaging. Unfortunately, it's been problematic to get
> libsndfile to build for more than one architecture. There is a gcc
> option that cannnot be used with multiple architectures in the
> Makefile and I can't get rid of it. I'll keep trying.
>
> Victor
>
>
> On 3 Jun 2010, at 16:09, Alexis Baskind wrote:
>
>> Hi all,
>>
>> Since I had this kind of (unsuccesful) headache some time ago, let me
>> share part of my experience, hope it may save some of your time:
>> 	
>>> 1. libsndfile: it builds and runs fine with ./configure using no
>>> options. Code built for x86_64 seems to link to it OK.
>>> However, ./configure reports  architecture as i386. So I am actually
>>> puzzled. If I configure with --build=x86_64, it then reports
>>> that architecture, but fails to build sndfile-play, because it says
>>> "Carbon.h" is missing. That makes a bit of sense, since apparently
>>> Carbon has been discontinued in that architecture. But how come
>>> x86_64 code links to i386 lib? Is this what is called a 'fat-binary'
>>> with both architectures?
>>>
>>
>> I had no problem with building libsndfile version 1.0.21 as universal
>> using macports ("port install libsndfile +universal"). I remembered
>> also
>> that before that, I tried to build it directly from sources in x86_64
>> only, and it worked. However maybe it's a good idea to build it as a
>> universal, so that you can build i386 and x86_64 versions of csound
>> easier.
>>
>>
>>> 2.portmidi: it appears that portmidi only builds i386 binaries. You
>>> can't link to it with x86_64 code. This might be related to  
>>> missing C
>>> APIs. I have sent an e-mail to Roger Dannenberg to see if he knows
>>> why
>>> this is.
>>
>> Are you sure ? With the sources I have (19Oct09 as it seems from the
>> changelog), without any option flags, it creates a mach-o with 3
>> architectures (X86_64, i386, and ppc7400), that so far seem to work  
>> on
>> my machine... strange. I can provide my portmidi sources if needed.
>>
>>
>>>
>>> 4. FLTK: I was able to build it only with -arch i386 (vers. 1.1.10).
>>> So I guess this will be another headache.
>>>
>>
>> The main issue as far as I understand is that FLTK relies on Carbon,
>> which is not working on 64bit architectures. The development branch
>> 1.3
>> started porting code on Cocoa, but it's still unfinished. All the
>> examples provided with fltk work, but Fluid does not build. I guess
>> we'll have to be patient.
>>
>> Also, the building scripts for csound will have to be changed, and
>> include Cocoa instead of Carbon.
>>
>> Alexis
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Victor Lazzarini wrote:

> I just looked at Macports and I don't think I can use it, it will just  
> mess up my packaging. Unfortunately, it's been problematic to get  
> libsndfile to build for more than one architecture. There is a gcc  
> option that cannnot be used with multiple architectures in the  
> Makefile and I can't get rid of it. I'll keep trying.

I consider Apple's fat binaries a flawed solution to a marketing
problem. Fortunately the idea of fat binaries has been pretty
firmly rejected by the Linux world (which supports way more than
just 4 arches anyway).

> 1. libsndfile: it builds and runs fine with ./configure using no
> options. Code built for x86_64 seems to link to it OK.
> However, ./configure reports  architecture as i386. So I am actually
> puzzled.

Its likely that the libsndfile binary you have built is broken in
some subtle way. Did you run the test suite?

Its actually the test suite that is the reason I think that fat binaries
are flawed. I have spent a lot of time and effort to build a comprehensive
test suite for libsndfile, but if you build a fat binary and run the
test suite, only one of the binaries in the fat binary gets tested and
there is no easy way to test the others (there may be more than one).

Back when Apple switched from PowerPC to Intel and foisted this
abomonation on the world I spent a considerable about of time trying
to debug a problem that I couldn't reproduce. In the end it turned out
to be due to building a fat binary on Intel and then having bugs in the
PowerPC part of the binary (that never occurred when compiling for
PowerPC natively) that was never validated by the test suite.

Until there is a way of running the test suite on all component
architectures of a fat binary, the only way to safely build a
libsndfile fat binary is as follows:

   for each architecture:
      ./configure && make && make check
   build fat binary from the tested architecture specifi components

Another part of the problem is that I get little or no feedback or
help from the community of users of libsndfile on Apple (and when I
do get it they expect me to jump through hoops to support their
platform or suggest I dump autotools etc). Instead of posting things
like this on the libsndfile mailing list I see it on Google alerts
and mailing lists for CSound, Supercollider, PD etc.

Sorry to whine about this, but the only platform I have easy access
to and motivation to work on is Linux and I get 100 times more support
from Linux users (bug reports, bug fixes, patches, etc) than I do
for all other platforms combined.

> If I configure with --build=x86_64, it then reports
> that architecture, but fails to build sndfile-play, because it says
> "Carbon.h" is missing. That makes a bit of sense, since apparently
> Carbon has been discontinued in that architecture.

So someone who knows about Apple's constantly changing APIs needs to
figure out how to fix this and send me a patch. In spite of my whining
I am actually very easy to work with as jpff can probably attest to.

> > I had no problem with building libsndfile version 1.0.21 as universal
> > using macports ("port install libsndfile +universal"). I remembered  

It is my understanding that the binary built in this manner is built
correctly as separate arch builds and then glued together into a fat
binary using lipo.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks for your comprehensive response. Things are clearer now. This  
is what happens

1. running ./configure in a 10.6 machine detects a i386 cpu, which is  
wrong. However, the
build is a x86_64 binary, successfully created because x86_64 is the  
default.

2. I tried to force the CPU to x86_64 by using --build=x86_64, but  
this fails because
configure gets confused and does not detect it is running in darwin.  
The Carbon.h problem is then due to the lack of
the relevant preprocessor flag.

3. On my 10.5 machine, I was able to build a x86_64 and ppc library  
files by passing CFLAGS="-arch x86_64" etc
to ./configure

4. I have now a  3-architecture fat binary, which I created with lipo.  
Unfortunately, I can't build ppc64 here, because configure can't run  
the produced binaries and thus fails.

5. I am quite happy with this, I can script it and it will be easy to  
build. I might use the same principle with other
dependencies.

If this all works, I will then attempt to build a fat binary for all  
csound binaries. This might be my salvation.

Victor


On 3 Jun 2010, at 23:53, Erik de Castro Lopo wrote:

> Victor Lazzarini wrote:
>
>> I just looked at Macports and I don't think I can use it, it will  
>> just
>> mess up my packaging. Unfortunately, it's been problematic to get
>> libsndfile to build for more than one architecture. There is a gcc
>> option that cannnot be used with multiple architectures in the
>> Makefile and I can't get rid of it. I'll keep trying.
>
> I consider Apple's fat binaries a flawed solution to a marketing
> problem. Fortunately the idea of fat binaries has been pretty
> firmly rejected by the Linux world (which supports way more than
> just 4 arches anyway).
>
>> 1. libsndfile: it builds and runs fine with ./configure using no
>> options. Code built for x86_64 seems to link to it OK.
>> However, ./configure reports  architecture as i386. So I am actually
>> puzzled.
>
> Its likely that the libsndfile binary you have built is broken in
> some subtle way. Did you run the test suite?
>
> Its actually the test suite that is the reason I think that fat  
> binaries
> are flawed. I have spent a lot of time and effort to build a  
> comprehensive
> test suite for libsndfile, but if you build a fat binary and run the
> test suite, only one of the binaries in the fat binary gets tested and
> there is no easy way to test the others (there may be more than one).
>
> Back when Apple switched from PowerPC to Intel and foisted this
> abomonation on the world I spent a considerable about of time trying
> to debug a problem that I couldn't reproduce. In the end it turned out
> to be due to building a fat binary on Intel and then having bugs in  
> the
> PowerPC part of the binary (that never occurred when compiling for
> PowerPC natively) that was never validated by the test suite.
>
> Until there is a way of running the test suite on all component
> architectures of a fat binary, the only way to safely build a
> libsndfile fat binary is as follows:
>
>   for each architecture:
>      ./configure && make && make check
>   build fat binary from the tested architecture specifi components
>
> Another part of the problem is that I get little or no feedback or
> help from the community of users of libsndfile on Apple (and when I
> do get it they expect me to jump through hoops to support their
> platform or suggest I dump autotools etc). Instead of posting things
> like this on the libsndfile mailing list I see it on Google alerts
> and mailing lists for CSound, Supercollider, PD etc.
>
> Sorry to whine about this, but the only platform I have easy access
> to and motivation to work on is Linux and I get 100 times more support
> from Linux users (bug reports, bug fixes, patches, etc) than I do
> for all other platforms combined.
>
>> If I configure with --build=x86_64, it then reports
>> that architecture, but fails to build sndfile-play, because it says
>> "Carbon.h" is missing. That makes a bit of sense, since apparently
>> Carbon has been discontinued in that architecture.
>
> So someone who knows about Apple's constantly changing APIs needs to
> figure out how to fix this and send me a patch. In spite of my whining
> I am actually very easy to work with as jpff can probably attest to.
>
>>> I had no problem with building libsndfile version 1.0.21 as  
>>> universal
>>> using macports ("port install libsndfile +universal"). I remembered
>
> It is my understanding that the binary built in this manner is built
> correctly as separate arch builds and then glued together into a fat
> binary using lipo.
>
> Erik
> -- 
> ----------------------------------------------------------------------
> Erik de Castro Lopo
> http://www.mega-nerd.com/
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Le 04/06/10 01:10, Victor Lazzarini a écrit :
> Thanks for your comprehensive response. Things are clearer now. This
> is what happens
>
> 1. running ./configure in a 10.6 machine detects a i386 cpu, which is
> wrong. However, the
> build is a x86_64 binary, successfully created because x86_64 is the
> default.
>
> 2. I tried to force the CPU to x86_64 by using --build=x86_64, but
> this fails because
> configure gets confused and does not detect it is running in darwin.
> The Carbon.h problem is then due to the lack of
> the relevant preprocessor flag.
>

There is another way to force it, with a command similar to:

$ CC="gcc -arch x86_64" CXX="g++ -arch x86_64" ./configure

... but depending on the configure script, it may be equivalent.

> 3. On my 10.5 machine, I was able to build a x86_64 and ppc library
> files by passing CFLAGS="-arch x86_64" etc
> to ./configure
>

Again, from my experience, this is most of time equivalent to what I 
previously suggested... but sometimes not, depending on gcc version, 
configure script, etc...

>>>> I had no problem with building libsndfile version 1.0.21 as
>>>> universal
>>>> using macports ("port install libsndfile +universal"). I remembered
>>
>> It is my understanding that the binary built in this manner is built
>> correctly as separate arch builds and then glued together into a fat
>> binary using lipo.

That's right, as far as I understood macports' behavior.

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Ok, that's the way to go. Same approach is working with fluidsynth. So  
I hope to get all the autotools-based dependencies done. Then I'll  
have to edit portmidi's makefile. Then fix SConstruct to build  
multiple architectures.

The major problem I will have on 10.6 is that portmidi is not  
reentrant. It is OK, somehow, with legacy dylib-loading code, but  is  
crashing Csound on multiple sequential instances on the same process  
when using dlopen(). That'll be a major headache.

Regards

Victor


On 4 Jun 2010, at 00:33, Alexis Baskind wrote:

> Le 04/06/10 01:10, Victor Lazzarini a écrit :
>> Thanks for your comprehensive response. Things are clearer now. This
>> is what happens
>>
>> 1. running ./configure in a 10.6 machine detects a i386 cpu, which is
>> wrong. However, the
>> build is a x86_64 binary, successfully created because x86_64 is the
>> default.
>>
>> 2. I tried to force the CPU to x86_64 by using --build=x86_64, but
>> this fails because
>> configure gets confused and does not detect it is running in darwin.
>> The Carbon.h problem is then due to the lack of
>> the relevant preprocessor flag.
>>
>
> There is another way to force it, with a command similar to:
>
> $ CC="gcc -arch x86_64" CXX="g++ -arch x86_64" ./configure
>
> ... but depending on the configure script, it may be equivalent.
>
>> 3. On my 10.5 machine, I was able to build a x86_64 and ppc library
>> files by passing CFLAGS="-arch x86_64" etc
>> to ./configure
>>
>
> Again, from my experience, this is most of time equivalent to what I
> previously suggested... but sometimes not, depending on gcc version,
> configure script, etc...
>
>>>>> I had no problem with building libsndfile version 1.0.21 as
>>>>> universal
>>>>> using macports ("port install libsndfile +universal"). I  
>>>>> remembered
>>>
>>> It is my understanding that the binary built in this manner is built
>>> correctly as separate arch builds and then glued together into a fat
>>> binary using lipo.
>
> That's right, as far as I understood macports' behavior.
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

That's great Victor. I think few people realise how many things needed
to be sorted in order to keep releasing updates. We'd be nowhere near
where we are without the help of all the developers.

Rory.


On 4 June 2010 00:41, Victor Lazzarini  wrote:
> Ok, that's the way to go. Same approach is working with fluidsynth. So
> I hope to get all the autotools-based dependencies done. Then I'll
> have to edit portmidi's makefile. Then fix SConstruct to build
> multiple architectures.
>
> The major problem I will have on 10.6 is that portmidi is not
> reentrant. It is OK, somehow, with legacy dylib-loading code, but  is
> crashing Csound on multiple sequential instances on the same process
> when using dlopen(). That'll be a major headache.
>
> Regards
>
> Victor
>
>
> On 4 Jun 2010, at 00:33, Alexis Baskind wrote:
>
>> Le 04/06/10 01:10, Victor Lazzarini a écrit :
>>> Thanks for your comprehensive response. Things are clearer now. This
>>> is what happens
>>>
>>> 1. running ./configure in a 10.6 machine detects a i386 cpu, which is
>>> wrong. However, the
>>> build is a x86_64 binary, successfully created because x86_64 is the
>>> default.
>>>
>>> 2. I tried to force the CPU to x86_64 by using --build=x86_64, but
>>> this fails because
>>> configure gets confused and does not detect it is running in darwin.
>>> The Carbon.h problem is then due to the lack of
>>> the relevant preprocessor flag.
>>>
>>
>> There is another way to force it, with a command similar to:
>>
>> $ CC="gcc -arch x86_64" CXX="g++ -arch x86_64" ./configure
>>
>> ... but depending on the configure script, it may be equivalent.
>>
>>> 3. On my 10.5 machine, I was able to build a x86_64 and ppc library
>>> files by passing CFLAGS="-arch x86_64" etc
>>> to ./configure
>>>
>>
>> Again, from my experience, this is most of time equivalent to what I
>> previously suggested... but sometimes not, depending on gcc version,
>> configure script, etc...
>>
>>>>>> I had no problem with building libsndfile version 1.0.21 as
>>>>>> universal
>>>>>> using macports ("port install libsndfile +universal"). I
>>>>>> remembered
>>>>
>>>> It is my understanding that the binary built in this manner is built
>>>> correctly as separate arch builds and then glued together into a fat
>>>> binary using lipo.
>>
>> That's right, as far as I understood macports' behavior.
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks. All dependencies done bar portmidi, which might take some  
time. FLTK only ppc and i386, that might cause a problem later, but  
we'll see.
1/2 way there towards a universal.

Victor
On 4 Jun 2010, at 00:44, Rory Walsh wrote:

> That's great Victor. I think few people realise how many things needed
> to be sorted in order to keep releasing updates. We'd be nowhere near
> where we are without the help of all the developers.
>
> Rory.
>
>
> On 4 June 2010 00:41, Victor Lazzarini   
> wrote:
>> Ok, that's the way to go. Same approach is working with fluidsynth.  
>> So
>> I hope to get all the autotools-based dependencies done. Then I'll
>> have to edit portmidi's makefile. Then fix SConstruct to build
>> multiple architectures.
>>
>> The major problem I will have on 10.6 is that portmidi is not
>> reentrant. It is OK, somehow, with legacy dylib-loading code, but  is
>> crashing Csound on multiple sequential instances on the same process
>> when using dlopen(). That'll be a major headache.
>>
>> Regards
>>
>> Victor
>>
>>
>> On 4 Jun 2010, at 00:33, Alexis Baskind wrote:
>>
>>> Le 04/06/10 01:10, Victor Lazzarini a écrit :
>>>> Thanks for your comprehensive response. Things are clearer now.  
>>>> This
>>>> is what happens
>>>>
>>>> 1. running ./configure in a 10.6 machine detects a i386 cpu,  
>>>> which is
>>>> wrong. However, the
>>>> build is a x86_64 binary, successfully created because x86_64 is  
>>>> the
>>>> default.
>>>>
>>>> 2. I tried to force the CPU to x86_64 by using --build=x86_64, but
>>>> this fails because
>>>> configure gets confused and does not detect it is running in  
>>>> darwin.
>>>> The Carbon.h problem is then due to the lack of
>>>> the relevant preprocessor flag.
>>>>
>>>
>>> There is another way to force it, with a command similar to:
>>>
>>> $ CC="gcc -arch x86_64" CXX="g++ -arch x86_64" ./configure
>>>
>>> ... but depending on the configure script, it may be equivalent.
>>>
>>>> 3. On my 10.5 machine, I was able to build a x86_64 and ppc library
>>>> files by passing CFLAGS="-arch x86_64" etc
>>>> to ./configure
>>>>
>>>
>>> Again, from my experience, this is most of time equivalent to what I
>>> previously suggested... but sometimes not, depending on gcc version,
>>> configure script, etc...
>>>
>>>>>>> I had no problem with building libsndfile version 1.0.21 as
>>>>>>> universal
>>>>>>> using macports ("port install libsndfile +universal"). I
>>>>>>> remembered
>>>>>
>>>>> It is my understanding that the binary built in this manner is  
>>>>> built
>>>>> correctly as separate arch builds and then glued together into a  
>>>>> fat
>>>>> binary using lipo.
>>>
>>> That's right, as far as I understood macports' behavior.
>>>
>>> ------------------------------------------------------------------------------
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net