From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-musl+bounces-142-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	by finch.gentoo.org (Postfix) with ESMTP id D6DB91382C5
	for <garchives@archives.gentoo.org>; Wed, 22 Jun 2016 14:02:51 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 04944E099C;
	Wed, 22 Jun 2016 14:02:48 +0000 (UTC)
Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by pigeon.gentoo.org (Postfix) with ESMTPS id 835C2E099C
	for <gentoo-musl@lists.gentoo.org>; Wed, 22 Jun 2016 14:02:47 +0000 (UTC)
Received: by mail-oi0-f48.google.com with SMTP id s66so23208489oif.1
        for <gentoo-musl@lists.gentoo.org>; Wed, 22 Jun 2016 07:02:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc;
        bh=Q0aKS+UCZqSMRd/0abBDW9teoUt/pZFLqxWq9ScLhps=;
        b=clwsUrYX3IHg+IFSHGws8dp4BwekxY4Ycr56Qfrp1mnZkc7AB8GqTIybwzdeNSlys7
         oXg1yP8hPoRMZE528J1qV87kH3HktvF7NJpUpgPrnJvChbJbWNjP0S7pTN6y2sAMkaYE
         ajWPtbAnvXP6tuexSN3JljvKuwWrUdMaP5E2CPRN95BNBG33UAv4MHA7DH+yquhZ5zUz
         nhCgbvaI+M3zWYMzWl6+1mn1kGqSbcrT5AX27zrk+fqPqmM1gy5qFvDr9xHnpGjKgrS3
         8taYUeg3gaxsMuyt7k4uSd9bVFAaInfGxgfEmLa6KMdAhUPkY1ZkfICpouRv+ymGWQ3R
         qsiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:from:date
         :message-id:subject:to:cc;
        bh=Q0aKS+UCZqSMRd/0abBDW9teoUt/pZFLqxWq9ScLhps=;
        b=dR+DtbLt4LgMgqwA6Ffzkhhy7LDcEJ5g6CydeDyqVVvPC6FKVZNKQdP3VXyIrqx05w
         wGiKbQUK8jCBnEGrXqiCfXrb2nwG0O1Ox4wof3eWkfl5VLnKTM2C9Sp/ZkIg2mlVXY8h
         N2K5VwgDxKOYmjYVKple1yN5bCr6Xh0b3CwFqm8XN+CuECq62L3pT8l1t36aLL9X9r7a
         sygnNdIP2GI6JSa/tnQM4rN9DLqA8uA20jl6+nvUDw2+Vtp7NZ6lED2WMIXzPAIxfqkK
         PFOShOyNiS4CRF5HmzTLrzNntz7k1Nunh+e7DvAJ4T53cZakiJA/aPzvnq3wRaGoFpR7
         JrIA==
X-Gm-Message-State: ALyK8tLA3DGCQhnkYuzcAtHq+KYIt03Ow+A8qF8OCCQj+1eTGFDCreGDvh9Qk6mZqUop+n78zAtWVuQKprDbYA==
X-Received: by 10.157.49.125 with SMTP id v58mr2011241otd.97.1466604166503;
 Wed, 22 Jun 2016 07:02:46 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-musl@lists.gentoo.org>
