Google Chrome Extension using NaCL with an externa

2019-02-19 19:35发布

I'm developing a Google Chrome extension using the NaCL. It's pretty cool and easy to use, but I have a doubt.

My extension needs the GPGME (GnuPG Made Easy), so I compile that library with '--enable-shared' option and added the library to the .mnf file:

{
    ...
    "files": {
        "libgpgme.so": {
            "x86-64": {
                "url": "libs/libgpgme.so"
            },
            "x86-32": {
                "url": "libs/libgpgme.so"
        }
    }
    ...
}

I also update the makefile with option '-lgpgme' but when I compile my .nexe I have the follow erro: "libgpgme.so: file not recognized: File format not recognized".

So, my questions are:

  1. Can I use a external library with my project?
  2. How can I do this?

-- Cheers, José

2条回答
女痞
2楼-- · 2019-02-19 19:40

You need to port libgpgme to NaCl first. I.e. libgpgme should be compiled by NaCl compiler not a Linux compiler.

GPGME uses configure. So porting usually done by passing wrapping scripts as compiler. These scripts replace NaCl programs produced by NaCl compiler with a script that invokes them via sel_ldr. This way configure can run compiled NaCl programs as normal Linux ones.

查看更多
不美不萌又怎样
3楼-- · 2019-02-19 19:57

Because Native CLient's inner sandbox relies on validation of the binary, you need to compile libgpgme with the Native Client tools. In general, Native Client needs to validate any code before it gets executed, including any libraries, whether they be statically or dynamically linked. By far the easiest way to create binaries that can be validated is using the Native Client compilers.

Porting to Native Client: Since libgpgme uses autotools, and in particular configure, you'll need to advertise the NaCl platform to them by adding a section like this in the basic_machine part of the file config.sub, which should reside somewhere in the libgpgme source tree:

   nacl*)
           basic_machine=i686-pc
           os=-nacl
           ;;

and adding

  -nacl*

to the os section of the same file. An example of a particularly clean port is libogg. You can see the entirety of the patch at http://code.google.com/p/naclports/source/browse/trunk/src/libraries/libogg-1.1.4/nacl-libogg-1.1.4.patch. (Strictly speaking, config.sub is generated from configure.in, but it is often more expedient to edit config.sub.)

There is more to porting than this first step, so some guides and pointers to existing ports follow to give you a feel for how it's done.

Guides: For more information, there are several porting post-mortems at https://developers.google.com/native-client/community/developers. In particular, the one about XaoS at https://developers.google.com/native-client/community/porting/xaos has a short section about autotools.

Existing ports: Also, there is a community-based repository for Native Client called naclports. It contains several libraries that have already been ported, but unfortunately not libgpgme yet. You can see the list of libraries in naclports at http://code.google.com/p/naclports/source/browse/trunk/src/libraries/. While it contains useful examples of how to do ports, naclports is not for the faint-hearted as it often breaks and - given that it's maintained on a volunteer/best-effort basis - may take time to get fixed.

查看更多
登录 后发表回答