From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 6B0BF398B434 for ; Fri, 12 Mar 2021 10:49:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6B0BF398B434 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-589-qzJKbMYMOR-NnLdNcGwCjA-1; Fri, 12 Mar 2021 05:49:01 -0500 X-MC-Unique: qzJKbMYMOR-NnLdNcGwCjA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 895CF84B9A9; Fri, 12 Mar 2021 10:49:00 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-112-77.ams2.redhat.com [10.36.112.77]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AF58D5C255; Fri, 12 Mar 2021 10:48:59 +0000 (UTC) From: Florian Weimer To: Alessandro Carminati via Libc-help Cc: Alessandro Carminati Subject: Re: MIPSEL GLIBC sem_init() not shared References: Date: Fri, 12 Mar 2021 11:49:11 +0100 In-Reply-To: (Alessandro Carminati via Libc-help's message of "Fri, 12 Mar 2021 10:31:33 +0100") Message-ID: <87a6r87il4.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 10:49:11 -0000 * Alessandro Carminati via Libc-help: > But looking at the liba.so dependencies, I've been surprised by the > fact that the library depends only on the main libc library > (libc.so.6) and has no dependency on libpthread.so.0 where the actual > sem_* symbols are implemented. > > $ /lib/ld-2.31.so --list /usr/lib/liba.so > linux-vdso.so.1 (0x7ffaa000) > libc.so.6 => /lib/libc.so.6 (0x77ddc000) > /lib/ld-2.31.so (0x77f8a000) > > I guess this might be related to my problem, but I have no clue how to > link these two facts. How the liba.so could be compiled and linked > using symbols its dependencies do not provide? This is called underlinking. It produces invalid objects. > How to force the GNU linker to link against sem_init@@GLIBC_2.2 > instead of sem_init@GLIBC_2.0? Just link with -lpthread, it will add the symbol version and call the right function. We are working on changes to glibc that makes it much less likely that such underlink can happen, so hopefully such difficult-to-debug problems will become a non-issue at some point in the future. Thanks, Florian