Interested in helping out with nacl_io filesystems, porting, and languages

[Dennis Kane]

Hi, I just saw the contributor page (https://developer.chrome.com/native-client/reference/ideas). I just posted about my site (the Native Client Proving Ground) a few days ago. See it at https://nacl-pg.appspot.com/desk?intro=the-shaker. I feel like I already know everyone who is working on this full time (Sam, Brad, Ben, etc), from all the mailing lists and stackoverflow. For me, this is not so much about wanting to help out. I pretty much have to work on this kind of stuff in order to feel like my life has any meaning.

I guess where I fit in is that broad excitement about this project can't really get started until there is a decent reference implementation that anyone in the world can see, hear, and touch for themselves. I've been working on my site for close to three years now, mostly in JavaScript land, but the last several months have been getting deeper into the wild world of PNaCl.

Right now, I'm putting the finishing touches on a mechanism that binds python to the JS desktop GUI. So, a user will be able to create a python object, and send it as a xhr style request to the JS.  This is a very general mechanism to allow the PNaCl module to build up knowledge about the world, as it were, and then act appropriately on that. In case you weren't aware, this pretty much opens up an infinity of possibilities to the web platform. I am also looking at creating python bindings to node servers (local or otherwise) via websockets in order to have a mechanism to import arbitrary data from the web, without needing to worry about the CORS politics that goes on in browser-land.

I am definitely interested in integrating different kinds of filesystems into the project, as well as getting new ports and language bindings up and running.

I have never had any interest in contributing to an open source project from afar. I would really like to improve my quality of life, either by working for a decent company or by starting something that is closely affiliated with one, so I can avoid the hell of the startup grind.

I recently posted my site to Hacker News, and it got to the first page for a little while (I have the appengine logs to prove it!).

Let me know if any of you mentors (per the contributor page) have any interest in what I'm doing.

p.s. I have no problem selling out very cheaply to the right bidder! :)

[Sam Clegg]

Hi Dennis,

I did see your Proving Ground post, and was meaning to respond
earlier. It looks really great! I'm sure there are lots of ways you
could contribute to NaCl and/or naclports. Are you aware that we
have a project in naclports called the NaCl Dev Environment which is
somewhat similar? It doesn't look as nice as yours, its purely
terminal based, but it supports running most of the application in
naclports and uses the pkg package manger. Some initial questions:
Did you write your own terminal emulator and process management
system in JavaScript? Is your work open source? Would you
interested in contributing any of your to naclports?

If you are specifically interesting in building a filesystem for
nacl_io I think a really usefull one would be Google Drive. This
would allow people to edit their drive files using (for example) vim,
which I think would make a lot of people happy.

cheers,
sam

> --
> You received this message because you are subscribed to the Google Groups
> "Native-Client-Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to native-client-di...@googlegroups.com.
> To post to this group, send email to native-cli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/native-client-discuss.
> For more options, visit https://groups.google.com/d/optout.

[Dennis Kane]

Hey Sam,

Thanks alot for the response.

Seriously... thanks! :)

The whole process of developing this thing has just been such a crazy experience for me, that it's pretty hard for me to figure out how to easily respond to a lot of your questions.

So instead of immediately trying to tackle them head on, I first want to shed some light on the larger perspective of what makes me tick.

I'm from Florida, and I graduated high school (in the early 90's) pretty high in my class without having to think very hard. My Dad was a computer programmer for GE at the time, so it was no surprise that I ended up declaring a compsci major as a freshman in college. But I personally had no clue about computers, and I was always the kind of person who was eventually going to get into a really deep philosophical mindset.  In college, I found rock 'n' roll, and by my sophomore year, that got the better of me, so I dropped out of school. Then I went back and dropped out again, then joined the Army for awhile, then ventured out to California on a Greyhound bus, where I lived for a couple of years as a free-spirited pedicab rider in downtown San Diego. Then, I moved back to Florida, where I could make better money as an actual cab driver.

