From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by mx.groups.io with SMTP id smtpd.web11.1251.1585604487064572820 for ; Mon, 30 Mar 2020 14:41:27 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=jKJ52Vy2; spf=pass (domain: linaro.org, ip: 209.85.128.68, mailfrom: ard.biesheuvel@linaro.org) Received: by mail-wm1-f68.google.com with SMTP id e9so446606wme.4 for ; Mon, 30 Mar 2020 14:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=87kzFZRHZZoUFloyTiZhvnaZYCVwn+ijnjoXmVQix1k=; b=jKJ52Vy25YN7LLL8vgb9vLFVs6GBlkzxyM0gKMgihf9+3HAeBwlhJ7cL5LiyI6acyK YxocR4KpAklRDp/tqavusMZec//AqS8JSafXq9cX3CVus9qw/RS+j0B5yH2d8sp5spe3 FAeqsYXavzhLXjCUdcXZ0maPovUyhiEmFxnegiM5/05UGMHoWx4FvP1GWzmC/Tsjo1+4 Rposam2fea0o9CCWBNtrHzZLPq25j6UV4pQkolDPzf4mquH4Y+/jFmG2L9i1tKIs+49k TZaMiw2xeJ4PbssZO4tmp9iNNNviWnSSvVc4brJvhHXv0xUD8wjzG/cqQ8at6gac6w7/ khRQ== 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:cc:content-transfer-encoding; bh=87kzFZRHZZoUFloyTiZhvnaZYCVwn+ijnjoXmVQix1k=; b=Y5+4B+dGz/xv0+SO/GOUgbN2Zf6qoVHdVtM7QpsSP7gAL5UsRZs2ZAKz9hNOZMNtJ1 TB8iUZneIHeULpkgaMNuarRr3fBMMZmNrfIr5zWPk02wC82dclMkKEdHCNpNspW6e/oy xYegWuRKDZGCmwsDgeh4IVghCH3N6mAGzJeM1Bb0CWygpYimNbuU8gJrW7awU5EZVigA il2XYZc/kVh37oYZZls9xGilEG+wu8dQYpTOFZe1T+3M2FE+hp/TQp081OxixJ9Cdcoh V8jwgBuFSTcdnmgW7fJN4pjY2doQfeu8B6cpX+7kMRYOHeuV4Wh4Uabsa11ZH1giCCek yS4A== X-Gm-Message-State: ANhLgQ3I4/J1c3eFrBQG1PRcDKSaeu1pOH34GcnXPB5ZZcdEGR1Blp/M qymO3kq4vF8cKKclu4ft/rfJbXMZlb641LL5U/xDOMbYHFs= X-Google-Smtp-Source: ADFU+vt0i+6GU9uPTlmxYDmR2aBaiZkQTI6XeKN+RghwB/emM1OQLuFvmCmu6mDlVTeRDbYZApxhASOj2jOc+QPXXoo= X-Received: by 2002:a7b:cb81:: with SMTP id m1mr120480wmi.1.1585604484966; Mon, 30 Mar 2020 14:41:24 -0700 (PDT) MIME-Version: 1.0 References: <03f18a49-6bd6-e753-e1bf-7e061d13f200@redhat.com> <14537.1585603662366515487@groups.io> In-Reply-To: <14537.1585603662366515487@groups.io> From: "Ard Biesheuvel" Date: Mon, 30 Mar 2020 23:41:13 +0200 Message-ID: Subject: Re: [edk2-devel] [PATCH] CryptoPkg/FltUsedLib: Add FltUsedLib for float. To: edk2-devel-groups-io , macarl@microsoft.com Cc: Laszlo Ersek Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 30 Mar 2020 at 23:29, Matthew Carlson via Groups.Io wrote: > > So it's not required by OpenSSL, it's required by the compiler whenever f= loating point is used, which can be in multiple places. For example, this i= s used in mu_plus (the Microsoft UEFI value add to EDK2) by the OnScreenKey= board driver as well as the UiToolKit driver. If you happen to use BaseCryp= tLib or the intrinsic in a driver that happens to need crypto as well, it c= an break due to multiple. > > I do agree, this only applies to MSVC and requiring every platform to add= a line in their DSC would be a situation I would prefer to avoid if possib= le. Is there a way to specify a library dependency only if a toolchain is b= eing used? Yes, so this either belongs in one of the IntrinsicsLibs we have, or in the various Entrypoint libraries we have for PEIMs, DXEs, etc. However, given that we are talking about static libraries here, adding a source file that *only* defines __fltused (and nothing else) to any library should also work, as the resulting object file will only be incorporated by the linker if it is needed to satisfy a symbol dependency, and so it can never cause a conflict if it is the only symbol in the object.