From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) by sourceware.org (Postfix) with ESMTPS id BDDFE3858D28 for ; Mon, 10 Jan 2022 13:26:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BDDFE3858D28 Received: by mail-ua1-x92d.google.com with SMTP id p37so23348790uae.8 for ; Mon, 10 Jan 2022 05:26:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=Pc+1WhXy19L0rRYKPD34tmDzfAE/CSFSXERN9sf/xGw=; b=PRJlu2FMWTk7ZcJQkNgySUBdMjuDxTB3qw7Mjs4knmSLQ5/yAZaCM/TcTrtgvLuSi1 IDVupS4unzAYL2x0NESZGvt+ZjSrS61P33AIQmqmCfPClp9oD1CvR9DB+HIC3AzfnbLP 0SY30Kp1XWh5aGjZe/Sg79FwDi1bPbnWk65W4glcXEQ4H0G1QzDySrZpQNxy+PLsQL44 ++zOH5LkNQxledq7/p/fne5XodvTjINYP1pW4G2D7+OtyGTFUItvXvS0YRbxgy3kOUmL /HDFI1qQ07WM4CXUBmTE9gi8Th+bmF014qvbSjTBqDE55bthWrR4V4l8NF50/ZaQX+8x bcFA== X-Gm-Message-State: AOAM531svrhkrj7Stw0fq9rJApD7tExndUsYiUZggCwqi7Z1eK4yl38+ 99qyO5YhqQV+TsSeow9yIkfPrJEzB+Lc7g== X-Google-Smtp-Source: ABdhPJy5dXP44n4As9iQvEIi3dG2D99M6T0AyCG/aB/PkPGTcWTpCJzdk/PEoHRL8izEXlEZoPk+zA== X-Received: by 2002:a05:6102:d8a:: with SMTP id d10mr14652722vst.47.1641821216134; Mon, 10 Jan 2022 05:26:56 -0800 (PST) Received: from ?IPV6:2804:431:c7ca:9d3:3f97:8103:cbb:d524? ([2804:431:c7ca:9d3:3f97:8103:cbb:d524]) by smtp.gmail.com with ESMTPSA id l8sm4086824vse.28.2022.01.10.05.26.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Jan 2022 05:26:55 -0800 (PST) Message-ID: Date: Mon, 10 Jan 2022 10:26:54 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: Why -static-libgcc? (Or: Do we need a build-time libc.so linker script?) Content-Language: en-US To: libc-alpha@sourceware.org References: <87y25dmc7k.fsf@oldenburg.str.redhat.com> <87v8yrycco.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella In-Reply-To: <87v8yrycco.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_BLACK autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 13:26:58 -0000 On 10/01/2022 10:00, Florian Weimer via Libc-alpha wrote: > * Joseph Myers: > >> On Wed, 24 Nov 2021, Florian Weimer via Libc-alpha wrote: >> >>> Why do we use -static-libgcc? Doesn't this invalidate some of our >>> tests, because users do not generally build with -static-libgcc? >> >> There is a principle that (a) building glibc should not require a GCC >> built with shared libgcc (to avoid circular dependencies, because building >> shared libgcc requires having first built shared libc) and (b) if you >> build glibc with a static-only C-only inhibit_libc GCC, the resulting >> stripped binaries should be identical to those you get from a longer >> alternating sequence of GCC and glibc builds (in particular, the binaries >> should be identical to those you get from building with shared libgcc >> available) > > I agree that this is a useful goal. > >> So building installed shared libraries needs to avoid any dependence on >> shared libgcc (unless such dependence is handled in a way not requiring >> shared libgcc to be available at build time - note that we know the >> libgcc_s SONAME via shlib-versions, so if desired we could insert a >> DT_NEEDED for it without using the real library, by building a dummy >> shared library to link against or otherwise). > > I think we could still build without -static-libgcc and check that the > installed shared objects do not contain a DT_NEEDED references to > libgcc_s. But it will not fix the test linking issue I encountered > (libgcc_eh.a references not resolvable against ld.so because of > --as-needed and link order). > > Do we really need to support building the test suite against a > static-only GCC build? I am not sure it makes sense since we do require a libgcc_s.so to have the cancellation and stack unwinding to work. > > This is not an urgent issue because direct symbol access to ld.so is > incompatible with static dlopen because it the inner namespace binds to > the uninitialized copy of ld.so, so things like __tls_get_addr do not > work. For some application scenarios, this is probably okay, but for > parts of libgcc_s (libgcc_eh.a especially), not so much. > > Thanks, > Florian >