GYP: libv8preparser.so.x still needed?

[Floren Munteanu]

Hi all,

I'm compiling v8 with GYP and python 2.6.8, on CentOS 5.8 64 bits:

export LD_LIBRARY_PATH="out/x64.release/lib.target out/x64.release/d8"

%{__make} %{?_smp_mflags} -j8 x64.release library=shared console=readline

The make is successful and I see the libv8.so library, but  libv8preparser.so is missing. When I used to compile it with scons, I had that lib generated.

Do I miss any additional make command to create the missing lib? Thanks for your help.

[Jakob Kummerow]

I don't feel like I need libv8preparser.so.

Since you're not reporting anything that's broken, looks like you don't need it either. 

[Floren Munteanu]

Thank you for your reply, Jakob. I mainly want to use v8 for nodejs. Do you know what libv8preparser library does? When would you use it?

Regards,

Floren

[Jakob Kummerow]

The name suggests that it contains the meat of the "preparser" binary when that is linked dynamically. I don't know any uses for that binary (beyond running preparser unit tests), though, and it seems to be linked statically now.

As long as everything works, why worry about changes under the hood?

[Floren Munteanu]

The reason I ask this is because I plan to release my v8-3.12.16 64bits rpm's to everyone. (CentOS/Redhat 5 and 6)

I just want to make sure they are reliable and everyone is happy. :)

As a side note, is much easier to build with gyp compared to scons. It was a bit tricky to do it in a Redhat5 env but I previously created the python26 packages so everything compiled like a charm.

[Jakob Kummerow]

On Fri, Jul 27, 2012 at 11:54 AM, Floren Munteanu <ad...@yqed.com> wrote:

The reason I ask this is because I plan to release my v8-3.12.16 64bits rpm's to everyone. (CentOS/Redhat 5 and 6)

I just want to make sure they are reliable and everyone is happy. :)

So you're picking a random trunk revision and are hoping that that's stable and reliable?!

In V8's current version numbering scheme, the 4th number indicates stability fixes, and branches are generally way more stable than trunk. I would suggest to look at what Chrome and/or node.js are using, and use those versions as candidates for stable package releases. Currently, Chrome 20/stable is at V8 3.10.8.20, Chrome 21/beta and node.js are using V8 3.11.10.17 (essentially they're tracking the tip of the respective branch).

[Floren Munteanu]

On Friday, July 27, 2012 6:56:53 AM UTC-4, Jakob Kummerow wrote:

So you're picking a random trunk revision and are hoping that that's stable and reliable?!

In V8's current version numbering scheme, the 4th number indicates stability fixes, and branches are generally way more stable than trunk. I would suggest to look at what Chrome and/or node.js are using, and use those versions as candidates for stable package releases. Currently, Chrome 20/stable is at V8 3.10.8.20, Chrome 21/beta and node.js are using V8 3.11.10.17 (essentially they're tracking the tip of the respective branch).

Thank you for the info, Jakob. As usual, Redhat/CentOS are left behind compared to OpenSuse, Debian and Ubuntu who have v8 and nodejs available in their stable repos. I was simply trying to help and produce more recent rpm's. The latest version available for Redhat is 3.6.6.25. Even Fedora Rawhide is running their latest rpm version at 3.8.9.

Based in your useful advice, I will create the rpm using the 3.11 branch. I do have a question related to versioning. Do you recommend me to use the major.minor.build versioning or should I also add the stability fixes number to the rpm package? I see Fedora using only the x.xx.xx model.

[Jérémy Lal]

You can search this mailing list for some previous comments about
versioning and soname.

The version you use in the package name (libv8-3.10.8) reflects the
soname version of the library. Upstream v8 doesn't guarantee ABI
compatibility of libv8 releases (because it is quite difficult to do so),
but, as indicated by data like
http://www.upstream-tracker.org/versions/v8.html
you can safely assume the soname version to be 3.10.8 instead of 3.10.8.23,
because 3.10.8.24 (most likely) won't break ABI/API compatibility.

If you understand this, you realize you can't choose a soname version of
3.12.16, because it is likely to be ABI/API incompatible with 3.12.16.xx
at some point. In that case you either use the full version, or wait for
that branch to reach a stable state.

