Configurable /usr/lib/libv8.* path

[Christoph Dorn]

Would it be possible to add a config flag to specify the location of
the libv8.* shared library?

I don't want to have to put it at /usr/lib/libv8.*

Christoph

[Ondřej Žára]

This question is beyond my skills, but I guess that would be difficult: libv8 is a shared library, so it is looked up by OS at runtime. I have no idea how to tell the OS to search for it in an explicit locations... this document might provide some info: http://www.eyrie.org/~eagle/notes/rpath.html

I personally solve this by putting a symlink into /usr/lib/libv8.so which points to my V8 svn repo. This way I don't have to copy anything when I recompile.

Alternatively, V8 could be build as a static library and thus linked directly *into* v8cgi during the build process.


Ondrej

2011/10/3 Christoph Dorn <chri...@christophdorn.com>

--
You received this message because you are subscribed to the Google Groups "v8cgi" group.
To post to this group, send email to v8...@googlegroups.com.
To unsubscribe from this group, send email to v8cgi+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/v8cgi?hl=en.

[Christoph Dorn]

On Oct 3, 11:41 am, Ondřej Žára <ondrej.z...@gmail.com> wrote:
> Alternatively, V8 could be build as a static library and thus linked
> directly *into* v8cgi during the build process.

How would I "link" it in? What would be the disadvantages to this
approach?

Christoph

[Ondřej Žára]

If you build V8 as a static library (e.g. without "library=shared") and remove the dynamic one you already have, it will get linked into v8cgi when v8cgi is built.

However, this approach seems to segfault right now - most probably because V8 gets linked into every v8cgi module and collisions occur when multiple modules are loaded at once.

So, I recommend the symlink solution :)


O.

P.S. I started looking into OpenSSL to enable HTTPS download, stay tuned :)

2011/10/3 Christoph Dorn <chri...@christophdorn.com>

Christoph

[Christoph Dorn]

On Oct 3, 12:43 pm, Ondřej Žára <ondrej.z...@gmail.com> wrote:
> If you build V8 as a static library (e.g. without "library=shared") and
> remove the dynamic one you already have, it will get linked into v8cgi when
> v8cgi is built.
>
> However, this approach seems to segfault right now - most probably because
> V8 gets linked into every v8cgi module and collisions occur when multiple
> modules are loaded at once.

Bug filed: http://code.google.com/p/v8cgi/issues/detail?id=98

> P.S. I started looking into OpenSSL to enable HTTPS download, stay tuned :)

Looking forward to it!

FYI, I have updated the test programs project with a bunch more info
and easier ways to run demos and tests:

https://github.com/pinf/test-programs-js

Christoph

[niknah]

In linux, use LD_LIBRARY_PATH

export LD_LIBRARY_PATH=/opt/v8/lib

v8cgi xxxxx.js

[Ondřej Žára]

> P.S. I started looking into OpenSSL to enable HTTPS download, stay tuned :)

Looking forward to it!

FYI, I have updated the test programs project with a bunch more info
and easier ways to run demos and tests:

 https://github.com/pinf/test-programs-js

The SSL library is somewhat working, so the downloads are okay now. Next issues:

1) SYSTEM.exec expects an API not present in v8cgi; trying to work around.
2) FILE.readdir (pinf-loader-js/api.js:404) not implemented; will try to figure API out from node.

O.

 

[Christoph Dorn]

Ondřej Žára wrote:

> P.S. I started looking into OpenSSL to enable HTTPS download, stay tuned :)

Looking forward to it!

FYI, I have updated the test programs project with a bunch more info
and easier ways to run demos and tests:

 https://github.com/pinf/test-programs-js

The SSL library is somewhat working, so the downloads are okay now. Next issues:

Great!

1) SYSTEM.exec expects an API not present in v8cgi; trying to work around.

Is this due to not having stdout and stderr available after executing the command? GPSEE has the same issue as will likely all the other platforms other than node.

At the moment I am not checking the exit code which is something I should do and could solve this issue short-term. Once that is in place separating stdout and stderr is not as critical although nice (may not be needed for the loader adapter layer but when used from applications I find it super useful). One suggestion that has been made is to redirect stdout and stderr to files and then pick up the files after and return content along with exit code. This should be optional.

The primary uses for EXEC in the loader are to decompress zip and tar.gz files and remove directory trees by running 'rm -R ...' as far as I can remember. That is all that should be needed to download and resolve dependencies. If you can compile in native implementations of these then we can get rid of the exec calls which would be even better (planned for all platforms long-term).

FYI, I will not have time to review/push any code until after Oct 17.

Christoph

[Ondřej Žára]

1) SYSTEM.exec expects an API not present in v8cgi; trying to work around.

Is this due to not having stdout and stderr available after executing the command? GPSEE has the same issue as will likely all the other platforms other than node.

Yes. I am not sure what an ideal exec() API looks like - a synchronous call (as in v8cgi) normally returns one value, while this one should ideally provide three (exit code, stdout, stderr). The Process module in v8cgi is very raw, so I would be happy to adjust it in order to offer richer functionality while maintaining reasonable API.

 

At the moment I am not checking the exit code which is something I should do and could solve this issue short-term. Once that is in place separating stdout and stderr is not as critical although nice (may not be needed for the loader adapter layer but when used from applications I find it super useful). One suggestion that has been made is to redirect stdout and stderr to files and then pick up the files after and return content along with exit code. This should be optional.

The primary uses for EXEC in the loader are to decompress zip and tar.gz files and remove directory trees by running 'rm -R ...' as far as I can remember. That is all that should be needed to download and resolve dependencies. If you can compile in native implementations of these then we can get rid of the exec calls which would be even better (planned for all platforms long-term).

I already figured that; my fixing of SYSTEM.exec will now consist mainly of analyzing downloader.js and adjusting the v8cgi adapter accordingly. Will let you know when I make some advancement...


Best regards,
Ondrej



 

FYI, I will not have time to review/push any code until after Oct 17.

Christoph