It wasn't until I turned 30 (in 2005) that I started in get into computers, when I wiped Windows XP off of my desktop machine and installed Debian with no GUI.  After about a year of playing around with the command line, I started to get into actual programming with Perl. Then I started to go deeper into the heart of things by playing around with C. By about 2011, I heard about node.js, and that began my foray into JavaScript. I started to play around with trying to put as much functionality into a browser window as I possibly could. A year later is when I started to work on my current project.

I wanted to lay all of this out first so everyone could understand that I never came into programming simply because I happen to be good at it or even that I have an interest in it, as a thing in itself.  I am really just very interested in the big questions of life, and technology just happens to have a very central role in many of those questions. So ultimately, the reason I can get up in the morning and feel like my life is worth anything is because I truly believe I am working on things that will have some kind of impact on the future.

Okay, so with all of that as a background, let me try to tackle the question of whether any of my work is open source. There are several ways to think about the question of "open source":

1) The first way that comes to my mind is whether an interested person can get an ascii text representation of a program, or just a binary blob. Well, JavaScript obviously does not have a binary form, so this question is moot for the vast majority of my work.

2)  Another way concerns whether a person can get a version of a program that the programmer actually works on, or just a version of the program that has been minified or obscured somehow.

3) Yet another way asks about the legal standing of the code in question, when in comes to the licensing issue.

Well, question #1 is already answered. The answer to #2 is no, and the answer to #3 is, "What me worry?"  The reason for my answer to #2 is partly because of local political factors where I live, partly because I have needed to pretty much go into a pretty serious state of personal hibernation to get my ideas out of my head and into reality, and partly because I just find the whole process of dealing with modern repository concepts and semantics to be something of a specialization that I have no interest in mastering, and so I simply refuse to even begin the process of learning them. And the reason for my answer to #3 is just that I hate even thinking about the "de jure" aspects of what I do. I only care about technology because of its "de facto" implications to the wider world. The philosophical way of saying this is: To the things themselves!

As far as the local political factors are concerned, you need to understand that I live in the heart of Florida, which might as well be the heart of the Amazon or the Congo when it comes to the question of software, open source or otherwise.  Like I said before, I have no interest in the concept of contributing to software projects from a distance, ie, if my only contact with my peers is over the internet. That is, I just don't get any pleasure out of emailing, web chatting, or video conferencing with anyone. In fact, doing all of that stuff can only make my life even worse, if it is not connected to anything in my everyday reality, because it only shines a spotlight on how crappy my real life actually is.

If I were to be living somewhere in which these questions had any social/economic/political relevance, then I could start to form more meaningful opinions about them. At the moment, though, all I can say is that I live in a place where the people just look at me cross-eyed if I start to talk about anything related to my programming interests.

Given the right situation, I would just hand over my latest development tarball without batting an eyelash. As long as a person has vim with "foldmethod=marker" enabled, then they could start to make sense out of things pretty easily because I rely on deep nesting and closures to hierarchically organize my code rather than doing more complicated tricks like extending object prototypes and, e.g., calling bind or apply.  A curious person could then just browse the code asking for clarification about what is going on since I don't have much lucid commenting at the moment, and then I could just go through and put in some decent comments. But that is just the JavaScript side of things.

As far as the C/C++ level is concerned, I only have a few working directories where I really just play around with the whole NaCl build system. Right now, my best bet is to just look at the naclports build logs, and copy the various pnacl-clang command lines into my own shell script so I don't have to try to make sense out of the whole  naclports+python build system.

I've recently been hacking on files like ps_instance.c and nacl_setup_env.c to do some basic integration work with my system. In ps_instance.c, for example, I've created a new handler from the JS that is in response to an outstanding request from a python script. The python script just hangs while it waits for the answer. I got that working pretty well yesterday. So, you can just do this from python:

import desk
response = desk.ask_the_js("portname", {"arg1": True, "foo": 42, "bar": "baz"})
...do something with response