J�r�my.

[Floren Munteanu]

On Friday, July 27, 2012 8:19:44 AM UTC-4, kapouer wrote:

The version you use in the package name (libv8-3.10.8) reflects the
soname version of the library. Upstream v8 doesn't guarantee ABI
compatibility of libv8 releases (because it is quite difficult to do so),
but, as indicated by data like
http://www.upstream-tracker.org/versions/v8.html
you can safely assume the soname version to be 3.10.8 instead of 3.10.8.23,
because 3.10.8.24 (most likely) won't break ABI/API compatibility.

If you understand this, you realize you can't choose a soname version of
3.12.16, because it is likely to be ABI/API incompatible with 3.12.16.xx
at some point. In that case you either use the full version, or wait for
that branch to reach a stable state.

Thank you. That is another part of the gyp compiling puzzle I addressed. Linux expects something like libv8.so.3 and I additionally provide soft links for libv8.so, libv8.so.3.11 and libv8.so.3.11.10.

The compile end result with proper soname in CentOS 5.8:

Provides: libv8.so.3()(64bit)
Requires(interp): /bin/sh /bin/sh
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires(post): /bin/sh
Requires(postun): /bin/sh
Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.4)(64bit) libm.so.6()(64bit) libm.so.6(GLIBC_2.2.5)(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(GLIBCXX_3.4)(64bit) libv8.so.3()(64bit) rtld(GNU_HASH)
Processing files: v8-devel-3.11.10-1.el5
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: libv8.so.3()(64bit) python(abi) = 2.4 v8 = 3.11.10-1.el5

I would like to also know how do you determine the 4th number which indicates stability fixes? I did not see any info into ChangeLog. So far, I only know the major, minor, build and repo revision.

[Jakob Kummerow]

On Fri, Jul 27, 2012 at 3:03 PM, Floren Munteanu <ad...@yqed.com> wrote:

I would like to also know how do you determine the 4th number which indicates stability fixes? I did not see any info into ChangeLog. So far, I only know the major, minor, build and repo revision.

 

Yeah, we don't create ChangeLog entries when we backport patches. The full version information is in src/version.cc, and we create corresponding SVN tags (which you can watch out for on the v8-dev mailing list).

[Jérémy Lal]

On 27/07/2012 15:03, Floren Munteanu wrote:
> On Friday, July 27, 2012 8:19:44 AM UTC-4, kapouer wrote:
>
> The version you use in the package name (libv8-3.10.8) reflects the
> soname version of the library. Upstream v8 doesn't guarantee ABI
> compatibility of libv8 releases (because it is quite difficult to do so),
> but, as indicated by data like

> http://www.upstream-tracker.org/versions/v8.html <http://www.upstream-tracker.org/versions/v8.html>

> you can safely assume the soname version to be 3.10.8 instead of 3.10.8.23,
> because 3.10.8.24 (most likely) won't break ABI/API compatibility.
>
> If you understand this, you realize you can't choose a soname version of
> 3.12.16, because it is likely to be ABI/API incompatible with 3.12.16.xx
> at some point. In that case you either use the full version, or wait for
> that branch to reach a stable state.
>
>
> Thank you. That is another part of the gyp compiling puzzle I addressed. Linux expects something like libv8.so.3 and I additionally provide soft links for libv8.so, libv8.so.3.11 and libv8.so.3.11.10.

do you use the right flags ?
here are the ones used in the debian package :
library=shared snapshot=off soname_version=3.11.10

i advise you to look at the source package of others distros.

Jérémy.

[Floren Munteanu]

On Friday, July 27, 2012 9:16:12 AM UTC-4, kapouer wrote:

do you use the right flags ?
here are the ones used in the debian package :
library=shared snapshot=off soname_version=3.11.10

Ya Jeremy, except I use soname_version=3

If I use 3.11.10, the compiler will produce:

... libstdc++.so.6(GLIBCXX_3.4)(64bit) libv8.so.3.11.10()(64bit) ...

instead of:

... libstdc++.so.6(GLIBCXX_3.4)(64bit) libv8.so.3()(64bit) ...

I'm used to see the the major version only, in each library. What do you recommend?

I checked other packages and they all use scons.

[Floren Munteanu]

On Friday, July 27, 2012 9:24:43 AM UTC-4, Floren Munteanu wrote:

I checked other packages and they all use scons.

This is what the compiler produces with scons on Redhat 6.3:

... libstdc++.so.6(GLIBCXX_3.4)(64bit) libv8.so.3()(64bit) libv8preparser.so.3()(64bit) ...

So I don't know what to do. I think is best to stick with the major version as real file and soft link the libv8.so.3 to the other versions?

[Jérémy Lal]

On 27/07/2012 15:24, Floren Munteanu wrote:
> On Friday, July 27, 2012 9:16:12 AM UTC-4, kapouer wrote:
>
> do you use the right flags ?
> here are the ones used in the debian package :
> library=shared snapshot=off soname_version=3.11.10
>
>
> Ya Jeremy, except I use soname_version=3
> If I use 3.11.10, the compiler will produce:

> ... libstdc++.so.6(GLIBCXX_3.4)(64bit) *libv8.so.3.11.10 *()(64bit) ...
> instead of:
> ... libstdc++.so.6(GLIBCXX_3.4)(64bit) *libv8.so.3 *()(64bit) ...

>
> I'm used to see the the major version only, in each library. What do you recommend?
> I checked other packages and they all use scons.

That is precisely i've been trying to explain :
if you use a soname version of just "3", it assumes all versions of libv8 starting
with a 3 are API and ABI compatible. Since this is clearly a false statement,
you will have to bump your soname for each new major.minor branch (approximately).
At the end, you have libv8.so.78 for v8 version 3.20.15, which is not clear.

Instead, i propose you use a soname version built upon the fact that (up until now)
the versions between 3.11.10.1 and 3.11.10.17 are API/ABI compatible : 3.11.10.

Also note that if you don't version soname in accordance with API changes or
ABI incompatibilities, other packages depending on yours will not know why they
suddenly break : a program using libv8.so.3 will need to be recompiled (at best)
if you update libv8.so.3 to an ABI/API incompatible version.

For example, in debian (well it didn't got into wheezy, but anyway it's planned)
we're going to use :
SONAME : libv8.so.3.10.8
/usr/lib/libv8.so.3.10.8
/usr/lib/libv8.so -> libv8.so.3.10.8 (provided by libv8-dev)

Is that clear ?

J�r�my.

[Jérémy Lal]

On 27/07/2012 15:38, J�r�my Lal wrote:
> Is that clear ?

further explanations :
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi

J�r�my.

[Floren Munteanu]

On Friday, July 27, 2012 9:38:33 AM UTC-4, kapouer wrote:

For example, in debian (well it didn't got into wheezy, but anyway it's planned)
we're going to use :
SONAME : libv8.so.3.10.8
/usr/lib/libv8.so.3.10.8
/usr/lib/libv8.so -> libv8.so.3.10.8 (provided by libv8-dev)

Is that clear ?

Very clear, Jeremy. I will follow the same approach to keep everything uniform, many thanks for this final clarification.

[Floren Munteanu]

As recommended by Jeremy, the final compiler results in CentOS 5.8 64 bits are:

Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.4)(64bit) libm.so.6()(64bit) libm.so.6(GLIBC_2.2.5)(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(GLIBCXX_3.4)(64bit) libv8.so.3.11.10()(64bit) rtld(GNU_HASH)

Processing files: v8-devel-3.11.10-1.el5
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1

Requires: libv8.so.3.11.10()(64bit) python(abi) = 2.4 v8 = 3.11.10-1.el5

Thank you for the valuable information. 

[Floren Munteanu]

OK, the finalized RPM's are now published into my public repository:

http://rpm.axivo.com

Jeremy, Jakob,

I dare asking this question here since it looks like you have close knowledge about Node.js also.

I opened this topic on nodejs list:

https://groups.google.com/forum/?fromgroups#!topic/nodejs/lhKN6aFxT6g

If you have any inside, please reply there. Thank you again for taking the time to help me sort the last puzzle.

[Jakob Kummerow]

Only one remark, which is not node.js specific at all:

As has been discussed previously in this thread, V8's version numbers do not try to make any statements about binary compatibility. That means to avoid run-time breakage, *any* applications compiled against V8 must play it safe and depend on *exactly* the V8 version they were compiled against.

When you're *lucky*, something that's compiled against, say, V8 v3.11.10.17 will also work with v3.11.10.18, but there are *no guarantees* that all 3.11.10.x versions are ABI compatible. (Most of the time they are, because most stability/security fixes do not change the ABI, but sometimes they're not, because when we decide to backport a fix we do not even check for ABI compatibility.)

When you let your node.js package depend on "V8 >= 3.11.10", it again comes down to luck: If you are careful to release matching updates for both packages at the same time, and if all of your users happen to always install matching sets of updates, everything will be fine. If, however, for whatever reason someone ends up with the older node.js package and e.g. V8 3.14.x, chances are their node.js will not work. (Again, no guarantees either way -- it might happen that our ABI won't change between 3.11 and 3.14, or that at least it doesn't break backwards compatibility, but nobody is ensuring this or even trying.) If my package manager installed two packages on my system which are not compatible given their respective versions, I would consider that a bug ;-)

[Jérémy Lal]

I agree with you, that is why using an ABI compatibility checker is
indispensable when i suggest to use major.minor.build soname version.
Otherwise one would have to do as you say.

J�r�my.

[Floren Munteanu]

On Saturday, July 28, 2012 9:24:46 AM UTC-4, Jakob Kummerow wrote:

When you let your node.js package depend on "V8 >= 3.11.10", it again comes down to luck: If you are careful to release matching updates for both packages at the same time, and if all of your users happen to always install matching sets of updates, everything will be fine. If, however, for whatever reason someone ends up with the older node.js package and e.g. V8 3.14.x, chances are their node.js will not work. (Again, no guarantees either way -- it might happen that our ABI won't change between 3.11 and 3.14, or that at least it doesn't break backwards compatibility, but nobody is ensuring this or even trying.) If my package manager installed two packages on my system which are not compatible given their respective versions, I would consider that a bug ;-)

