Google Chrome扩展程序使用NaCL和外部库 [英] Google Chrome Extension using NaCL with an external library

问题描述

我正在使用NaCL开发Google Chrome扩展程序。这是非常酷和易于使用，但我有疑问。

我的扩展需要GPGME（GnuPG Made Easy），所以我使用'--enable -shared'选项并将该库添加到.mnf文件中：

  {
 ... 
 files：{
libgpgme.so：{
x86-64：{
url：libs / libgpgme.so
}，
x86-32：{
url：libs / libgpgme.so
} 
} 
 ... 
} 
  

我也用选项'-lgpgme'更新makefile，但是当我编译我的.nexe时，我有下面的错误：

所以，我的问题是：

1. 我可以在项目中使用外部库吗？


2. 我该怎么做？

-
干杯，
何塞

解决方案

因为本地CLient的内部沙箱依赖于二进制文件的验证，您需要使用Native Client工具编译libgpgme。通常，Native Client需要在执行任何代码之前验证它，包括任何代码库，无论它们是静态链接还是动态链接。到目前为止，创建可验证二进制文件的最简单方法是使用Native Client编译器。

移植到Native Client：
由于libgpgme使用autotools，特别是configure，所以需要在文件config.sub的basic_machine部分添加一个像这样的区域来向其通告NaCl平台，该文件应该位于libgpgme源代码树的某个位置：

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

并加入

  -nacl * 
  

到同一个文件的操作系统部分。一个特别干净的端口的例子是libogg。您可以在 http://code.google.com/p/naclports/source/browse/trunk/src/libraries/libogg-1.1.4/nacl-libogg-1.1.4.patch 。 （严格地说，config.sub是从configure.in生成的，但通常更方便编辑config.sub。）

除了这个之外还有更多的移植步骤，所以一些指南和指向现有端口的指南会告诉你如何完成它。

指南：
For更多信息， https://developers.google.com/上有几个移植版本原生客户端/社区/开发者。特别是，有关XaoS的 https://developers.google.com/native

现有端口：
另外，有一个名为naclports的Native Client基于社区的存储库。它包含几个已经移植过的库，但不幸的是，它还没有libgpgme。您可以在 http：// code.google.com/p/naclports/source/browse/trunk/src/libraries/ 。虽然它包含了有关如何做端口的有用示例，但naclports并不适合胆小的人，因为它经常被打破，并且 - 由于它是以志愿者/尽力而为的方式维护的 - 可能需要一段时间才能得到解决。

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é

解决方案

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.

这篇关于Google Chrome扩展程序使用NaCL和外部库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！