From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id A93BD398E47F for ; Fri, 12 Mar 2021 13:41:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A93BD398E47F Received: by mail-pg1-x536.google.com with SMTP id o38so15883954pgm.9 for ; Fri, 12 Mar 2021 05:41:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0pXVsESZ8XrEGKEBy/cAayVlVCI1k159E8MSjIU1Hdw=; b=KBbs+5Ed67bjdyz8ErFHxuc5bOxD3j0m05/yLLxxV/DjTPaBvwdV+FCRrTiU0BHWMp bJJl8ruU91QyNH5rBzIuLa6yCSrpLd6NBHj9nyWl+LeIoBc4PqPjZGAqFhID171J2PQ/ Px1q+EI2uZs6u0kicFJAO9tCcGWnywe/UGz8FXuEj3pIYz/W5wAWBRluh7ZtS+9TVTRA sfS+/IzrFUBvAzgPSEYa6kNDh89/Te/R64Kax1Lvi0xsoTgnX0nUI7FytwwFojkre7sm MRAci4Om3q0APIHgYQ2kn4sxTQRKnln9NQcPeX/MinmyKiKgH74i74dyuVibr3dJ5f2C VDGQ== X-Gm-Message-State: AOAM5301iK5Cl6kqwYMYM4q0/jVC72XyiXXjFT/7jUmb+eWYTqDupFv4 NhJ5OkT2UHHPBMtxjGtu2uS1P89UJlosDgoyKVkli9D2v04= X-Google-Smtp-Source: ABdhPJwJGR5bv36qlo4A5FN0YfX3sPa9DO8M+QN9VDbHZ896HG+sCf7r8kcSGvNVBaBuwgwdl6xg8cc/9EW/Txs1ugc= X-Received: by 2002:a63:e203:: with SMTP id q3mr12098592pgh.325.1615556512352; Fri, 12 Mar 2021 05:41:52 -0800 (PST) MIME-Version: 1.0 References: <87a6r87il4.fsf@oldenburg.str.redhat.com> <87sg505zy0.fsf@oldenburg.str.redhat.com> In-Reply-To: <87sg505zy0.fsf@oldenburg.str.redhat.com> From: Alessandro Carminati Date: Fri, 12 Mar 2021 14:41:15 +0100 Message-ID: Subject: Re: Fwd: MIPSEL GLIBC sem_init() not shared To: libc-help@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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 13:41:56 -0000 On Fri, Mar 12, 2021 at 1:17 PM Florian Weimer wrote: > > * Alessandro Carminati via Libc-help: > > > This time was the port on MIPSEL, but before this port, I compiled > > successfully (without -lpthread) on two other architectures: ARM32 and > > x64. Which is the mechanism why in other architecture, the libpthread > > was included and in MIPS it didn't? > > 32-bit Arm starts at GLIBC_2.4, x86-64 starts at GLIBC_2.2.5. The old > versions aren't there, so an underlinked library cannot bind against > them. I noticed this fact, and I wondered if I could change anything in the configuration of the glibc to remove the __old_sem_init. Obviously, I now have a better solution, so I'll stick with that. I also checked the DT_NEEDED in the liba.so in these two architectures. They have libpthread even if I compiled them without -lpthread I must assume this as a specificity of their version of the GCC. > > > My question is, why it resolved the call picking the > > sem_init@GLIBC_2.0 instead of sem_init@@GLIBC_2.2? > > glibc originally did not have symbol versioning, so for backwards > compatibility, unversioned binaries need to pick the oldest available > version. In theory, we could provide better diagnostics. But we're > working on moving all libpthread symbols in to libc.so.6, so that their > versions are always visible to the link editor (unless you link with > -nostdblib, but then you are on your own anyway). That's why the > diagnostics do not seem to be particularly useful in the medium term. What you say makes sense. And explains the behavior I observed in my code. But "unversioned binaries need to pick the oldest available version" is in contrast with what you can read on the internet about the same argument. I must admit that before stepping into this issue, I ignored the symbol versioning even exists. By the way, here's what I found on the internet: http://peeterjoot.com/2019/09/20/an-example-of-linux-glibc-symbol-versioning/ "The @@ one means that it applies to new code, whereas the @MYSTUFF_1.1 is a load only function, and no new code can use that symbol." https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility/ "The @@ tells the dynamic linker that this version is the default version." https://web.archive.org/web/20100430151127/http://www.trevorpounds.com/blog/?33 "The double @@ can only be defined once for a given symbol since it denotes the default version to use." Al the sources I have found seems to agree on the fact that if a symbol is unversioned, like in my case, the symbol the dynamic linker should use is the one that carries the "@@" In my scenario, the symbol which carries the double @@ is the sem_init@@GLIBC_2_2. If the dynamic linker would have picked it, as it should, if I correctly interpret what I read, I wouldn't be here asking. Could you add a comment on that? Thank you Alessandro