Xojo Developer Conference
25/27th April 2018 in Denver.
MBS Xojo Conference
6/7th September 2018 in Munich, Germany.

GCC 4.0 - Pre 10.3.9 support - what to do (Real Studio Plugins Mailinglist archive)

Back to the thread list
Previous thread: LittleEndian for MemoryBlock
Next thread: Business Graphics


macosx and unix paths   -   GOLD
  GCC 4.0 - Pre 10.3.9 support - what to do   -   Björn Eiríksson <b
   Re: GCC 4.0 - Pre 10.3.9 support - what to do   -   Alfred Van Hoek
    Re: GCC 4.0 - Pre 10.3.9 support - what to do   -   Björn Eiríksson <b
     Re: GCC 4.0 - Pre 10.3.9 support - what to do   -   Christian Schmitz
   Re: GCC 4.0 - Pre 10.3.9 support - what to do   -   Chris Little

GCC 4.0 - Pre 10.3.9 support - what to do
Date: 18.06.05 00:04 (Fri, 17 Jun 2005 23:04:30 +0000)
From: Björn Eiríksson <b
I am getting some complaints after making a switch to GCC 4.0 for
systems pre 10.3.9.

From looking it up then GCC 4.0 compilations don't work on systems
before 10.3.9.

Now looking a few months ahead then we are supposed to use GCC 4.0
since that will be the only way to make the
FAT Mach-O to support both PPC and Intel.

Now.....with this all in mind then how do we support systems before
10.3.9 ?

Or is there something in this equation that I am missing ?

Re: GCC 4.0 - Pre 10.3.9 support - what to do
Date: 18.06.05 02:41 (Fri, 17 Jun 2005 21:41:26 -0400)
From: Alfred Van Hoek
on 6/17/05 7:04 PM, Björn Eiríksson at <email address removed> wrote:

> I am getting some complaints after making a switch to GCC 4.0 for
> systems pre 10.3.9.
>
> From looking it up then GCC 4.0 compilations don't work on systems
> before 10.3.9.
>
> Now looking a few months ahead then we are supposed to use GCC 4.0
> since that will be the only way to make the
> FAT Mach-O to support both PPC and Intel.
>
> Now.....with this all in mind then how do we support systems before
> 10.3.9 ?
>
> Or is there something in this equation that I am missing ?
>

I still am running 10.3.9 with gcc 3.3. Before a quicktime upgrade (7.0) the
MachO was compiled against system SDK. After upgrading to QuickTime 7.0, a
hole bunch of compiler errors were generated against a macro defined in the
header files of the quicktime SDK. The only way was to fix it was to link
against the 10.3.x SDK which you can download from apple. Perhaps this is a
lead for you to utilize this macro which sound like **IS_NOT**, can't
remember it. My guess is that that compiler macro is the equation you are
missing,

best,

Alfred

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: GCC 4.0 - Pre 10.3.9 support - what to do
Date: 18.06.05 02:55 (Sat, 18 Jun 2005 01:55:59 +0000)
From: Björn Eiríksson <b

On 18.6.2005, at 01:41, Alfred Van Hoek wrote:

> on 6/17/05 7:04 PM, Björn Eiríksson at <email address removed> wrote:
>
>> I am getting some complaints after making a switch to GCC 4.0 for
>> systems pre 10.3.9.
>>
>> From looking it up then GCC 4.0 compilations don't work on systems
>> before 10.3.9.
>>
>> Now looking a few months ahead then we are supposed to use GCC 4.0
>> since that will be the only way to make the
>> FAT Mach-O to support both PPC and Intel.
>>
>> Now.....with this all in mind then how do we support systems before
>> 10.3.9 ?
>>
>> Or is there something in this equation that I am missing ?
>>
> I still am running 10.3.9 with gcc 3.3. Before a quicktime upgrade
> (7.0) the
> MachO was compiled against system SDK. After upgrading to QuickTime
> 7.0, a
> hole bunch of compiler errors were generated against a macro
> defined in the
> header files of the quicktime SDK. The only way was to fix it was
> to link
> against the 10.3.x SDK which you can download from apple. Perhaps
> this is a
> lead for you to utilize this macro which sound like **IS_NOT**, can't
> remember it. My guess is that that compiler macro is the equation
> you are
> missing,
>
> best,
>
> Alfred

