From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward501b.mail.yandex.net (forward501b.mail.yandex.net [178.154.239.145]) by sourceware.org (Postfix) with ESMTPS id 5289E3858C52 for ; Wed, 10 Apr 2024 13:55:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5289E3858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=yandex.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yandex.ru ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5289E3858C52 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=178.154.239.145 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712757349; cv=none; b=uqyxh+wPXzdzME1oPTsxaNJhzan164aKDX/EPs166EYaa6lrRpPU/EHZiORIR6uG1ssLVOtAPBUyl8E3VpAsvxVNZPuynslgSeLc2SomVxsUapdJd5Re9rEsN9zCdBqtuXlTQ5GAC7QxYkaMwtJ5QsDiw55rTwwh0ZfT7PUFWNQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712757349; c=relaxed/simple; bh=yG2NxiwqPpGvM5ewwU+Nlu/D81rdMH9K4f2mtSnbw/Q=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=wp+nfA4HI8OVu8e97qHz04ehDFgGudwzJkC0U8A8xlQDvWMWGf3kTssg1oa9gZYM0RDwdZpRyQQ8CGwb2YJBKeAZ37V9j2LhkVo0nzmSURx2a6Z0DYpyoBOLTir/3Tt1C3ByC2v7tFTpxebDPGnwqRGp08w1zxRasPRgWZdA/8A= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from mail-nwsmtp-smtp-production-main-19.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-19.sas.yp-c.yandex.net [IPv6:2a02:6b8:c24:3b2:0:640:ff71:0]) by forward501b.mail.yandex.net (Yandex) with ESMTPS id 9A415618D3; Wed, 10 Apr 2024 16:55:43 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-19.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id gtasdljDdeA0-35Gsaf1Y; Wed, 10 Apr 2024 16:55:43 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1712757343; bh=yG2NxiwqPpGvM5ewwU+Nlu/D81rdMH9K4f2mtSnbw/Q=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=IuE6qJWa1Us74sL4hjhlVpCIOBlr4XTkSlqGQYzqk8J3z/HJAjykZu3HWsKZqtALb h7P65Q1JIZbCD3Txvv3pFeao1LBr7NOhc5GlCu2OsG3wTw14oEnKEPBN3B7UjXeCnp oEQPCraI2Q2VqEaJL0WaPc+9Gb0wn7bLQsmd1eRw= Authentication-Results: mail-nwsmtp-smtp-production-main-19.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <47702d90c552af639e1e00e201dc850c01dace35.camel@yandex.ru> Subject: Re: libstdc++ link errors in support/links-dso-program From: Konstantin Kharlamov To: =?UTF-8?Q?=D0=93=D0=BE=D1=80=D0=B1=D0=B5=D1=88=D0=BA=D0=BE_?= =?UTF-8?Q?=D0=91=D0=BE=D0=B3=D0=B4=D0=B0=D0=BD?= , Florian Weimer Cc: =?UTF-8?Q?=D0=93=D0=BE=D1=80=D0=B1=D0=B5=D1=88=D0=BA=D0=BE_?= =?UTF-8?Q?=D0=91=D0=BE=D0=B3=D0=B4=D0=B0=D0=BD?= via Libc-help Date: Wed, 10 Apr 2024 16:55:42 +0300 In-Reply-To: References: <87msr0hs3n.fsf@oldenburg.str.redhat.com> <8734srh194.fsf@oldenburg.str.redhat.com> <98b5b573-67b8-4110-8759-ca67fab6f85b@gmail.com> <874jc92znl.fsf@oldenburg.str.redhat.com> <290c8346-5c9f-4d2e-80b8-80bdabfe833f@gmail.com> <442b4a2d966e8a34cf948e58416573157f9b5814.camel@yandex.ru> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.0 MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, 2024-04-10 at 16:30 +0300, =D0=93=D0=BE=D1=80=D0=B1=D0=B5=D1=88=D0= =BA=D0=BE =D0=91=D0=BE=D0=B3=D0=B4=D0=B0=D0=BD wrote: > On 10/04/2024 16:22, Konstantin Kharlamov wrote: > > On Wed, 2024-04-10 at 15:50 +0300, =D0=93=D0=BE=D1=80=D0=B1=D0=B5=D1=88= =D0=BA=D0=BE =D0=91=D0=BE=D0=B3=D0=B4=D0=B0=D0=BD via Libc-help > > wrote: > > > On 10/04/2024 15:03, Florian Weimer wrote: > > > > * =D0=93=D0=BE=D1=80=D0=B1=D0=B5=D1=88=D0=BA=D0=BE =D0=91=D0=BE=D0= =B3=D0=B4=D0=B0=D0=BD: > > > >=20 > > > > > We already have a solution to build this in Docker, though > > > > > the > > > > > target > > > > > test VPS is tight on resources and I wouldn't really like to > > > > > mess > > > > > with > > > > > Docker there. > > > > You don't have to build on the target system directly, you just > > > > need to > > > > use a container/chroot environment that matches the target > > > > distribution > > > > version.=C2=A0 These containers tend to be fairly lightweight, > > > > requiring > > > > less > > > > space and resources than a full glibc build. > > > An unpacked binary Glibc package takes just 12 MB. A minimal > > > Debian > > > image is orders of magnitude larger. > > >=20 > > > And the primary problem with Docker is that continuous rebuilds > > > occupy > > > the disk space rapidly fast, as it normally preserves old builds, > > > which > > > is not a case with builds on a host system. > > I am confused. Docker may or may not preserve something depending > > on > > how you use it. You're saying compilation on the host system is not > > preserved, which confuses me even further because why would it not. > > Unless you run `make clean && make distclean` sure you have all > > artifacts in place. > The primary difference is that artifacts overwrite the same files, > while=20 > in Docker every difference involves creating new images (or new cache > entries if BuildKit is used) for the whole chain after the layer > where a=20 > change happened. > >=20 > > Anyway. As far as I understand what you're saying you don't want > > Docker > > to preserve a build. I presume it's being "preserved" because > > you're > > building on a host directory that is mount-bound via `-v` option > > (there > > isn't many other ways you'd be getting that. Saving container state > > is > > another one but why would you do that if you don't want the state > > to be > > saved. So it is likely not that). You can solve that by using > > mount- > > bind in such way so that any changes the container does to the > > mound- > > bind will only be visible inside the container. Idk of any ways to > > do > > that in the vanilla Docker, but in Podman it's supported by `:O` > > option, i.e. `-v my_host_dir:/mnt:O`. >=20 > I already added a lot of bind mounts and cache mounts to minimize the > redundancy. Cache mounts are reused between builds, at least. Why are you re-building Glibc in CI in the first place? Are you doing some glibc development, or is it the same Glibc version built over and over? In company I work at we have various 3rd party packages with customizations, and to avoid rebuilding them every time we just store them to a separate repo that is referred by the main project via git- submodule. Works very well.