Maybe the desk will pop up a simple dialog and ask a yes/no question, maybe it will prompt for a voice recording to import into a local machine learning subsystem in order to do offline or domain specific voice recognition, etc.  The python script will just wait while the page does its thing.

And as far as filesystem integration is concerned, my main concern is to what extent these mechanisms are implemented on the NaCl side vs the JS side. But I am definitely interested in the whole idea of supporting seamless Drive and/or Github integration. Really, it's not so much that I'm "interested" as it's really a no brainer and it would be a crime not to start working on it fairly soon.

My terminal emulator is kind of a can of worms. There is not really any official notion of "processes" per se, although it shouldn't be too big of a problem to get that working if and when that kind of logic is needed. I've looked at the code in naclterm.js, naclprocess.js, and hterm.concat.js to try to understand the approach that Google is taking with respect to all of that, and I do actually use all of that infrastructure whenever the user opens up ncurses applications such as nano and vim. Otherwise, I just do all of the normal REPL terminal handling with my own JS module that at least seems to work pretty well for the purposes of the current system. 

The bottom line about me is pretty simple. If there is an idea that has pretty deep implications in the academic/philosophical sense at the same time that it has a foothold in the real world where normal people are going about their everyday lives, them I'm ready to rumble, and I'm interested in figuring out how to start working with anyone who is like-minded.  For me, the limiting factor until now has been the amount of time and effort I've had to invest into getting my technical skills up to par with my theoretical ponderings.

The bottom, bottom line is even simpler: whatever involves the highest degree of "logical awesomeness" is where I want to be!

Thanks again!

> email to native-client-discuss+unsub...@googlegroups.com.

[Dennis Kane]

To everyone,

I should have apologized in advance in my previous post for my tendency to blabber on and on about things. But what can I say... I love philosophy, and technology gives me an outlet to make fairly profound philosophical points!

As far as pure technology is concerned, I think the best thing for right now is just concentrate on doing a rough prototype of seamless Drive integration with the system at the JavaScript layer. My intuition is that it makes more sense to keep the various "domain specific" ideas of mounting different filesystems at this level, at least for now. So, there can be directories like "/gdrv" or "/gthb", whose files can be edited directly from vim or nano. Under the covers, the native client module will have to intercept the write(2) system calls so that the file gets sent to the page and then waits for confirmation that the server-side operation was successful. If there was some kind of a problem like no network connection, this will obviously need to be handled gracefully.

I think something along these lines can start getting worked out in fairly short order.

Other than that, I will try to not write any more tl;dr nonsense like I wrote in my last post :)

[Sam Clegg]

On Sat, Nov 21, 2015 at 7:14 AM, Dennis Kane <dka...@gmail.com> wrote:
> To everyone,
>
> I should have apologized in advance in my previous post for my tendency to
> blabber on and on about things. But what can I say... I love philosophy, and
> technology gives me an outlet to make fairly profound philosophical points!
>
> As far as pure technology is concerned, I think the best thing for right now
> is just concentrate on doing a rough prototype of seamless Drive integration
> with the system at the JavaScript layer. My intuition is that it makes more
> sense to keep the various "domain specific" ideas of mounting different
> filesystems at this level, at least for now. So, there can be directories
> like "/gdrv" or "/gthb", whose files can be edited directly from vim or
> nano. Under the covers, the native client module will have to intercept the
> write(2) system calls so that the file gets sent to the page and then waits
> for confirmation that the server-side operation was successful. If there was
> some kind of a problem like no network connection, this will obviously need
> to be handled gracefully.

This sounds like a good place to start. nacl_io already intercepts
the I/O calls suchs read() and write(). There is even a jsfs
filesystem in nacl_io already which allows you to implement a
filesystem in JavaScript.

>
> I think something along these lines can start getting worked out in fairly
> short order.
>
> Other than that, I will try to not write any more tl;dr nonsense like I
> wrote in my last post :)
>

> --
> You received this message because you are subscribed to the Google Groups
> "Native-Client-Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to native-client-di...@googlegroups.com.

