Fwd: FreeBSD Port: www/chromium

105 views
Skip to first unread message

Evan Martin

unread,
Jul 19, 2013, 2:23:13 PM7/19/13
to clang
Is this just due to them using an old version of Clang?

---------- Forwarded message ----------
From: Mike Jakubik <mike.j...@intertainservices.com>
Date: Fri, Jul 19, 2013 at 10:43 AM
Subject: FreeBSD Port: www/chromium
To: chro...@freebsd.org, po...@freebsd.org


Hello,

Latest Chromium does not seem to compile with Clang 3.3.

CXX(target) out/Release/obj.target/v8_base.x64/v8/src/string-search.o
CXX(target) out/Release/obj.target/v8_base.x64/v8/src/string-stream.o
CXX(target) out/Release/obj.target/v8_base.x64/v8/src/strtod.o
CXX(target) out/Release/obj.target/v8_base.x64/v8/src/stub-cache.o
v8/src/stub-cache.cc:1479:33: error: reinterpret_cast from 'nullptr_t'
to 'char *' is not allowed
: GetCodeWithFlags(flags, reinterpret_cast<char*>(NULL));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
gmake: *** [out/Release/obj.target/v8_base.x64/v8/src/stub-cache.o] Error 1
*** [do-build] Error code 1

Stop in /usr/ports/www/chromium.

Thanks.
_______________________________________________
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-chromium
To unsubscribe, send any mail to "freebsd-chromi...@freebsd.org"

Nico Weber

unread,
Jul 19, 2013, 2:26:54 PM7/19/13
to Evan Martin, clang

I'd guess they're not setting clang=1 in their GYP_DEFINES and are hence not picking up the right cflags (most notably, they probably aren't picking up -std=gnu++11, which we use on our clang builds).

Evan Martin

unread,
Jul 19, 2013, 3:11:32 PM7/19/13
to Nico Weber, clang
The thread continues here:
http://lists.freebsd.org/pipermail/freebsd-chromium/2013-July/000855.html

Seems to maybe be a FreeBSD-specific #define of NULL (!)
http://svnweb.freebsd.org/base?view=revision&revision=228918

Nico Weber

unread,
Jul 19, 2013, 3:21:55 PM7/19/13
to Evan Martin, clang
On Fri, Jul 19, 2013 at 12:11 PM, Evan Martin <ev...@chromium.org> wrote:
Huh, interesting! The patch looks like this over and over:

-    : CMap::Builder(reinterpret_cast<ReadableFontData*>(NULL),
+    : CMap::Builder(static_cast<ReadableFontData*>(0),

Using a static_cast instead of a reinterpret_cast sounds reasonable, but shouldn't nullptr_t be static_cast<>able to a pointer type? This seems to work:

$ cat test.cc
#include <iostream>
using namespace std;

class ReadableFontData {};

void f(ReadableFontData* p) {}

void g() { f(static_cast<ReadableFontData*>(nullptr)); }
$ clang -c test.cc -std=c++11 
$

(Why is there a cast at all? Both nullptr and NULL should implicitly convert to a pointer too.)
Reply all
Reply to author
Forward
0 new messages