Linking V8 statically and dynamically

[Luke]

When linking V8 to my project what static libraries do I need to link?
After building with GYP I have the following:

libpreparser_lib.a
libv8_base.a
libv8_nosnapshot.a
libv8_snapshot.a

Which do I need to link against? Which should be left out?

I'm also having trouble linking against libv8.dylib. After building it
(with module=shared option) it ends up in /v8/out/x64.release/
libv8.dylib.

I want it in /phpdev/lib. But when I try to link against it there,
what I build references /v8/out/x64.release/libv8.dylib not /phpdev/
lib/libv8.dylib.

Building the second script in getting started: https://developers.google.com/v8/get_started

$ ./hello_world

dyld: Library not loaded: /v8/out/x64.release/libv8.dylib
Referenced from: /test/./hello_world
Reason: image not found
Trace/BPT trap

$ otool -L ./hello_world
./hello_world:
/v8/out/x64.release/libv8.dylib (compatibility version 0.0.0, current
version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 125.2.11)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.9.0)

Luke

[Luke]

On Tuesday, April 10, 2012 6:22:13 PM UTC-7, Luke wrote:

When linking V8 to my project what static libraries do I need to link?
After building with GYP I have the following:

libpreparser_lib.a
libv8_base.a
libv8_nosnapshot.a
libv8_snapshot.a

Which do I need to link against? Which should be left out?

I still need an answer on this.

 

I'm also having trouble linking against libv8.dylib. After building it
(with module=shared option) it ends up in /v8/out/x64.release/
libv8.dylib.

I want it in /phpdev/lib. But when I try to link against it there,
what I build references /v8/out/x64.release/libv8.dylib not /phpdev/
lib/libv8.dylib.

Building the second script in getting started: https://developers.google.com/v8/get_started

$ ./hello_world

dyld: Library not loaded: /v8/out/x64.release/libv8.dylib
  Referenced from: /test/./hello_world
  Reason: image not found
Trace/BPT trap

$ otool -L ./hello_world
./hello_world:
        /v8/out/x64.release/libv8.dylib (compatibility version 0.0.0, current
version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 125.2.11)
        /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.9.0)

 

Figured this part out.

Need to run:

$ cd /phpdev/lib

$ install_name_tool -id /phpdev/lib/libv8.dylib libv8.dylib

After recompiling it should pick up the library in the right location. You can fix existing binaries like this:

$ install_name_tool -change /v8/out/x64.release/libv8.dylib /phpdev/lib/libv8.dylib hello_world

I'm not sure why the dylib's id is an absolute path. Perhaps this is a bug in the compilation process?

Luke

[Jakob Kummerow]

On Wed, Apr 11, 2012 at 18:54, Luke <lu...@webconnex.com> wrote:

On Tuesday, April 10, 2012 6:22:13 PM UTC-7, Luke wrote:

When linking V8 to my project what static libraries do I need to link?
After building with GYP I have the following:

libpreparser_lib.a
libv8_base.a
libv8_nosnapshot.a
libv8_snapshot.a

Which do I need to link against? Which should be left out?

I still need an answer on this.

Doesn't your linker figure that out all by itself when you point it to the right directory containing the libraries?

If it doesn't: for a build with snapshot, you need to link against libv8_base.a and libv8_snapshot.a (for a build without snapshot it's libv8_base.a and libv8_nosnapshot.a; if you say so on the GYP (or make) command line then libv8_snapshot.a won't be built in the first place). The snapshot gives you a (small) performance benefit, especially on startup, at the expense of some added binary size.

My understanding is that it's a flexibility vs. comfort tradeoff. Linking against the absolute path is easier to work with (you don't need LD_LIBRARY_PATH) and more robust against several versions of the libraries being around on your filesystem; on the other hand you lose the flexibility to move your libraries someplace else. Fortunately, as you've found out there are tools to manipulate the linkage information after the fact, so whatever the build system decides to do is merely a default that can be changed.