Support GLBIC example.

native_client_sdk/src/examples/dlopen/eightball.cc

Index: native_client_sdk/src/examples/dlopen/eightball.cc
===================================================================
--- native_client_sdk/src/examples/dlopen/eightball.cc	(revision 0)
+++ native_client_sdk/src/examples/dlopen/eightball.cc	(revision 0)
@@ -0,0 +1,20 @@
+#include <stdlib.h>
+#include <stdio.h>
+
+#include "eightball.h"
+
+const char *Magic8Ball(void) {

[Brad Chen, 2012/01/31 22:29:54]

I'm so happy you dropped the __attribute__ stuff. That said, please be sure we
aren't hitting the problem the old code was trying to fix. In particular check
all flavors of Windows.

[noelallen1, 2012/02/01 17:46:10]

Windows bots are passing, but we don't have all OS flavors represented.  I'll
keep an eye out.  However, I don't see how that's possible.  I can understand if
newlib vs glibc fails since they are toolchains, but I would expect our GCC
toolchain and sel_ldr/chrome built for Windows on machine N which is unknown, to
work the same for any Windows platform X that down loads it.  Windows is not
involved in either the link or load process.

On 2012/01/31 22:29:54, Brad Chen wrote:

+  const int NSIDES = 8;
+  const char* answer[NSIDES] = {
+    "YES",
+    "NO",
+    "MAYBE",
+    "MAYBE NOT",
+    "DEFINITELY",
+    "ASK ME TOMORROW",
+    "PARTLY CLOUDY",
+    "42",
+  };
+  return answer[rand() % NSIDES];
+}
+
Property changes on: native_client_sdk/src/examples/dlopen/eightball.cc
___________________________________________________________________
Added: svn:eol-style
   + LF