On Mon, Mar 5, 2012 at 14:23, Bryan White <[email protected]> wrote:
> > Yep, that seems to be the case, and it is sufficient for all clients of > V8 > > that I know of. > > I don't know what you definition of 'client' is in this context, Projects depending on V8. > but I > for one use the static libv8 and would be very concerned if the option > to build this was dropped. > > > There's no need to explicitly specify it as it's the default behavior > > anyway. > > It sounds like you are saying the static lib is built by default. Is > that true? It contradicts most everything else you say in this post. > What I meant is that component=static_library is the default setting, so there's no need to explicitly specify this on the command line. > Why do you need libv8.a in the first place? Look at d8.gyp for an example > > how you can statically link against V8. It "just works". Generally > speaking, > > if you have a choice at all, you should opt for dynamic linking (i.e. > shared > > libraries). > > I am uncomfortable dynamically linking against projects in very active > development. We are a small company with v8 running on half a dozen > different servers. There is a high likely hood of breaking things by > deploying an add but forgetting to deploy an updated shared lib. > > I am not aware that statically linking to a .so is possible. Right, and I didn't say it was. Also, I didn't ask why you would want to link against V8 statically -- my question was, why you need precisely libv8.a (rather than libv8_base.a + libv8_nosnapshot.a + libv8_snapshot.a) in order to do that. > I scanned the d8.gyp file. I don't speak gyp but I did not see anything > about this. > The d8 target, which has type "executable", specifies a dependency on the "v8" target, which has type "none" (but in turn depends on other targets that produce .a files). That's enough to have the d8 binary statically link in everything. Most of us developers do that all the time, and the standard Chrome/Chromium build works similarly. Things might not be quite as easy if you don't use GYP for your downstream project, but in that case you're more or less on your own anyway. I'm happy to help if I have time, and as I said before you can also submit a patch yourself that adds functionality you need that might be missing. In any case, it is the intention of the V8 team to stop supporting two build systems, so the SCons build is slated to be dropped. That doesn't mean that the option to link statically is going away, it just so happens that the GYP build doesn't generate a libv8.a as the SCons build did, and so far I haven't considered this a problem because both shared and static linking is still possible. This also means that I haven't looked into how much work it would be to get a libv8.a if one so desired. -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
