Using Goma on Fedora

[Andrew Guenther]

Hey all,

I'm looking to understand if Goma currently supports builds initiated from Fedora and if not what the work to do that might be.

When attempting a build I currently see these errors:

input root detection failed: no common paths in inputs: [src/out/Goma /lib64/libc-2.26.so]
compiler_proxy [1.366252089s]: no retry: exec error=-1 retry=1 reason=input root detection failed: no common paths in inputs: [src/out/Goma /lib64/libc-2.26.so] http=healthy

From what I gather, this is because libc would normally be getting pulled from the supplied sysroot which defaults to --sysroot=../../build/linux/debian_sid_amd64-sysroot

Since I'm on Fedora and not a Debian based distribution, this file (and presumably others) can't be found in the sysroot. Digging in to that sysroot folder shows some scripts which I don't fully understand which seem to be responsible for creating/updating this sysroot. Would I need to generate a sysroot for Fedora similar to how these scripts do for Debian? The scripts are a bit daunting, but if there's any documentation on what the requirements are for sysroot, I'd like to try my hand at it.

If it is relevant, I'm also using a Bazel-Buildfarm based backend for Goma which I know to be working for builds initiated from Debian.

[Dirk Pranke]

I'm not sure of the answer, but @Thomas Anderson may be able to advise here.

-- Dirk

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/4cefa744-66fd-45a7-bb15-b190cbb233ean%40chromium.org.

[Mostyn Bramley-Moore]

Are you using a custom toolchain? If so, I would try placing it inside your chromium checkout, and all of its dependencies reported by ldd.

-Mostyn.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAEoffTCNz5bRWXjp5bVGKHDoJSUj62_8PqgXOAd-qgvpKdsuhg%40mail.gmail.com.

[Andrew Guenther]

I don't believe I'm using a custom toolchain. This is just a clean checkout. I can see the version of clang being used is the one in my checkout:

../../third_party/llvm-build/Release+Asserts/bin/clang++

But I can see that if I ldd the clang binary that it's dependencies are not all in my checkout:

± ldd clang

linux-vdso.so.1 (0x00007fff60957000)

libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f61a6dd7000)

librt.so.1 => /lib64/librt.so.1 (0x00007f61a6bcf000)

libdl.so.2 => /lib64/libdl.so.2 (0x00007f61a69cb000)

libm.so.6 => /lib64/libm.so.6 (0x00007f61a668b000)

libz.so.1 => /lib64/libz.so.1 (0x00007f61a6476000)

libstdc++.so.6 => src/third_party/llvm-build/Release+Asserts/bin/./../lib/libstdc++.so.6 (0x00007f61a60fc000)

libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f61a5ee6000)

libc.so.6 => /lib64/libc.so.6 (0x00007f61a5b3b000)

/lib64/ld-linux-x86-64.so.2 (0x00007f61a6ff5000)

[Andrew Guenther]

If it's useful, this is my current Goma env:

GOMA_ARBITRARY_TOOLCHAIN_SUPPORT=true

GOMA_BURST_MAX_SUBPROCS=64 (auto configured)

GOMA_BURST_MAX_SUBPROCS_HEAVY=16 (auto configured)

GOMA_BURST_MAX_SUBPROCS_LOW=64 (auto configured)

GOMA_COMPILER_INFO_POOL=7 (auto configured)

GOMA_COMPILER_PROXY_DAEMON_MODE=true

GOMA_COMPILER_PROXY_HTTP_THREADS=8 (auto configured)

GOMA_COMPILER_PROXY_LOCK_FILENAME=goma_compiler_proxy.lock

GOMA_COMPILER_PROXY_PORT=8088

GOMA_COMPILER_PROXY_SOCKET_NAME=goma.ipc

GOMA_COMPILER_PROXY_THREADS=32 (auto configured)

GOMA_FALLBACK=true

GOMA_INCLUDE_PROCESSOR_THREADS=32 (auto configured)

