No libv8.a generated for either X64 or ARM64 build.

[Nonny Mouse]

I'm trying to build V8 for both X64 and ARM64 (by cross compiling).  Both builds seem to run and complete without errors, but libv8.a, libplatform.a, etc. are not generated for either build.  However, other static libraries are successfully built (e.g. libgmock.a).

Build machine is X64 running Mint 17.3 (i.e. Ubuntu 14.04LTS).  To be certain, I created a new v8 directory and downloaded and built everything again with the following:

     git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
     export (correct path, beginning with depot_tools)
     fetch v8;  cd v8
     build/linux/sysroot_scripts/install-sysroot.py --arch=arm64
     gclient sync
    
     then:

     gn gen out/a64 --args='is_debug=false symbol_level=0 v8_use_external_startup_data=false v8_enable_i18n_support=false target_cpu="arm64"'
     ninja -C out/a64 | tee out/a64/build.log

(The only difference between the X64 and ARM64 builds was the target_cpu and out directory).



[Jochen Eisinger]

Currently, we don't create an .a file, but assume that the embedding app also uses gn which would then just pass the list of all object files on. I filed https://bugs.chromium.org/p/v8/issues/detail?id=5435 to track this issue in general

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nonny Mouse]

Thanx Jochen.

That's what I suspected.  It won't be difficult to fix within a standard g++ build, for the moment, but I am concerned for the future.

I can understand the choice to create a custom build system for a very large project like Chromium, but not for something as relatively simple as V8.  I have no intention of building any version of the full browser and I doubt that many in this group will, either.  In 40+ years of professional software development I have had to learn many different build systems (and even more programming languages) and I really don't want to waste my efforts delving into the fine details of another.  Especially since I would only be using it for one project.

All we really need are easily constructed, static and shared libraries (and, if possible, a little better documentation) . . .

Nevertheless, thanks for all your work here.  It really is greatly appreciated . . .

[Nonny Mouse]

In case anyone else would prefer to use static libraries in their own build, I have found it easiest to create all .a files as (thin archives) in the same directory, with cd to .../v8/v8/out/x64/obj and then:

     ar rcsDT libv8_base.a v8_base/*.o   (repeated for each library directory)

All libraries are then made easily available to GCC or LD with "export LIBRARY_PATH=/xxx/v8/v8/out/x64/obj" using an -l option for each required library (e.g. -lv8_base).

It would be really nice if this could be done automatically in the GN build . . .