From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by mx.groups.io with SMTP id smtpd.web10.7272.1643379248441171890
 for <devel@edk2.groups.io>;
 Fri, 28 Jan 2022 06:14:08 -0800
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=MgrDx4uB;
 spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1643379247;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=QUQSQWuHnkCgysR5j4fDrSe+KhZ9s6COCgAi0b/icfY=;
	b=MgrDx4uBf1eotxJFGIFoywuIlroJDy9u0Uft80HmKXJhhzUinsy07KHOIdHZsBPw54yjLc
	9v6n/lTkfTXyKfTG8cTJ5nG5IXHICOuJS2MaCv6WRtJYFpMhBWpdM8tKWc/cMqLFB1UqKg
	7iDH0qE7MDkDmTlwHhR6a1UpC7R71ug=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 us-mta-573-F66r8qKvMs6Yo0NWEzIpXg-1; Fri, 28 Jan 2022 09:14:06 -0500
X-MC-Unique: F66r8qKvMs6Yo0NWEzIpXg-1
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4EDB783DD21
	for <devel@edk2.groups.io>; Fri, 28 Jan 2022 14:14:05 +0000 (UTC)
Received: from sirius.home.kraxel.org (unknown [10.39.193.47])
	by smtp.corp.redhat.com (Postfix) with ESMTPS id 0CFE16D032
	for <devel@edk2.groups.io>; Fri, 28 Jan 2022 14:14:04 +0000 (UTC)
Received: by sirius.home.kraxel.org (Postfix, from userid 1000)
	id E339C180060D; Fri, 28 Jan 2022 15:14:02 +0100 (CET)
Date: Fri, 28 Jan 2022 15:14:02 +0100
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl submodule to v3.0
Message-ID: <20220128141402.3poowxc7mglbrih6@sirius.home.kraxel.org>
References: <20220128140723.isljt6lz6the7k5y@sirius.home.kraxel.org>
MIME-Version: 1.0
In-Reply-To: <20220128140723.isljt6lz6the7k5y@sirius.home.kraxel.org>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
Authentication-Results: relay.mimecast.com;
	auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

  Hi,

> -DEFINE GCC_DLINK2_FLAGS_COMMON     = -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
> +DEFINE GCC_DLINK2_FLAGS_COMMON     = -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds -lgcc
> 
> Build doesn't come very far.  Looks like the gcc intrinsics are not
> free-standing but want call into libc:
> 
> /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_absvsi2.o): in function `__absvdi2':
> (.text+0x18): undefined reference to `abort'

> Not sure why the linker tries
> to resolve symbols for object files which should not be needed in the
> first place.  Possibly something else is fishy here, any hints are
> welcome.  Something in the linker script maybe?

So, digged a bit more into this.  When unpacking libgcc.a, then packing
a new lib with only the object files needed, and pass that to the linker
everything works fine.

In theory just using -lgcc should have the same effect, especially when
it comes last on the command line so even in case of a symbol being
defined in both tianocore and libgcc the linker should prefer the
tianocore version.  In practice that is not the case.  Debugging to be
continued next week ...

take care,
  Gerd