My favorites | Sign in
Project Home Downloads Wiki Issues Source Code Search
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 151: Add a soname to the V8 shared library
9 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Closed:  May 2009

Sign in to add a comment
Reported by, Nov 16, 2008 must have a soname. should also be a symlink to the real 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:

Feb 23, 2009
Project Member #2
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.
Status: Accepted
Apr 28, 2009
Project Member #3
(No comment was entered for this change.)
Status: Assigned
Apr 29, 2009
Project Member #4
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 with an soname of

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. 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 patch set 3 implements this (without 
the stable branch soname).
May 1, 2009
Project Member #5
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 to the version 1.1 branch.
Status: Fixed
May 1, 2009
Project Member #6
The commit to r1831 was missing the files src/version.h, src/ and 
test/cctest/ These where added in r1833.

May 3, 2009
Project Member #7
The r1833 had the version number which was wront. This was fixed to be in r1834.
May 4, 2009
Project Member #8
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 with soname
Sign in to add a comment

Powered by Google Project Hosting