I actually can compile with GCC 3.3 that is not problem. The problem
with GCC 3.3 is that it gives 2x larger code and will not be helpful
with Intel Migration. The only way to support the Intel migration is
to use GCC 4 but by doing so then you limit the product to 10.3.9 or
later, and this is the thing I am wondering about how to handle. It
seems harsh to limit users to 10.3.9 but yet it seems harsh to let
users miss out on all the optimizations and Intel possibilities when
they become available.

There are plenty of articles of this problem introduced in GCC 4, but
to me then REALbasic plugin is a different case than the other forums
deal with. Since there the users are faced with the question "Does my
app have to support 10.2" and Apple engineers seem to tell developers
to press all their 10.3 users to take free upgrade to 10.3.9. But in
case of a plugin then I cant take this decision as I am not making
the end user application and clearly some users can jump on the
10.3.9 wagon but others will not be able to.

What I am saying here is that the way Apple has set it up is that
there are now 2 Mach-O targets, one for those who want to support
future OS's and get optimizations and one for those who want to
support 10.3.8 and earlier.
--

Re: GCC 4.0 - Pre 10.3.9 support - what to do
Date: 18.06.05 17:54 (Sat, 18 Jun 2005 18:54:41 +0200)
From: Christian Schmitz
Björn Eiríksson <<email address removed>> wrote:

> I actually can compile with GCC 3.3 that is not problem. The problem
> with GCC 3.3 is that it gives 2x larger code and will not be helpful
> with Intel Migration.

There is something that you may not know.

You can compile using GCC4 for intel and with GCC3 for PPC and combine
both binaries to one universal binary.

You can even combine 32bit and 64bit code to one universal binary if you
want.

Mfg
Christian

--

Re: GCC 4.0 - Pre 10.3.9 support - what to do
Date: 18.06.05 02:42 (Fri, 17 Jun 2005 21:42:28 -0400)
From: Chris Little
on 6/17/05 7:04 PM, Björn Eiríksson at <email address removed> wrote:

> I am getting some complaints after making a switch to GCC 4.0 for
> systems pre 10.3.9.
>
> From looking it up then GCC 4.0 compilations don't work on systems
> before 10.3.9.
>
> Now looking a few months ahead then we are supposed to use GCC 4.0
> since that will be the only way to make the
> FAT Mach-O to support both PPC and Intel.
>
> Now.....with this all in mind then how do we support systems before
> 10.3.9 ?
>
> Or is there something in this equation that I am missing ?
>

I think the interesting question will be, can RB support plug-ins that are
universal binaries? On the Carbon-dev list Apple employees have stated that
the PPC part of the universal binary can be GCC 3.3 (or even built with
CodeWarrior) while the x86 part can be built with GCC 4.0.

>From Chris Espinosa of Apple:

> There's a sample project that does just this in my iDisk public folder, at
> cdespinosa.  It builds the SDKExample with one target for ppc 10.2.8 and later
> with gcc3,3, and for i386 for 10.4.1 and later with gcc4.  It uses the 10.4u
> SDK on both sides, but it uses #ifs on the AvailabilityMacros to be able to be
> built (at least on the ppc side) with any SDK from 10.2.8 up.

>From Eric Albert of Apple:

> And just to be completely clear here, universal binary support is merely
> about the Mach-O file format and doesn't have anything per se to do with
> the compiler. So if you'd like, you can build the PowerPC side of your
> application with CodeWarrior or xlc or even write type out the bytes one
> at a time in vi, then use lipo to merge the resulting PowerPC binary
> with an Intel binary built with gcc 4.0.
>
> Of course, the build-and-merge process is substantially easier if you
> build both sides in Xcode, and easier yet if you're using the same
> compiler and SDK version for both Intel and PowerPC. But you aren't
> tied to that.

Chris

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>