I'll resend a patch following Jose's suggestion, probably on Sunday. There are just too many things happening before that.
Pierre > On 25 Mar 2016, at 00:36, Jose Fonseca <jfons...@vmware.com> wrote: > >> On 24/03/16 22:07, Ilia Mirkin wrote: >>> On Sat, Mar 19, 2016 at 6:30 PM, Jose Fonseca <jfons...@vmware.com> wrote: >>>> On 19/03/16 22:25, Ilia Mirkin wrote: >>>> >>>>> On Sat, Mar 19, 2016 at 6:23 PM, Jose Fonseca <jfons...@vmware.com> wrote: >>>>> >>>>>> On 18/03/16 04:00, Ilia Mirkin wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Mar 17, 2016 8:27 PM, "Matt Turner" <matts...@gmail.com >>>>>> <mailto:matts...@gmail.com>> wrote: >>>>>> > >>>>>> > On Thu, Mar 17, 2016 at 5:17 PM, Pierre Moreau >>>>>> <pierre.mor...@free.fr >>>>>> <mailto:pierre.mor...@free.fr>> wrote: >>>>>> > > This fixes a compile error while building Nouveau with C++11 >>>>>> enabled (and >>>>>> > > glibc >= 2.23). This happens if SWR is enabled, as it forces >>>>>> C++11. >>>>>> > >>>>>> > That seems bad, right? >>>>>> > >>>>>> > Enabling OpenSWR should affect how any other drivers are built. Why >>>>>> > does this happen? >>>>>> >>>>>> Yeah, the fix here is to fix the build not to add random unrelated >>>>>> options from one driver when building another. >>>>> >>>>> >>>>> >>>>> Although I agree in principle, that drivers should not interfere with >>>>> others >>>>> build, C++14 will soon be the default [1]. >>>>> >>>>> So, in this particular case, it seems a missed opportunity not to try to >>>>> fix >>>>> this generically. >>>>> >>>>> >>>>> What about adding to include/c99_math.h something like >>>>> >>>>> #if __cplusplus >= 201103L >>>>> using std::isinf; >>>>> #endif >>>> >>>> >>>> Why is isinf() becoming unavailable by the way? I don't think anyone's >>>> given a clear answer on that. At least I haven't heard one. >>> >>> >>> It's unavoidable. >>> >>> On C99 isinf is a macro. >>> >>> On C++11 isinf is an function inside std namespace. >>> >>> You can't have a macro inside a C++ namespace -- macros have no namespaces. >>> >>> So, even if you `#include <math.h>` instead of `#include <cmath>`, the >>> math.h must not `#define isinf` so that C-prepposeccor doesn't expan >>> `std::isinf` to invalid code. >> >> OK, so then we should drop this logic in whereever we define isinf >> (iirc there's a definition for some platform that doesn't have it) or >> in c99_math.h as Matt suggests. > > No, there's no isinf definition anywhere anymore. > > But as I said c99_math.h sounds a good place for it. > > Jose > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev