Add new redhat triple

Cody Maloney cmaloney at tagged.com
Tue Jan 14 16:34:45 PST 2014


On Mon, Jan 13, 2014 at 9:46 AM, Rafael EspĂ­ndola
<rafael.espindola at gmail.com> wrote:
>> Not an official package.
>>
>> But current RedHat and CentOS call their host x86_64-redhat-linux-gnu,
>> and that's where, from what I can find, the triple got embedded into
>> GCC from.
>>
>> There also isn't an official binary package of gcc 4.8 I can get at
>> from RedHat or CentOS which would answer what their official will ones
>> do.
>
> Can you check their spec files to see if they pass an explicit triple.
> It is quiet surprising that RHEL and Fedora would use different
> triples.

They do pass an explicit triple. It is x86_64-redhat-linux (in the
case where everything is hooked up correctly on the platform). The
triple x86_64-redhat-linux-gnu is in the default macro set (on CentOS
official package), although it should not be hit generally since the
platform-specific set of macros sets it to the right macro. How it
managed to not hit that is definitely a setup specific bug/problem
which I'm tracking down. So it's unlikely others will hit this same
triple in practice.

>>> So your idea is to do a directory listing and check which entries
>>> "look like" triples? I could probably be made to work. Chandler, what
>>> do you think?
>>
>> Yep, list the directory for things that look like triples, parse out
>> the relevant facts from those triples (architecture, kernel,
>> distribution, etc.) where clang cares, then pick the best one.
>
> It seems like a reasonable idea to me. Are you interested in coding
> such a patch? It should make the Driver a bit faster and easier to
> maintain (and add support for your setup).

I'm interested in coding it, but probably won't have time for that
large of a patch + test expansion for a while (And the just add the
triple patch works well enough for business needs). It looks like
Clang/LLVM has a cross-platform directory iterator that should make it
fairly straightforward. The change opens up more potential for oddness
/ people depending on broken things, and it looks like there is a
certain amount of non-tested platform specific behavior ATM which
should probably be decided if it needs to have a test added and be a
maintained or if the behavior is okay to change in those cases.

Not a speed win guarantee (Depends how long parsing logic takes
although it is a trivial tokenization, as well as how many we're
parsing/sorting, and what the structure of the code is). Definitely
should be more maintainable though (And where relevant make it
possible to just use other checks to get out what the host platform
is, such as /etc/os-release and friends).

Cody




More information about the cfe-commits mailing list