GOMA_LOG_CLEAN_INTERVAL=86400

GOMA_MAX_SUBPROCS=7 (auto configured)

GOMA_MAX_SUBPROCS_LOW=6 (auto configured)

GOMA_PING_TIMEOUT_SEC=60

GOMA_SERVER_HOST=<removed>

GOMA_SERVER_PORT=80

GOMA_TMP_DIR=/run/user/1778107/goma_gueandre

GOMA_USE_LOCAL=false

GOMA_USE_SSL=false

I have a local env file that I source which explicitly sets the following options:

export GOMA_SERVER_HOST=<removed>

export GOMA_ARBITRARY_TOOLCHAIN_SUPPORT=true

export GOMA_USE_SSL=false

export GOMA_USE_LOCAL=false

export GOMA_SERVER_PORT=80

export GOMA_FALLBACK=true

[Raphael Kubo da Costa]

I've always used the Goma client on Fedora (I'm currently on F33) without issues. My latest successful build was with revision f42fa3f3bff6a4e6ae775c7a15b4be74ae6086c2 from December 15.

In case it helps, I use the following GN arguments in my build:

    dcheck_always_on = true
    enable_nacl = false
    is_component_build = true
    is_debug = false
    use_goma = true
    goma_dir = "<path/to/depot_tools>/.cipd_bin"

I usually don't need to set any Goma environment variable for the build to work.

[Raphael Kubo da Costa]

Coming to think of it, I might have run into similar issues in the past back when I was trying to set up my own Goma server + Buildbarn backend many months ago. I think at the time setting GOMA_ARBITRARY_TOOLCHAIN_SUPPORT=true like you do was enough. That specific error message is coming from the Goma server AFAICS, so I'd try to get more insight into what's making it fail like that. IIRC you can also set GLog-related variables when starting the client to get more verbose logs (e.g. GLOG_v=9).

[Fumitoshi Ukai (鵜飼文敏)]

https://bugs.chromium.org/p/chromium/issues/detail?id=1158833 ?

Next client release will fix this.

2020年12月21日(月) 23:56 Raphael Kubo da Costa <raphael.ku...@intel.com>:

--

You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/0bed8f14-0b6d-4433-9f1d-009971443327n%40chromium.org.

[Yoshisato Yanagisawa]

Sorry for the slow reply, but the Goma client excludes uploading files if they are in directories listed in ld.so.conf.  I guess Fedora does not have /lib64 in ld.so.conf, and the dynamic loader picks libraries in /lib64 because they are in trusted paths.  As Fumitoshi mentioned, the fix will be available in the next release.  Hopefully, until the end of the next week.

2021年1月7日(木) 14:54 'Fumitoshi Ukai (鵜飼文敏)' via infra-dev <infr...@chromium.org>:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAE8n1nd8BqQc0Cj70PkxD5wRAvzisN9dFBNuJtwrqYkbuMYLiA%40mail.gmail.com.

[Andrew Guenther]

Great to hear! Thanks for the reply. I don't seem to have permissions for that issue, but I'll keep an eye out for commits tagged with it and report back.

[Raphael Kubo da Costa]

I don't have access to that bug either, but now I do remember filing https://bugs.chromium.org/p/chromium/issues/detail?id=998092, and looking at my /etc/ld.so.conf I can see

    # For Goma.
    /lib
    /usr/lib
    /usr/lib64

(dunno if that's still relevant, but it did fix some issues I was having at the time).

[Andrew Guenther]

Thank you so much Raphael! That worked! Still excited to see the other change come through, but awesome that I can start using this today.

[Yoshisato Yanagisawa]

I have updated the head of the source and am going to update 

https://chromium-review.googlesource.com/c/infra/goma/client/+/2623122

With the latest Goma client, libraries in trusted paths would also be redacted.

2021年1月11日(月) 19:23 Raphael Kubo da Costa <raphael.ku...@intel.com>: