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

[Sylvestre Ledru]

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 ...

> >> 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...
ok
Could you post this message or do you want me to do it ?

> 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.

Sylvestre