List-Help: <mailto:gentoo-musl+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-musl+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-musl+subscribe@lists.gentoo.org>
List-Id: Gentoo musl list <gentoo-musl.gentoo.org>
X-BeenThere: gentoo-musl@gentoo.org
X-BeenThere: gentoo-musl@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.202.63.212 with HTTP; Wed, 22 Jun 2016 07:02:45 -0700 (PDT)
In-Reply-To: <CAOYuCc042U7f7Sz=8-tKTbzxfL8Q2_aqS2Z-ypLDyiurRDZ6=g@mail.gmail.com>
References: <CAOYuCc2iavSmy2Pqy5pv8TOxguSYNMPk7wZCG10_9QghfK6TSA@mail.gmail.com>
 <4228046b-02f1-1b65-f56d-6e79347e4390@gentoo.org> <CAOYuCc2b2v2wBLGjBzkGRNdKe1gV8uSqnCLFxnxyodZuQ9Ym5g@mail.gmail.com>
 <20302d1d-92ff-1c4b-8939-08894c3589ca@gentoo.org> <CAOYuCc1JqdQg3eshzPvTYjo-8jHP0Z_NW+e6P2G2OT5gyQGW1w@mail.gmail.com>
 <8e7cafd9-97c7-6ca1-ad3f-95bdb0060ce0@gentoo.org> <CAOYuCc1_-vV3pXmsxmuC+9y2TDTGdi3S7NU=mAJ3SkU4z2Y_Aw@mail.gmail.com>
 <e1f362ee-7755-9a54-78e3-19e0733ebd3b@gentoo.org> <CAOYuCc3ZyA0SS1EUpVMGYmNrTUSX3k69d4Jz7dz2iYW1fQkF_A@mail.gmail.com>
 <19f9f66f-5dd4-786a-3b29-0a57c407548e@gentoo.org> <CAOYuCc3Q69t-iLG837Virh4iOjZpsTHa6g_B3+9_UaqwFC-vOw@mail.gmail.com>
 <1c93fa87-e2c3-2737-1222-ae93003e21ad@gentoo.org> <CAOYuCc0xybwO5ABAkJM3RX0nd-w=p1naO4j6MUv-=zXiRsK_iw@mail.gmail.com>
 <7d6fa9d6-1134-1d2a-1d06-33029b82429d@gentoo.org> <CAOYuCc1UZO5kvO8Nr_VDHSMTUd_LYkJ60Z-aAVt-24415B35DQ@mail.gmail.com>
 <CAOYuCc0RfPW1Zpvm+datU5oU9KYLcZhW2vovcMRA1570F2ea1g@mail.gmail.com>
 <37117cc0-2af1-306d-6ec5-d8d37d8c588c@gentoo.org> <CAOYuCc3EPZcw6xy_gbcuTEsgyjn=ttBqmwKjtW-qrNmYw91usA@mail.gmail.com>
 <CAOYuCc2=r33iGem2Ugqst27wT9CH68zUVTP50zgjpq3_1v5cDw@mail.gmail.com> <CAOYuCc042U7f7Sz=8-tKTbzxfL8Q2_aqS2Z-ypLDyiurRDZ6=g@mail.gmail.com>
From: Lei Zhang <zhanglei.april@gmail.com>
Date: Wed, 22 Jun 2016 22:02:45 +0800
Message-ID: <CAOYuCc3ZvVF9EnNTr_sCdj1zqaZ6cFYHumuNfzHF6Qda35UL2w@mail.gmail.com>
Subject: Re: [gentoo-musl] [GSoC] _GNU_SOURCE in C++
To: Luca Barbato <lu_zero@gentoo.org>
Cc: gentoo-musl@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
X-Archives-Salt: 9838a004-5afd-4632-9184-93f60a7b35c1
X-Archives-Hash: 7ef1e6d8abe444edd7f25702b0c7442e

2016-06-22 21:54 GMT+08:00 Lei Zhang <zhanglei.april@gmail.com>:
> 2016-06-21 12:54 GMT+08:00 Lei Zhang <zhanglei.april@gmail.com>:
>> 2016-06-17 20:44 GMT+08:00 Lei Zhang <zhanglei.april@gmail.com>:
>>> After putting about eight "#define _GNU_SOURCE"s in various *.cpp
>>> files, it seems to work now :)
>>
>> I was wrong; it doesn't work... I still can't figure out a good solution :(
>>
>> Take glibc's strtoll_l for example: it's hidden by _GNU_SOURCE in
>> stdlib.h and used exclusively by libc++'s header <locale>; but
>> defining _GNU_SOURCE in <locale> could be too late, since stdlib.h
>> might be included prior to <locale>.
>>
>> Though glibc's stdlib.h is only explicitly included in <cstdlib>,
>> defining _GNU_SOURCE in <cstdlib> doesn't work either. It turns out
>> strtoll_l (and others) is not directly protected by _GNU_SOURCE, but
>> by __USE_GNU, which is in turn defined in features.h according to
>> _GNU_SOURCE. That means "#define _GNU_SOURCE" must appear before the
>> inclusion of features.h, and it's not very clear where "#undef
>> _GNU_SOURCE" should be put.
>>
>> Any suggestions?
>
> So far the only feasible solution I can think of is to wrap every
> inclusion of C headers in libc++ with a pair of "#define _GNU_SOURCE"
> and "#undef _GNU_SOURCE", thus making sure _GNU_SOURCE is defined
> before any implicitly inclusion of features.h. It is cumbersome, but
> works. I haven't really figured out if this solution is 100%
> error-proof.

As an after-thought, I don't this justifies as a *real* solution, as
it still exposes nearly all the hidden symbols to user program; it
just enables us to compile LLVM against musl...


Lei