We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

So this is fun. The configure script does this:

# test to see if "-g" is supported...
ac_test_CFLAGS=${CFLAGS+set}
ac_save_CFLAGS=$CFLAGS
CFLAGS="-g"
# build dummy program here to see if compiler dies...

The problem is that running gcc-3.3 on an Intel Mac will die here unless you have -arch ppc in the CFLAGS:

The error is this:
  gcc-3.3: installation problem, cannot exec `cc1': No such file or directory

On a PowerPC Mac, where -arch will default to ppc, you don't get this problem.

Is there some way to force the configure script to always use some CFLAGS? Maybe set CC to some wrapper script?

--ryan.

Try it now, I've moved the -arch into the CC variable.

Huh, I can't believe that works.  :)

Configure is making progress now...

--ryan.

(In reply to comment #3)
> Huh, I can't believe that works.  :)

Heheh, stupid scripting tricks. :)

Okay, I think I have this all working now.

We're hitting some funkiness because we're writing SDL_config.h to SDL/build/ppc/include, so the builds are using the default SDL_config.h, which has a __MACOSX__ path...which appears to mostly work, but we blow up in here:

 gcc-3.3 -arch ppc -DMAC_OS_X_VERSION_MIN_REQUIRED=1020 -nostdinc -F/Developer/SDKs/MacOSX10.2.8.sdk/System/Library/Frameworks -I/Developer/SDKs/MacOSX10.2.8.sdk/usr/include/gcc/darwin/3.3 -isystem /Developer/SDKs/MacOSX10.2.8.sdk/usr/include -Iinclude -I../../include -D_GNU_SOURCE=1 -I/usr/local/include -DTARGET_API_MAC_CARBON -DTARGET_API_MAC_OSX -I/usr/X11R6/include -DXTHREADS -D_THREAD_SAFE -faltivec -force_cpusubtype_ALL -fpascal-strings -c ../../src/video/Xext/Xxf86dga/XF86DGA.c  -fno-common -DPIC -o build/.libs/XF86DGA.o
In file included from ../../src/video/Xext/extensions/extutil.h:39,
                 from ../../src/video/Xext/Xxf86dga/XF86DGA.c:66:
../../include/SDL_stdinc.h:165:22: alloca.h: No such file or directory


...there's no alloca.h in the 10.2.8 SDK (but there is in 10.4u.sdk). I guess we should strive to make SDL_config_macosx.h work for these universal builds and ignore the configure-generated header, since it'll have to work on both targets once we merge the two architectures.

I checked in a few changes:

- A change to define CXX in fatbuild, which comforts the configure script a little even if we don't use C++ anywhere.
- Some code to see how many CPU cores exist and parallelize make across them.
- CFLAGS that apply to both archs are specified seperately (-O3, -pipe, etc)
- -fvisibility=hidden for the gcc4 builds
- a "clean", "clean-ppc" and "clean-x86" command
- Fix to SDL_config_macosx.h for the HAVE_ALLOCA_H thing.

Take a look at svn revision #2237 and see if you want to tweak it at all. Tossing this bug to Sam...flag it RESOLVED FIXED if these changes are cool.

--ryan.

(In reply to comment #5)
> Okay, I think I have this all working now.
> 
> We're hitting some funkiness because we're writing SDL_config.h to
> SDL/build/ppc/include, so the builds are using the default SDL_config.h, which
> has a __MACOSX__ path...which appears to mostly work, but we blow up in here:
> 
>  gcc-3.3 -arch ppc -DMAC_OS_X_VERSION_MIN_REQUIRED=1020 -nostdinc
> -F/Developer/SDKs/MacOSX10.2.8.sdk/System/Library/Frameworks
> -I/Developer/SDKs/MacOSX10.2.8.sdk/usr/include/gcc/darwin/3.3 -isystem
> /Developer/SDKs/MacOSX10.2.8.sdk/usr/include -Iinclude -I../../include
> -D_GNU_SOURCE=1 -I/usr/local/include -DTARGET_API_MAC_CARBON
> -DTARGET_API_MAC_OSX -I/usr/X11R6/include -DXTHREADS -D_THREAD_SAFE -faltivec
> -force_cpusubtype_ALL -fpascal-strings -c
> ../../src/video/Xext/Xxf86dga/XF86DGA.c  -fno-common -DPIC -o
> build/.libs/XF86DGA.o
> In file included from ../../src/video/Xext/extensions/extutil.h:39,
>                  from ../../src/video/Xext/Xxf86dga/XF86DGA.c:66:
> ../../include/SDL_stdinc.h:165:22: alloca.h: No such file or directory

I think the change that you made is a good one for the Xcode stuff, but I'm not sure
why it was necessary.  Presumeably the ppc build is using the right one, since we do
a cd to the ppc/build directory before building (right?) and the include path specifies
the current directory include before the SDL root include...

> - A change to define CXX in fatbuild, which comforts the configure script a
> little even if we don't use C++ anywhere.

I didn't notice any problems, what did this take care of?

> - Some code to see how many CPU cores exist and parallelize make across them.

BTW, when setting up parallel make, I usually use # cpus + 1, so a compile is running while disk access is going for another.

> - -fvisibility=hidden for the gcc4 builds

This should have been picked up in the separate configure for x86... why didn't it?

> why it was necessary.  Presumeably the ppc build is using the right one, 
> since we do a cd to the ppc/build directory before building (right?) and the
> include path specifies the current directory include before the SDL root 
> include...

Maybe it should, but it definitely picked up the wrong SDL_config.h ... I threw in an #error line just to make sure.

It's actually better if it works with the Xcode config.h, since the Universal lib will need to work with one header when installed.

> > - A change to define CXX in fatbuild, which comforts the configure script a
> > little even if we don't use C++ anywhere.
> 
> I didn't notice any problems, what did this take care of?

Without it, it picks up /usr/bin/g++ as the C++ compiler...which is fine, since we don't ever compile any c++ code, but if we ever did, it could build some bits of the library with g++4 and the rest with gcc3. Just future proofing here.
 
> BTW, when setting up parallel make, I usually use # cpus + 1, so a compile is
> running while disk access is going for another.

My experience is that this works well on Linux, but is actually slower on PowerPC Mac OS X...not sure if that's an architecture issue or a scheduler issue, though, and haven't tried it on Intel Mac OS X.
 
> > - -fvisibility=hidden for the gcc4 builds
> 
> This should have been picked up in the separate configure for x86... why 
> didn't it?

No idea. Feel free to ssh to the Intel Mac if you want to play. Maybe the configure script sees that we defined CFLAGS and doesn't change it? (which would be a bug I introduced, if that's true.)

--ryan.

Okay, I got everything sorted out, thanks!  This is fixed in commit #2238

Good point about future proofing C++ stuff, I'm putting that back in.

(In reply to comment #7)
> > BTW, when setting up parallel make, I usually use # cpus + 1, so a compile is
> > running while disk access is going for another.
> My experience is that this works well on Linux, but is actually slower on
> PowerPC Mac OS X...not sure if that's an architecture issue or a scheduler
> issue, though, and haven't tried it on Intel Mac OS X.

Okay, I'm reverting this change, too.  Thanks!