Bug#629861: closed by Sylvestre Ledru <sylvestre at debian.org> (Bug#629861: fixed in clang 2.9-4)

[Michael Wild]

On 06/14/2011 05:33 PM, Sylvestre Ledru wrote:
> Le mardi 14 juin 2011 à 15:45 +0200, Michael Wild a écrit :
>> On 06/14/2011 12:57 PM, Sylvestre Ledru wrote:
>>> Le mardi 14 juin 2011 à 08:20 +0200, Michael Wild a écrit :
>>>> On 06/13/2011 11:50 PM, Sylvestre Ledru wrote:
>>>>
>>>> I agree that the Linux code in ToolChains.cpp is horrible and
>>>> unmaintainable. On the Clang mailing list one of the devs also said that
>>>> he would prefer configuration files. Shelling out to ask gcc is also a
>>>> bad option. You have to be very careful that you ask it the right thing,
>>>> e.g. pass it the right -m32/-m64 flags on i386 and amd64, respectively,
>>>> and it gets more complicated on non-Intel architectures.
>>> You mean this ?
>>> gcc -print-file-name=crtbegin.o
>>> I am not sure to understand what is wrong.
>>>
>>
>> If I understood Anders' proposal, that would mean to invoke something like
>>
>> std::string loc;
>> // or -m32
>> FILE* f = popen("/usr/bin/gcc -m64 -print-file-name=crtbegin.o", "r");
>> if (f)
>> {
>>   {
>>     __gnu_cxx::stdio_filebuf<typename std::string::value_type>
>>       fb(f, std::ios_base::in, 1);
>>     std::istream is(&fb);
>>     std::getline(is, loc);
>>   }
>>   pclose(f);
>> }
>>
>> Personally, I don't like this kind of stuff, but then that's probably
>> also a matter of personal preference.
> I agree it is dirty but less than the current solution ...

Agreed, provided that the correct arguments are passed to gcc it is
presumably consistent with gcc.

[...]

>> Perhaps we could prod upstream to hurry and fix the situation and 
>> then backportthose changes to 2.9? IMHO the most "future-proof"
>> solution...

> ok
> Could you post this message or do you want me to do it ?

I think it would be good if you did, because you as the DD maintaining
clang-2.9 carry more weight.

> 
>> BTW: Do you patches also work on non-Intel architectures (e.g mips or arm)?
> No, I was waiting to see the results (and issues) with x86 & amd64.

Ok, I understand.

Michael