On Sat, Feb 14, 2015 at 1:57 PM, David Majnemer <[email protected]> wrote:
> > > On Sat, Feb 14, 2015 at 12:42 PM, Saleem Abdulrasool < > [email protected]> wrote: > >> On Sat, Feb 14, 2015 at 12:17 PM, David Majnemer < >> [email protected]> wrote: >> >>> >>> >>> On Sat, Feb 14, 2015 at 11:54 AM, İsmail Dönmez <[email protected]> >>> wrote: >>> >>>> On Sat, Feb 14, 2015 at 9:20 PM, David Majnemer >>>> <[email protected]> wrote: >>>> > Er, I don't see how "libc version" is a meaningful thing on linux. >>>> The presumption of which libc implementation is not baked into the triple. >>>> > >>>> >>>> This makes sense on Linux too. See >>>> >>>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131223/199910.html >>>> where this kind of information would be useful. >>>> >>> >>> Again, I don't see how we can assume linux == glibc. I'm pretty sure >>> r198093 is conservatively correct but not precisely correct. >>> >> >> The GNU part of the triple tells you that you are using {,e}glibc. Most >> linux distros/builds will use an alternative environment if they are using >> uclibc (traditionally, uclibc). So: >> >> *-linux-gnu*: {,e}glibc >> *-linux-uclibc*: uclibc >> *-linux-*: no libc >> *-android: bionic >> >> Yes, triples are a mess, but that is the world we live in. >> > > My doubt stems from stuff like: > $ musl-gcc -v |& grep Target > Target: x86_64-linux-gnu > > Are the musl people in the wrong for using the 'x86_64-linux-gnu' > moniker? Is there a description anywhere on the net of what 'gnu' in that > position actually means? > IMO, yes, they are at fault for using that. Unless they wish to be treated as if they are glibc (along with bug-for-bug compatibility) they should be using a separate environment as uclibc does. > >> That said, this is generic infrastructure, so, the specifics of Linux >> aren't really applicable to this change IMO. >> > > This flag is redundant for Darwin targets and MS targets already have a > version flag. > > The MS version flag is for MSVC compatibility not for the MSVCRT version being targeted (and they can diverge). My original idea was to key the Windows behavior off of the MSCompatibilityVersion, but, Reid was strongly in favor of this approach (which I had wanted anyways for Linux for examples like Ismail pointed out). > >> >>> >>>> >>>> ismail >>>> _______________________________________________ >>>> cfe-commits mailing list >>>> [email protected] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >>>> >>> >>> >>> _______________________________________________ >>> cfe-commits mailing list >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >>> >> >> -- >> Saleem Abdulrasool >> compnerd (at) compnerd (dot) org >> > > -- Saleem Abdulrasool compnerd (at) compnerd (dot) org
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
