• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
gcc frontend bug when compiling fat/universal?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gcc frontend bug when compiling fat/universal?


  • Subject: gcc frontend bug when compiling fat/universal?
  • From: Roland Schwingel <email@hidden>
  • Date: Wed, 8 Feb 2006 17:04:42 +0100


Hi...

At present I am facing a strange "bug" with the gcc-suite when compiling a little C program. I am hoping I
am here at the right adress to mail this issue if not please don't bother to redirect me!

I want to  generate a static lib which is later linked to an executable. Everything works fine when not creating
fat/universal binaries (in the last stage)... Lets go thru quick receipe to get it reproduceable in the shell:

I am running Xcode 2.2.1 on macosx 10.4.4 (intel):

1. Imagine a little hello world c source file.
$ cat hello.c
#include <stdio.h>

int main(int argc,char **argv)
{
        printf ("Hello world\n");
        return 0;
}

2. Compile it to a (fat) .o file:
$ gcc -arch i386 -arch ppc hello.c -c -o hello.o

3. Fine so far. Generate a static (fat) lib out of it using libtool
$ libtool -static -o libhello.a hello.o

4. It is fat lib now... Use lipo to prove it.
$ lipo -info libhello.a
Architectures in the fat file: libhello.a are: i386 ppc

5. Try to link it as executable (i386 only first: to see what gcc is doing):
$ gcc -v -arch i386 -L. -lhello -o hello
Using built-in specs.
Target: i686-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5250.obj~12/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5250)
 /usr/libexec/gcc/i686-apple-darwin8/4.0.1/collect2 -dynamic -arch i386 -weak_reference_mismatches non-weak -o hello -lcrt1.o /usr/lib/gcc/i686-apple-darwin8/4.0.1/crt2.o -L. -L/usr/lib/gcc/i686-apple-darwin8/4.0.1 -L/usr/lib/gcc/i686-apple-darwin8/4.0.1 -L/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../.. -lhello -lgcc -lSystem

6. Fine so far (when linking to ppc this works as well). Try to get an universal binary now, but remove i386 hello before.
$ rm hello
$ gcc -v -arch i386 -arch ppc -L. -lhello -o hello

Nothing happens!! NO file is produced no linking is started!!
I asume a problem in the gcc frontend when parsing the parameters... Is this bug already known? Anything in sight that this will be fixed?

Thanks in advance for your help,

Roland

PS: This example is a simplified breakdown of a bigger scenario, just in case you wonder why I do not compile it directly into an executable (which would work in this case).
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: gcc frontend bug when compiling fat/universal?
      • From: Eric Albert <email@hidden>
  • Prev by Date: Re: Asynchronous Unit testing
  • Next by Date: Re: Asynchronous Unit testing
  • Previous by thread: Re: Asynchronous Unit testing -- solved
  • Next by thread: Re: gcc frontend bug when compiling fat/universal?
  • Index(es):
    • Date
    • Thread