Using Goma on Fedora

53 views
Skip to first unread message

Andrew Guenther

unread,
Dec 18, 2020, 1:49:18 PM12/18/20
to infra-dev
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

unread,
Dec 18, 2020, 3:33:49 PM12/18/20
to Andrew Guenther, Thomas Anderson, infra-dev
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

unread,
Dec 18, 2020, 4:34:22 PM12/18/20
to Dirk Pranke, Andrew Guenther, Thomas Anderson, infra-dev

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.

Andrew Guenther

unread,
Dec 18, 2020, 4:45:29 PM12/18/20
to infra-dev, Mostyn Bramley-Moore, infra-dev, Dirk Pranke, Andrew Guenther, Thomas Anderson
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

unread,
Dec 18, 2020, 5:14:25 PM12/18/20
to infra-dev, Andrew Guenther, Mostyn Bramley-Moore, infra-dev, Dirk Pranke, Thomas Anderson
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

unread,
Dec 21, 2020, 9:34:49 AM12/21/20
to infra-dev, guea...@amazon.com
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

unread,
Dec 21, 2020, 9:55:59 AM12/21/20
to infra-dev, guea...@amazon.com
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 (鵜飼文敏)

unread,
Jan 7, 2021, 12:54:20 AMJan 7
to Raphael Kubo da Costa, infra-dev, guea...@amazon.com

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.

Yoshisato Yanagisawa

unread,
Jan 7, 2021, 1:27:39 AMJan 7
to Fumitoshi Ukai (鵜飼文敏), Raphael Kubo da Costa, infra-dev, guea...@amazon.com
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>:

Andrew Guenther

unread,
Jan 7, 2021, 1:10:38 PMJan 7
to infra-dev, yyana...@chromium.org, Raphael Kubo da Costa, infra-dev, Andrew Guenther, Fumitoshi Ukai
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

unread,
Jan 11, 2021, 5:23:05 AMJan 11
to infra-dev, guea...@amazon.com, yyana...@chromium.org, Fumitoshi Ukai
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

unread,
Jan 11, 2021, 4:12:14 PMJan 11
to infra-dev, Raphael Kubo da Costa, Andrew Guenther, yyana...@chromium.org, Fumitoshi Ukai
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

unread,
Jan 12, 2021, 4:54:14 AMJan 12
to Raphael Kubo da Costa, infra-dev, guea...@amazon.com, Fumitoshi Ukai
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>:
Reply all
Reply to author
Forward
0 new messages