Has anyone successfully built a static library on osx 10.12.x using GN and Clang?

[Jared Wyles]

I am attempting to update our build infrastructure to use GN which requires using clang and producing static libs. 

I see there is now a v8_static_library argument to gn. So i have created a args.gn that looks something like

is_debug = false
target_cpu = "x64"
v8_static_library = true
is_component_build = true
v8_use_external_startup_data = false

then I execute ninja -C out.gn/foo -j 1 as usual (-j 1 to just debug any issues)

I now get the following error

$ ninja -C out.gn/foo -j 1
ninja: Entering directory `out.gn/foo'
[7/1419] LIBTOOL-STATIC obj/libv8_version.a
FAILED: obj/libv8_version.a
rm -f obj/libv8_version.a && TOOL_VERSION=1485597133 python ../../build/toolchain/mac/filter_libtool.py libtool -static -o obj/libv8_version.a
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: no files specified
Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -static [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-sacLT] [-no_warning_for_no_symbols]
Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -dynamic [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-o output] [-install_name name] [-compatibility_version #] [-current_version #] [-seg1addr 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table <filename>] [-seg_addr_table_filename <file_system_path>] [-all_load] [-noall_load]
ninja: build stopped: subcommand failed.

I also notice that building with clang on osx requires at least clang 3.9 due to the usage of no-undefined-var-template. Clang 8.0.0.0 appears to be branched before this landed in 3.9 is there a way to have gclient or gn pull down a correct version of llvm and its associated tooling to build v8?

[Ivgeni Segal]

It appears to work via regular make. From v8 directory simply type:

make x64.release -j4

It outputs static libraries to out/x64.release:

-rw-r--r--   1 isegal  staff    32649264 Feb  4 22:13 libicui18n.a

-rw-r--r--   1 isegal  staff    15306496 Feb  4 22:29 libicuuc.a

-rw-r--r--   1 isegal  staff      105592 Feb  4 22:13 libjson_fuzzer_lib.a

-rw-r--r--   1 isegal  staff     2695096 Feb  4 22:13 libparser_fuzzer_lib.a

-rw-r--r--   1 isegal  staff     2325672 Feb  4 22:13 libregexp_fuzzer_lib.a

-rw-r--r--   1 isegal  staff  1178275400 Feb  4 22:29 libv8_base.a

-rw-r--r--   1 isegal  staff     1840784 Feb  4 22:30 libv8_external_snapshot.a

-rw-r--r--   1 isegal  staff     1233032 Feb  4 22:13 libv8_libbase.a

-rw-r--r--   1 isegal  staff     1948848 Feb  4 22:13 libv8_libplatform.a

-rw-r--r--   1 isegal  staff      210456 Feb  4 22:13 libv8_libsampler.a

-rw-r--r--   1 isegal  staff     3014200 Feb  4 22:15 libv8_nosnapshot.a

[Jared Wyles]

I'll give that a shot!

Thanks

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

[Jared Wyles]

This is still using gyp not GN :( 

[Ivgeni Segal]

Just double checked - you are correct.

Though for my purpose it still works and the project that uses v8 builds and works.

It looks like there's an open issue https://github.com/electron/electron/issues/7940

and a recent discussion on the subject

https://groups.google.com/forum/#!topic/v8-users/L_Qc60uOZlk

I tried building on windows with the same parameters as yours and it also failed.

As it stands right now it looks like static builds are not supported with gn.

As a workaround, if you still need to use gn, it should be possible to manually invoke libtool on the object files once GN finishes building them.

[Ivgeni Segal]

Update:

I was able to successfully build on current OSX a recent V8 v5.9.35 after a small patch and the following command:

export PATH=`pwd`/depot_tools:"$PATH"

gclient sync

cd v8

gn gen --args="is_debug=false is_component_build=false v8_use_snapshot=true v8_use_external_startup_data=false v8_static_library=true" out.gn/x64.release

ninja -C out.gn/x64.release -j4

The patch can be found here:

https://github.com/isegal/v8/commit/67f391fd4c0d3e5ea0add73e04fe962295c42e2d

One more note (if you get mkpeephole build error):

If you have MacPorts or Brew, they may have an older version of LD that would conflict with the build process. Need to either temporarily remove /opt/local/bin from the path or update LD via the following command:

sudo port install ld64 +ld64_xcode

Good luck!

On Saturday, January 28, 2017 at 2:44:20 PM UTC-8, Jared Wyles wrote:

[Jared Wyles]

Just tried your patch ivgeni. Still the same error. Libtool appears to fail at the same point

rm -f obj/libv8_version.a && TOOL_VERSION=1485597133 python ../../build/toolchain/mac/filter_libtool.py libtool -static  -o obj/libv8_version.a 

error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: no files specified 

Will have to keep prodding it.

Jared.