[Dennis Kane]

> This sounds like a good place to start.  nacl_io already intercepts 
> the I/O calls suchs read() and write().  There is even a jsfs 
> filesystem in nacl_io already which allows you to implement a 
> filesystem in JavaScript.

I'm pretty understading of the basic gist behind the whole kernel intercept concept in nacl_io. I really just mean that I'll need to intercept it at the application level, like when vim is inside of its own main write function, in order to do things like seamless integration with Drive. I'll probably let vim write out onto the memfs, and then copy these bytes into a PP_Var ArrayBuffer that gets pumped to JS, and then wait for confirmation from the page before returning from that write function in vim.

Googling around for these different ideas like jsfs only ever seems to lead back to your own comments. I'm not bothered by the fact that there isn't much official documentation about this stuff... it just means that I must be pretty close to the bleeding edge :)

I've actually been making decent progress today. Now I have an "OAuth" settings tab that lets users give the necessary access permissions to the website, and I've updated the "mount" command to let users mount arbitrary directory names to the root directory, for use with remote filesystems like Drive. When this is done for the first time, it automatically creates a directory called "NaClPG-root" in the Drive root, where all of files will be kept. And I've also updated the "mkdir" command to create folders inside of this folder, and also the "ls" command to, well... you know.

If anyone else is interested in getting on board here, please don't be afraid to make yourself known!

[Sam Clegg]

On Sat, Nov 21, 2015 at 4:12 PM, Dennis Kane <dka...@gmail.com> wrote:
>> This sounds like a good place to start. nacl_io already intercepts
>> the I/O calls suchs read() and write(). There is even a jsfs
>> filesystem in nacl_io already which allows you to implement a
>> filesystem in JavaScript.
>
> I'm pretty understading of the basic gist behind the whole kernel intercept
> concept in nacl_io. I really just mean that I'll need to intercept it at the
> application level, like when vim is inside of its own main write function,
> in order to do things like seamless integration with Drive. I'll probably
> let vim write out onto the memfs, and then copy these bytes into a PP_Var
> ArrayBuffer that gets pumped to JS, and then wait for confirmation from the
> page before returning from that write function in vim.

I would try to avoid modifying vim here.. since that would imply that
every app would need modification. Doing it at the nacl_io/jsfs
layer means that all apps benefit from the new filesystem type.

> Googling around for these different ideas like jsfs only ever seems to lead
> back to your own comments. I'm not bothered by the fact that there isn't
> much official documentation about this stuff... it just means that I must be
> pretty close to the bleeding edge :)

Indeed, I don't know of any real uses of jsfs yes, so this could be the first.

>
> I've actually been making decent progress today. Now I have an "OAuth"
> settings tab that lets users give the necessary access permissions to the
> website, and I've updated the "mount" command to let users mount arbitrary
> directory names to the root directory, for use with remote filesystems like
> Drive. When this is done for the first time, it automatically creates a
> directory called "NaClPG-root" in the Drive root, where all of files will be
> kept. And I've also updated the "mkdir" command to create folders inside of
> this folder, and also the "ls" command to, well... you know.

I believe jsfs is based on the fuse API so there will be a few dozen
different syscalls to implement. Rather than implementing 'ls' per
say you would be implementing opendir/readdir. When you choose to
sync the data back to drive (e.g. on ever write, or only when a file
is closed. or somewhere in between) will depend on the performance and
desired semantics. I guess it could be configurable via mount params.

Also, It would be nice if all files in drive were accessible (not just
those under a specific sub-directory). I'm hoping we can enable vim
(or any other naclports app) as an editor for all text/plain files in
drive one day.

>
> If anyone else is interested in getting on board here, please don't be
> afraid to make yourself known!

Perhaps you could open a bug in the naclports tracker for this where
we can coordinate?

[Dennis Kane]

I wrote this before I tried to get jsfs working, which I worked on all day yesterday to no avail. Did you see the "Issues with jsfs" post?

