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

[Michael Wild]

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.

>> Since the Clang devs are unlikely to fix 2.9, why not make a patch which
>> does away with that whole charade of distro-detection and replace it
>> with a purely Debian-specific implementation? Here the things I think it
>> would need to do:
>>
>> - Detect the target gcc-triplet. This can be inferred from the second
>> argument of the Linux::Linux(const HostInfo&, const llvm::Triple&
>> Triple) constructor. Perhaps LinuxHostInfo::CreateToolChain() could get
>> some tweaking too, in order to produce the right triplet upfront (e.g.
>> i486 instead of i368 on Debian).
>>
>> - Detect the multiarch-triplet. Similarly to the GCC multiarch patch,
>> this can be looked up from a table. Essentially that table would map the
>> gcc-triplet to the corresponding multiarch-triplet (e.g. i486-linux-gnu
>> to i386-linux-gnu and x86_64-linux-gnu to x86_64-linux-gnu).
>>
>> - Set up the search paths.
>>
>> Did I miss something here?
> I didn't follow the multiarch "migration" but are there other changes
> which might happen ?
> Otherwise, I am happy with your suggestion. Are you willing to do it ?

That's what I don't know. Is it done now? Also, if such a patch were
worked out, that would only solve the problem for 2.9, but what will
upstream do to fix the situation in upcoming releases? At the moment I
don't think I can spare the time to work on this, I'm sorry. Perhaps we
could prod upstream to hurry and fix the situation and then backport
those changes to 2.9? IMHO the most "future-proof" solution...

BTW: Do you patches also work on non-Intel architectures (e.g mips or arm)?

Michael