On Oct 9, 1:48 pm, "Simon Ask Ulsnes" <[EMAIL PROTECTED]> wrote:
>> The other approach is to specify the full path to the build
>> directory's libv8.so in your g+ link line, but that's a dreadful hack,
>> and quick test programs linked that way should never be deployed.
>
> This is a perfectly valid and standard way of dealing with this:
>
> g++ -o your_target -I/path/to/v8 your_source_file.cpp /path/to/v8/libv8.a
Linking to libv8.a is a "perfectly valid and standard way" of linking
to libv8.so? :P
Methinks you didn't read what I wrote carefully enough before
replying. :-))))
Sure, static linking avoids the issue of shared library location, but
not by dealing with the issue. Instead, it doesn't use shared
libraries at all. ;-)
In any case, static or dynamic is not what alemao asked about, which
is why I answered with generic solutions for both types of linking.
Your advice doesn't work generically since the /path/to/v8 will vary
continually if V8 isn't actually installed and therefore application
Makefiles will regularly have to change, or, at the very least an
abstraction symlink will have to be updated every time that your
development path changes as you work on new versions of V8 so that
Makefiles can remain invariant. Unix newcomers who can't get V8 to
compile outside of the V8 directory are not about to be switching
symlinks on each update, so I suggested a generic solution that will
always work.
I bet it won't be long though before V8 is packaged for distribution
via the various distro packaging systems, in which case the whole
issue will disappear soon.
Morgaine.
--~--~---------~--~----~------------~-------~--~----~
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
-~----------~----~----~----~------~----~------~--~---
