|Issue 151:||Add a soname to the V8 shared library|
|9 people starred this issue and may be notified of changes.||Back to list|
libv8.so must have a soname. libv8.so should also be a symlink to the real libv8.so.X.Y.Z binary. This is needed by downstream in order to keep track of ABI changes so that apps linked against V8 can continue to run.
Feb 9, 2009
Update: this issue is still a problem for Debian, the library cannot be packaged until it ships a soname, see the following bug for more info: http://bugs.debian.org/497701 Cheers Antonio
Feb 23, 2009
Sorry about not responding to this earlier. We'd be happy to accept patches for adding a SONAME to the generated shared object files to our SCons-based build system.
Apr 28, 2009
(No comment was entered for this change.)
Apr 29, 2009
My suggestion is to include the full V8 version name in the soname to indicate that the API might change between each single V8 version. The main reason for this is as the V8 interface is a C++ interface it can be difficult to know when the actual interface changes. As C++ is used parts of the interface will be compiled into the client application e.g. for template expansion and inline functions. The SCons build for V8 will have an additional option 'soname=on' for building a shared object with an soname. When that option is specified the filename for the shared object will contain the version number, and the soname will be the same. E.g V8 version 1.2.3 will be called libv8-1.2.3.so with an soname of libv8-1.2.3.so. When a stable branch of V8 from some version is created we could change this scheme so that when building from a stable branch an soname of e.g. libv8.so.1 will be used, and binary compatibility will then be ensured on that branch as long as the soname stays the same. The current 1.1 branch might be a candidate for the first stable shared library. This requires some form of testing to ensure that this holds. One way to do that will be to build a shell (either the sample shell or the developer shell) using the first revision with a certain soname and then building the latest V8 shared object with the same soname and runn all the tests using the shell and the later shared object. This is perhaps not the optimal solution, but adding a fixed soname across several versions will require binary compatibility testing and adhering to strict rules when making changes to the API. Changelist http://codereview.chromium.org/100104 patch set 3 implements this (without the stable branch soname).
May 1, 2009
The scheme described above have been implemented in r1826, r1827 and r1828. The change is also applied to the version 1.1 branch in r1831. This also assigns the specific soname of libv8.so.1 to the version 1.1 branch.
May 1, 2009
May 3, 2009
May 4, 2009
The version handling have been removed from the version 1.1 branch to avoid adding files to the branch. For now r1833 can be pulled to build V8 18.104.22.168 with soname libv8.so.1.
|► Sign in to add a comment|