Complicated usage with static libv8

[ondras]

Hi,

please forgive if this question is not directly related to V8 itself, but rather to gcc/c++ usage.

My project (v8cgi) uses a main binary and several (loadable) modules. These modules are implemented as shared libraries; both the main binary and modules use V8.
Under normal circumstances, I use a shared V8 library and everything works cool.

One of v8cgi users recently suggested if it would be possible to use a static build of libv8. I tried that and failed: having V8 linked to both the main binary *and* all the modules seems to crash badly (segfault) when I dlsym() the first external module.

1) is the static V8 the reason why the scenario described above segfaults?
2) how can I avoid this? Is it actually possible to use static V8 from within those loadable modules?


Thanks,
Ondrej Zara

[Michael Schwartz]

Hey Ondrej,

There are flags for GCC that force export of ALL public symbols.  This should allow your .so to find the symbols in your main binary.  There may be another switch that forces the whole .a file to be linked in, not just the referenced (by your main binary) symbols.

Hope that's enough to get you going in the right direction.

Also, you are probably getting an error on dlopen(), so you should not be calling dlsym()…

:)

--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users

[Ondřej Žára]

Hi Mike,

first of all, the dlopen() call is okay: all my modules (in the failing scenario described above) are linked with (static) libv8.a, so they do not lack V8 symbols. The dlsym() call, on the other hand, begins interacting with V8 API, which segfaults - most probably because of some global state V8 depends on (and is confused by having multiple V8 instances in memory).

As for the GCC option to export all symbols: do you suggest compiling v8cgi itself first (with libv8.a), then linking all secondary modules against this binary, not against libv8?


Thanks,
Ondrej

2011/10/6 Michael Schwartz <myk...@gmail.com>

[Michael Schwartz]

I am sure you don't want to statically link libv8.a multiple times.

I think you need to statically link libv8.a with your main program and force all symbols to be exported.  Then your loaded .so can find the symbols for libv8 in your main program.

Ideally you shouldn't have to static link with libv8.a at all.  I bet there are gcc/ld flags that would allow all to be .so.

[Stephan Beal]

On Thu, Oct 6, 2011 at 4:31 PM, Michael Schwartz <myk...@gmail.com> wrote:

Ideally you shouldn't have to static link with libv8.a at all.  I bet there are gcc/ld flags that would allow all to be .so.

In fact, libv8.a won't compile warning-free on Linux because v8 uses networking libs which cannot link statically on Linux. gcc will warn about that this and tell you that at runtime it will use the DLL versions for those symbols. This is caused by code used in the PosixSocket class in v8.

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

[Ondřej Žára]

2011/10/6 Michael Schwartz <myk...@gmail.com>

I am sure you don't want to statically link libv8.a multiple times.

Precisely.
 

I think you need to statically link libv8.a with your main program and force all symbols to be exported.  Then your loaded .so can find the symbols for libv8 in your main program.

Okay, will try this: link v8cgi with libv8.a; link my modules with libv8.so. V8 symbols will be available at runtime so the modules will be happy; libv8.a will be linked just to main binary. Sounds reasonable; will let you know about the outcome.
 

Ideally you shouldn't have to static link with libv8.a at all.  I bet there are gcc/ld flags that would allow all to be .so.

Yes, the shared solution works flawlessly. I am just trying an alternative, suggested by one of my users...


O.

 

[Stephan Beal]

On Thu, Oct 6, 2011 at 5:18 PM, Ondřej Žára <ondre...@gmail.com> wrote:

Okay, will try this: link v8cgi with libv8.a; link my modules with libv8.so. V8 symbols will be available at runtime so the modules will be happy; libv8.a will be linked just to main binary. Sounds reasonable; will let you know about the outcome.

i _think_ that runs the risk of the problem you and i discussed a few days ago - a "split brain" (as it's known in clustering jargon). Some of v8's file-local static (not exported) internals might be in the static bits and some might be allocated again in the DLL. Might. Maybe.

 

Ideally you shouldn't have to static link with libv8.a at all.  I bet there are gcc/ld flags that would allow all to be .so.

Yes, the shared solution works flawlessly. I am just trying an alternative, suggested by one of my users...

But of course i've been known to be wrong ;).

[Ondřej Žára]

2011/10/6 Stephan Beal <sgb...@googlemail.com>

On Thu, Oct 6, 2011 at 5:18 PM, Ondřej Žára <ondre...@gmail.com> wrote:

Okay, will try this: link v8cgi with libv8.a; link my modules with libv8.so. V8 symbols will be available at runtime so the modules will be happy; libv8.a will be linked just to main binary. Sounds reasonable; will let you know about the outcome.

i _think_ that runs the risk of the problem you and i discussed a few days ago - a "split brain" (as it's known in clustering jargon). Some of v8's file-local static (not exported) internals might be in the static bits and some might be allocated again in the DLL. Might. Maybe.

The main idea here was that the whole V8 will be loaded into memory only once, because it will be linked only once - as a static library to v8cgi. All other modules will be linked to shared V8, which will not be actually used - because all of the symbols will be available from v8cgi binary.

However, this approach does not seem to work: there is no segfault, but the app still crashes. I will investigate this in more detail later, but it is pretty straightforward that my initial impression of this setup was way too optimistic.

O.

 

 

Ideally you shouldn't have to static link with libv8.a at all.  I bet there are gcc/ld flags that would allow all to be .so.

Yes, the shared solution works flawlessly. I am just trying an alternative, suggested by one of my users...

But of course i've been known to be wrong ;).

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

--

[Michael Schwartz]

Try linking everything against libv8.so.  Your main program should be able to load v8 as a .so, and all your other .so should be able to find the symbols.  I think there's a special command line switch to gcc/ld that will export all the symbols in your main program (and libv8.so) to the elf file.

[Stephan Beal]

On Thu, Oct 6, 2011 at 10:05 PM, Michael Schwartz <myk...@gmail.com> wrote:

.so should be able to find the symbols.  I think there's a special command line switch to gcc/ld that will export all the symbols in your main program (and libv8.so) to the elf file.

-rdynamic

 

[Michael Schwartz]

Yeah, that's one of the switches.  There's another one for linking tho.

On Oct 6, 2011, at 9:29 AM, Stephan Beal wrote:

[Ondřej Žára]

2011/10/6 Michael Schwartz <myk...@gmail.com>

Try linking everything against libv8.so.  Your main program should be able to load v8 as a .so, and all your other .so should be able to find the symbols.  I think there's a special command line switch to gcc/ld that will export all the symbols in your main program (and libv8.so) to the elf file.

If I link everything to libv8.so, the whole project works without the need to hack (or explicitly export) anything :)

The original intention, lost in discussion, was to actually *evade* shared V8 completely. However, my recent experiments and googling lead me to conclusion that using a static V8 does not seem to be possible.


O.