From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id 45D383846400 for ; Wed, 10 Apr 2024 14:02:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 45D383846400 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 45D383846400 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::536 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712757782; cv=none; b=jelKR9Mqpyc/HGRwy6VzYyB+o1x55hqGtxyW+kGiJXBU34IvHvPmFkhpbKAj6j04d2fikz8NyevP1JnMsAoardJBg4/ASFSGGa12rghusUTcsgr9G63XvQKyFvFDHuLVO8T1ATvbDMGMe/tQ7hfi+eX4gSXNw/Vu8v9C3dC04aA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712757782; c=relaxed/simple; bh=EvcRJZgT0yC+EWtSmM8HaQ5+NcAetFPoyP29CZj3nlY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=ENEy2dDkQwtTGcRfGJcOzBtV1NJDtgFTyDvwcd58IZalqAI07uMow8i8XgAWDl3HtrMZ4p82wzBhDbKsLq4cnVAHoA35gbuFK2QWX/vOz5dpZUiclhYGmB5Cv5xeEOgECjxzxO0Gb76ICeVJjJP8n8X45o65aGedPtj4S05Z+wM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-56c5d05128dso7626384a12.0 for ; Wed, 10 Apr 2024 07:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712757771; x=1713362571; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=21B9sZwg987YTybAfODRzIci0EF9IHvlpmP3KMCGGbc=; b=lGZ62s866/8ryPb0bIvk2TBPzvEgqWDvPrh6neI2BzWQKCjkgX5wOmu+2RHoOxrULw EkETf9QNwl2rwYsXWHcdRT0/btx3v7pu6g6p+fk45VlozS6eQer3JnsFRtdn6DZguQ2I G7RSUBq3yEgRPRl1tNeUub2heTG8i+G3PYQvtFsUO5x0Frx06qm54ajqXJpakYQZzVTw kZL0MrarTruVk5Yz+XGp7jVagi3Xewosbrle8PEgnEPactej6mvbVSOFYRnIi/77NX8s rjZ7gwVIgTI1jI6budpv2VgSKmsAxC9lkwDkMsL2RgjyNdqr1+zZnDpqrJgaISvduA1H 7qXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712757771; x=1713362571; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=21B9sZwg987YTybAfODRzIci0EF9IHvlpmP3KMCGGbc=; b=AEabqFYcYoHCigpcT6jhBNd3ynAyDK9PeoYAabhCX551PV4f5BBVzrP6ZH9eQ7k24U SFcS0QNEGgxInGK0aj7xefGI/hp04QoaT99UFNj4WIZWZxZCAzXxR1KM/3yQX0OLmbdX 5PX/HiPM8L1/OmSxLV7PsyXcmMWZKel+/ecsY70teryGhB0qd9kY80Rzrb5FqswRXipq eVXNsLTRVF57Y38uodr7slnGZkEWfyvCldJvQN9tmYfjBCrJmTzEUkGVb/ou4We0OcWQ /6WjOfawnkjDKBZ8BDK92ft+MdJOMvaBZuV8smaZidKFc51jB0/fDq+Qe9DtR0yWnqNs gZDg== X-Gm-Message-State: AOJu0Yz5ujum6h3m6OR1lQxFGtx736/Akmucl8lyojtaP7F0tSrEZB9R 0+3xwzVU2Ap7v+uNjMZmF0sIw+EYdDpD4JFblVmCYATlIztk4s6r X-Google-Smtp-Source: AGHT+IG2GVpgQHWEE2CSB1iT99GkW+ZnBKSaJttV44Nz+cxRQPu7NgAxytem4B3OJ/O1mU2BGQHRug== X-Received: by 2002:a17:906:2b0f:b0:a52:16c4:ab02 with SMTP id a15-20020a1709062b0f00b00a5216c4ab02mr383309ejg.50.1712757770332; Wed, 10 Apr 2024 07:02:50 -0700 (PDT) Received: from [0.0.0.0] ([94.177.207.80]) by smtp.googlemail.com with ESMTPSA id a23-20020a1709062b1700b00a51dd26f6dcsm3337476ejg.51.2024.04.10.07.02.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Apr 2024 07:02:49 -0700 (PDT) Message-ID: <8d30eecc-cd44-4718-a312-6256e6c6e13e@gmail.com> Date: Wed, 10 Apr 2024 17:02:48 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: libstdc++ link errors in support/links-dso-program To: Konstantin Kharlamov , Florian Weimer Cc: =?UTF-8?B?0JPQvtGA0LHQtdGI0LrQviDQkdC+0LPQtNCw0L0gdmlhIExpYmMtaGVscA==?= 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> <47702d90c552af639e1e00e201dc850c01dace35.camel@yandex.ru> Content-Language: en-US From: =?UTF-8?B?0JPQvtGA0LHQtdGI0LrQviDQkdC+0LPQtNCw0L0=?= In-Reply-To: <47702d90c552af639e1e00e201dc850c01dace35.camel@yandex.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=3.1 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 10/04/2024 16:55, Konstantin Kharlamov wrote: > On Wed, 2024-04-10 at 16:30 +0300, Горбешко Богдан wrote: >> On 10/04/2024 16:22, Konstantin Kharlamov wrote: >>> On Wed, 2024-04-10 at 15:50 +0300, Горбешко Богдан via Libc-help >>> wrote: >>>> On 10/04/2024 15:03, Florian Weimer wrote: >>>>> * Горбешко Богдан: >>>>> >>>>>> 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.  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. >>>> >>>> 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 >> 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 >> change happened. >>> 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`. >> 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? It's not a CI and I don't need a patched Glibc actually. I mentioned already that I'm just cross-compiling a Golang project to be run and tested during development frequently on an older distribution. > > 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.