[PATCH]: enable multilib build on x86_64-apple-darwin

Current llvm-gcc-4.2 for trunk and the 2.6 release
is unable to build the i386 multilib for the
x86_64-apple-darwin target. The attached patch provides
this support. Can we get this into the 2.6 release
and trunk?
           Jack

darwin64_multilib.diff (574 Bytes)

doesn't --target=x86_64-apple-darwin imply you don't want multi-libs, and an x86_64-only compiler?

Shantonu

Why would you say that? On FSF gcc it is normal to have
the i386 multilib on x86_64 targets. I had that added for
gcc 4.4 on x86_64-apple-darwin...

http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01515.html
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01522.html

Shantonu,
   To clarify, the reason for the i386 multilib on
x86_64-apple-darwin is to enable users of the
x86_64-apple-darwin target to also compile i386
code in gfortran for example. Otherwise they have
to build the i686-apple-darwin target and keep to
seperate compilers around. I will admit this feature
is perhaps more useful on FSF gcc 4.4 where we have
the new -static-libgfortran flag allows for building
semi-static binaries (linked against libgfortran.a)
on darwin...

http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00850.html

Perhaps I should port that change to llvm-gcc-4.2 as
well?
             Jack

This is fine. I don't have a rw llvm-gcc tree, some else want to check it in? For 2.6, that's be someone else's call, for what it's worth, this should be fairly safe.

I applied this as r80071. However, I don't understand what this does. I'm able to build a working i386/x86-64 compiler on darwin without this, what exactly does this fix? What exactly is an "i386 multilib" and why do we care? :slight_smile:

-Chris

If you build a native 64-bit darwin compiler (host/target are x86_64-darwin) this will give you a -m32 multilib that will enable you to target i386. Otherwise you have to build a 32-bit compiler that has a 64-bit multilib.

-eric

Any chance that we could get r80071 applied to llvm-gcc-2.4 2.6
branch in about a week? As Mike said this change should be
very safe.
             Jack

Any chance that we could get r80071 applied to llvm-gcc-2.4 2.6
branch in about a week? As Mike said this change should be
very safe.

Yes, I'll ask Tanya to pull it into the release.

-Chris

Chris,
    Thanks. I am going to update the fink llvm and llvm-gcc42
packages I maintain to the 2.6 release so this will help. Is
clang updated in unison with llvm/llvm-gcc-4.2 and is there
much new that isn't in Xcode 3.2's clang? I was considering
creating clang packaging for fink as well (if the releases
were coordinated and the c++ support was decent yet).
              Jack

The releases are coordinated, however, if you want c++, there is little point in packaging up a clang just yet. For C and Objective-C, it would be reasonable.

Xcode 3.2's clang is exactly http://llvm.org/svn/llvm-project/cfe/tags/Apple/clang-23.

This is really old by open source standards, 2.6 is substantially more up-to-date. Clang C++ support is still too early to use, though it is making amazing progress!

-Chris