Jakob, that was the very first thing I thought also. IMO, the proper way to build node.js (or any other v8 dependent package) is to match exactly the v8 version:

%global npmver 1.1.45
%global pybasever 2.6
%global pythonver 26
Summary: Evented I/O for V8 JavaScript
Name: nodejs
Version: 0.8.4
Release: 1%{dist}
License: MIT
Group: Development/Languages/Other
URL: http://www.nodejs.org/
Source: http://nodejs.org/dist/v0.8.4/node-v%{version}.tar.gz
BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
BuildRequires: curl, gcc-c++, procps, openssl-devel >= 1.0.1
BuildRequires: python%{pythonver}, pkgconfig, v8-devel = 3.11.10
BuildArch: noarch
Requires: v8 = 3.11.10
Provides: npm = %{npmver}

....
%build
./configure \
--prefix=%{_prefix} \
--shared-openssl \
--shared-v8 --shared-v8-includes=%{_includedir} \
--shared-zlib
%{__make} %{?_smp_mflags} 

The above config is for CentOS 5, which requires python26. I saw several people not creating an exact v8 dependency and I thought right away about what we discussed earlier on soname subject.

[Floren Munteanu]

On Saturday, July 28, 2012 11:05:25 AM UTC-4, kapouer wrote:

I agree with you, that is why using an ABI compatibility checker is
indispensable when i suggest to use major.minor.build soname version.
Otherwise one would have to do as you say.

Hi Jeremy,

Can you detail a bit more how you would perform an ABI compatibility check?

I saw that you are a packager for nodejs. :)

Thank you.

[Jérémy Lal]

First you can check
http://www.upstream-tracker.org/versions/v8.html
or use the tool that generates that data (abi-compliance-checker).
I believe that tool is not perfect, but good enough in our case
(checking ABI not broken with patch-level revisions of v8).
Its author tried to promote its usage, but for now i don't know
if any developer working for a distro is actualy using it.

As an additional check, you can also run nodejs test suites against the new
version of v8, using the nodejs binary compiled against the previous version
of v8. If it fails, there is a problem...


Jérémy.