[PATCH] Introduce the idea of a minimum libc version
Saleem Abdulrasool
compnerd at compnerd.org
Sat Feb 14 19:38:59 PST 2015
On Sat, Feb 14, 2015 at 1:57 PM, David Majnemer <david.majnemer at gmail.com>
wrote:
>
>
> On Sat, Feb 14, 2015 at 12:42 PM, Saleem Abdulrasool <
> compnerd at compnerd.org> wrote:
>
>> On Sat, Feb 14, 2015 at 12:17 PM, David Majnemer <
>> david.majnemer at gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, Feb 14, 2015 at 11:54 AM, İsmail Dönmez <ismail at donmez.ws>
>>> wrote:
>>>
>>>> On Sat, Feb 14, 2015 at 9:20 PM, David Majnemer
>>>> <david.majnemer at gmail.com> 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
>>>> cfe-commits at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>>
>>>
>>>
>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>
>>
>> --
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>>
>
>
--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150214/5a17b95e/attachment.html>
More information about the cfe-commits
mailing list