New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 607107 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: May 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

libc++.gyp makes (wrong) assumption about directory depth.

Project Member Reported by yangguo@chromium.org, Apr 27 2016

Issue description

I use a custom workflow where I compile V8 with

GYP_DEFINES="v8_enable_disassembler=1 v8_object_print=1 release_extra_cflags='-ggdb3' use_goma=1 clang=1 msan=1 target_arch=x64 v8_target_arch=arm64" GYP_GENERATOR_FLAGS="output_dir=out/msan" gclient runhooks

ninja -j1024 -C out/msan/Release d8

Compiling with msan has a dependency on the custom libc++ in v8/buildtools. Compiling libc++ fails. The reason is that the variable for the directory root is set like this:

    'libcxx_root': '../../buildtools/third_party/libc++',

However, given my output dir structure (out/msan/Release instead of out/Release), the directory depth is 3 instead of the assumed 2.

Changing the variable to

    'libcxx_root': '<(DEPTH)/buildtools/third_party/libc++',

fixes the issue.

I have no idea how to upstream this change though... help?
 
Not an expert on gyp, but this change looks reasonable.
Why do you think it would not be acceptable?

I simply have no idea how to upstream the change, which is why I filed this issue :)
I _think_ there should have been a reason for having that '../..' instead of '<(DEPTH)', but I don't remember for sure. Maybe there were problems with different build systems. Maybe there weren't.
I'll give this a shot.
Wait.
<(DEPTH) is a path relative to GYP file, not the build directory.
Unless we're in a gypi file, there's no point in using <(DEPTH), I even heard it was discouraged.

I have also noticed that Chrome recently got GYP disabled by default. This may have not happened for MSan yet, but it will happen sooner or later.
V8 still uses and relies on GYP, and this will not change until node.js has moved away from GYP.

I'm not too familiar with GYP myself, but changing ../.. to <(DEPTH) indeed fixes the issue for me.
Ah, I see now.
That's because buildtools/ resides under v8/ now, i.e. libc++ descends one level deeper in the directory tree.
It should not actually have anything to do with your output dir structure.
+Michael, who touched the code in question.

I've tried to replace the dots with '<(DEPTH)' (see https://codereview.chromium.org/1934993003/), but it broke MSan build for me.
Cc: machenb...@chromium.org
Cc: tandrii@chromium.org
Your chromium trybot is not (yet) usable for buildtools patches. Lemme fix that.
Sorry, to be clear, that change also breaks MSan for me locally, so this does not seem to be an option.

(thanks for fixing the bots anyway)
Right, but just as a showcase that these bots function now infra-wise: Could you rebase and reup the patch and trigger the bot again?
Done, will be watching the bots.
Can I see which CL it is?
I don't think youv'e rebased the CL - at least I don't see PROJECT field.
I can try to reup the CL myself and see...
Project Member

Comment 17 by sheriffbot@chromium.org, May 3 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: WontFix (was: Untriaged)
This'll be obsolete with gyp deprecation...

Sign in to add a comment