> email to native-client-discuss+unsub...@googlegroups.com.

[Lichang Wang]

Sorry Dennis,

I will delete it now. I am sorry for that.

Best,

Lichang

On Tuesday, November 24, 2015 at 11:10:49 AM UTC-8, Dennis Kane wrote:

Hi, you have posted the same off-topic message on two of my threads after posting your own thread.

Just a word of advice: These guys work for a little company called Google, and as such are busy working on issues that are at least tangentially related to Google's interests.

You are trying to incorporate some kind of library from god knows who in order to do god knows what. However, that's not what the Native Client environment is here for.

Please spend some time in the nacl_sdk getting the examples to work and then modifying them to your needs.

Please delete your messages from my threads.

On Tuesday, November 24, 2015 at 1:33:42 PM UTC-5, Lichang Wang wrote:

Hello Sam,

Sorry to bug you ! I wonder if you could give me any suggestions about my problem with Native Client https://groups.google.com/forum/#!topic/native-client-discuss/fpQIIrGgwhE.

Any instruction will be most appreciated !!

Thank you

I was new to Native-Client, when I try Native-Client wihout HElib library(https://github.com/shaih/HElib), it works fine. But, when I introduced HElib library to my Native-Client application, the  pnacl-clang++ compiler always reports error.
It takes me a lot of time, but still can't be solved. The HElib also worked fine without Native_Client. I think it the problem of C++ library or NTL library path,,,but I can't figure out it.

Thank you in advance for any help !!

Here is the Makefile:
//////////////////////////////

////////////////////////////////////////////////////////////////////////////////////////////

      FILE := temple
 17
 18 THIS_MAKEFILE := $(abspath $(lastword $(MAKEFILE_LIST)))
 19 NACL_SDK_ROOT ?= $(abspath $(dir $(THIS_MAKEFILE))../)
 20
 21 #all:
 22 #       @echo  $(MAKEFILE_LIST)
 23 #       @echo  $(THIS_MAKEFILE)
 24 #       @echo  $(NACL_SDK_ROOT)
 25
 26 # Project Build flags
 27 WARNINGS := -Wno-long-long -Wall -Wswitch-enum -pedantic -Werror
 28 CLANGFLAGS := --pnacl-allow-native -std=gnu++11 -stdlib=libc++  -arch x86_64 #-DBOOST_DATE_TIME_HAS_HIGH_PRECISION_CLOCK=1 -DB    OOST_HAS_GETTIMEOFDAY=1  -pthread -std=gnu++11  $(WARNINGS)
 29
 30 #
 31 # Compute tool paths
 32 #
 33 GETOS := python $(NACL_SDK_ROOT)/tools/getos.py
 34 OSHELPERS = python $(NACL_SDK_ROOT)/tools/oshelpers.py
 35 OSNAME := $(shell $(GETOS))
 36 RM := $(OSHELPERS) rm
 37
 38 PNACL_TC_PATH := $(abspath $(NACL_SDK_ROOT)/toolchain/$(OSNAME)_pnacl)
 39 PNACL_CXX := $(PNACL_TC_PATH)/bin/pnacl-clang++
 40 PNACL_FINALIZE := $(PNACL_TC_PATH)/bin/pnacl-finalize

      HOMOMOR_ST_LIB := $(NACL_SDK_ROOT)/wlc_Homomorphic/HomomoLib/HElib-master/src/fhe.a
 43 HOMOMOR_FLAGS := -I/usr/local/include -I$(NACL_SDK_ROOT)/wlc_Homomorphic/HomomoLib/HElib-master/src
 44 HOMOMOR_LDFLAGS := -L/usr/local/lib  -lntl -lgmp -lm
 45
 46 CXXFLAGS := -I$(NACL_SDK_ROOT)/include
 47 LDFLAGS := -L$(NACL_SDK_ROOT)/lib/pnacl/Release -lppapi_cpp -lppapi
 48
 49 # Disable DOS PATH warning when using Cygwin based tools Windows
 50 #
 51 CYGWIN ?= nodosfilewarning
 52 export CYGWIN
 53
 54
 55 # Declare the ALL target first, to make the 'all' target the default build
 56 all: $(FILE).pexe
 57
 58 clean:
 59         $(RM) $(FILE).pexe $(FILE).bc
 60
 61 $(FILE).bc: $(FILE).cc
 62         $(PNACL_CXX) $(CLANGFLAGS)   -o $@ $< -O2 $(HOMOMOR_ST_LIB) $(HOMOMOR_FLAGS)  $(HOMOMOR_LDFLAGS)  $(CXXFLAGS) $(LDFLAG    S)
 63 $(FILE).pexe: $(FILE).bc
 64         $(PNACL_FINALIZE) -o $@ $<  
////////////////////////////////////////////////////////////////////////////////////////////////////////////

Below is trouble shot:

//////////////////////////////////////////////////////////////////////////////////////////////////////////////

/home/lichang/NativeClient/nacl_sdk/pepper_46/toolchain/linux_pnacl/bin/pnacl-clang++ --pnacl-allow-native -std=gnu++11 -stdlib=libc++  -arch x86_64    -o homomoEncryption.bc homomoEncryption.cc -O2 /home/lichang/NativeClient/nacl_sdk/pepper_46/wlc_Homomorphic/HomomoLib/HElib-master/src/fhe.a -I/usr/local/include -I/home/lichang/NativeClient/nacl_sdk/pepper_46/wlc_Homomorphic/HomomoLib/HElib-master/src  -L/usr/local/lib  -lntl -lgmp -lm    -I/home/lichang/NativeClient/nacl_sdk/pepper_46/include   -L/home/lichang/NativeClient/nacl_sdk/pepper_46/lib/pnacl/Release -lppapi_cpp -lppapi


In file included from homomoEncryption.cc:11:
In file included from /usr/local/include/NTL/ZZ.h:19:
/usr/local/include/NTL/tools.h:234:32: warning: shift count >= width of type
      [-Wshift-count-overflow]
   { unsigned long y = a;  x = NTL_ULONG_TO_LONG(y); }
                               ^~~~~~~~~~~~~~~~~~~~
/usr/local/include/NTL/ctools.h:273:26: note: expanded from macro 'NTL_ULONG_TO_LONG'
   ((((unsigned long) a) >> (NTL_BITS_PER_LONG-1)) ? \
                         ^  ~~~~~~~~~~~~~~~~~~~~~
In file included from homomoEncryption.cc:11:
In file included from /usr/local/include/NTL/ZZ.h:19:
/usr/local/include/NTL/tools.h:237:10: warning: shift count >= width of type
      [-Wshift-count-overflow]
   { x = NTL_ULONG_TO_LONG(a); }
         ^~~~~~~~~~~~~~~~~~~~
/usr/local/include/NTL/ctools.h:273:26: note: expanded from macro 'NTL_ULONG_TO_LONG'
   ((((unsigned long) a) >> (NTL_BITS_PER_LONG-1)) ? \
                         ^  ~~~~~~~~~~~~~~~~~~~~~
In file included from homomoEncryption.cc:11:
In file included from /usr/local/include/NTL/ZZ.h:19:
/usr/local/include/NTL/tools.h:245:35: warning: shift count >= width of type
      [-Wshift-count-overflow]
   { unsigned long y = a;  return NTL_ULONG_TO_LONG(y); }
                                  ^~~~~~~~~~~~~~~~~~~~

/usr/local/include/NTL/sp_arith.h:748:41: warning: shift count >= width of type
      [-Wshift-count-overflow]
   unsigned long rr = (cast_unsigned(b) << NTL_SP_NBITS) - cast_unsigned(q)*cas...
                                        ^  ~~~~~~~~~~~~                            ^
In file included from homomoEncryption.cc:11:
In file included from /usr/local/include/NTL/ZZ.h:20:
/usr/local/include/NTL/vector.h:414:20: warning: overflow in expression; result is
      2147483632 with type 'long' [-Winteger-overflow]
/usr/local/include/NTL/ctools.h:251:5: note: expanded from macro 'NTL_SNS_REALLOC'
   (NTL_OVERFLOW1(n, a, b) ? ((void *) 0) : \
    ^
/usr/local/include/NTL/ctools.h:165:34: note: expanded from macro 'NTL_OVERFLOW1'
    (((long) (n)) >= (NTL_OVFBND1-((long)(b))+((long)(a))-1)/((long)(a))))))
                                 ^
26 warnings generated.
/usr/local/lib/libntl.a(thread.o): error: undefined reference to 'std::string::assign(char const*, unsigned long)'
/usr/local/lib/libntl.a(fileio.o): error: undefined reference to 'std::string::append(std::string const&)'
/usr/local/lib/libntl.a(fileio.o): error: undefined reference to 'std::basic_iostream<char, std::char_traits<char> >::~basic_iostream()'
/usr/local/lib/libntl.a(fileio.o): error: undefined reference to 'std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >::~basic_stringstream()'
/usr/local/lib/libntl.a(fileio.o): error: undefined reference to 'std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()'

/usr/local/lib/libntl.a(GF2EXFactoring.o): error: undefined reference to 'std::basic_ifstream<char, std::char_traits<char> >::~basic_ifstream()'
/usr/local/lib/libntl.a(GF2EXFactoring.o): error: undefined reference to 'std::basic_filebuf<char, std::char_traits<char> >::~basic_filebuf()'

/usr/local/lib/libntl.a(GF2EXFactoring.o): error: undefined reference to 'std::basic_ios<char, std::char_traits<char> >::init(std::basic_streambuf<char, std::char_traits<char> >*)'
/usr/local/lib/libntl.a(GF2EXFactoring.o): error: undefined reference to 'vtable for std::basic_ios<char, std::char_traits<char> >'

/home/lichang/NativeClient/nacl_sdk/pepper_46/wlc_Homomorphic/HomomoLib/HElib-master/src/fhe.a(NumbTh.o): error: undefined reference to 'std::cerr'
/home/lichang/NativeClient/nacl_sdk/pepper_46/wlc_Homomorphic/HomomoLib/HElib-master/src/fhe.a(NumbTh.o): error: undefined reference to 'std::istream::get()'
/home/lichang/NativeClient/nacl_sdk/pepper_46/wlc_Homomorphic/HomomoLib/HElib-master/src/fhe.a(NumbTh.o): error: undefined reference to 'std::string::_Rep::_M_destroy(std::allocator<char> const&)'
/home/lichang/NativeClient/nacl_sdk/pepper_46/wlc_Homomorphic/HomomoLib/HElib-master/src/fhe.a(NumbTh.o): error: undefined reference to 'std::string::_Rep::_S_empty_rep_storage'
/home/lichang/NativeClient/nacl_sdk/pepper_46/wlc_Homomorphic/HomomoLib/HElib-master/src/fhe.a(NumbTh.o): error: undefined reference to 'std::string::assign(std::string const&)'
/home/lichang/NativeClient/nacl_sdk/pepper_46/wlc_Homomorphic/HomomoLib/HElib-master/src/fhe.a(NumbTh.o): error: undefined reference to 'std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)'
/home/lichang/NativeClient/nacl_sdk/pepper_46/wlc_Homomorphic/HomomoLib/HElib-master/src/fhe.a(NumbTh.o): error: undefined reference to 'std::string::_Rep::_M_dispose(std::allocator<char> const&)'
/home/lichang/NativeClient/nacl_sdk/pepper_46/wlc_Homomorphic/HomomoLib/HElib-master/src/fhe.a(NumbTh.o): error: undefined reference to 'std::basic_ios<char, std::char_traits<char> >::clear(std::_Ios_Iostate)'
.............
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////