[llvm-commits] [llvm-gcc-4.2] r54702 - /llvm-gcc-4.2/trunk/gcc/Makefile.in

[Jim Grosbach]

I'm open to suggestions for alternatives; however, without this or  
equivalent, the build is fundamentally broken on Darwin.

The core issue is that on Darwin, we install a single dylib, even when  
building compilers for more than one architecture. Normally, that  
dylib will be build only for the target llvm-gcc is configured for  
(see the bits of Makefile.in above the change for reference). That  
would be fine, except that the Darwin build scripts (build_gcc) take  
things a step further; when multiple compilers have been built, only a  
single dylib is installed, which is then shared by all of the  
compilers. That is, the build script assumes that the dylib will have  
support for all targets. So long as the targets are x86 and ppc, this  
piece of the Makefile is what enforces that assumption. Forcing  
targets into the dylib like that is ugly to begin with. Adding ARM  
support is merely an extension of the solution already chosen.

There are a couple of alternatives, but they are more invasive and  
beyond the scope of what I'm looking for at the time being. We can  
move building the dylib containing the target bits into a separate  
project with its own build machinery. That seems overkill to me. We  
can modify the llvmCore build to create a dylib with the necessary  
bits. llvm-gcc just uses it and doesn't build a new dylib at all.  
Longer term, I like this option, but there may be caveats of which I'm  
unaware, so grain of salt and all that. Lastly, we can change the  
Darwin build script to install a dylib for each target compiler rather  
than a single dylib with symlinks for the other compilers.  
Architecturally, this is the most consistent with the rest of the gcc  
installation; however, it uses up more disk space than strictly  
necessary.

Note that all of this is solely for Darwin. None of it touches the  
build for anyone else.

-Jim

On Aug 15, 2008, at 12:01 AM, Evan Cheng wrote:

> Hi Jim,
>
> I don't think this is a good idea yet. Most people don't need llvm-gcc
> ARM support. Perhaps this should be something that's specified on the
> command line?
>
> I'll back this out for now. Thanks.
>
> Evan
>
> On Aug 12, 2008, at 2:13 PM, Jim Grosbach wrote:
>
>> Author: grosbach
>> Date: Tue Aug 12 16:13:55 2008
>> New Revision: 54702
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=54702&view=rev
>> Log:
>> LLVM dylib needs the ARM backend as well.
>>
>> Modified:
>>   llvm-gcc-4.2/trunk/gcc/Makefile.in
>>
>> Modified: llvm-gcc-4.2/trunk/gcc/Makefile.in
>> URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/Makefile.in?rev=54702&r1=54701&r2=54702&view=diff
>>
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> = 
>> =====================================================================
>> --- llvm-gcc-4.2/trunk/gcc/Makefile.in (original)
>> +++ llvm-gcc-4.2/trunk/gcc/Makefile.in Tue Aug 12 16:13:55 2008
>> @@ -1152,10 +1152,10 @@
>> $(error Unsuported LLVM Target $(target))
>> endif
>>
>> -# If in BUILD_LLVM_INTO_A_DYLIB mode, always link in the x86/ppc
>> backends.
>> +# If in BUILD_LLVM_INTO_A_DYLIB mode, always link in the x86/ppc/
>> arm backends.
>> # See below for more details.
>> ifdef BUILD_LLVM_INTO_A_DYLIB
>> -LLVMTARGETOBJ := $(sort $(LLVMTARGETOBJ) x86 powerpc)
>> +LLVMTARGETOBJ := $(sort $(LLVMTARGETOBJ) x86 powerpc arm)
>> endif
>>
>> # We use llvm-config to determine the libraries that we need to link
>> in our
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits