Hello Andrew and Rebecca,
This issue happens on macOS when the CPATH variable is not set, headers are
stored within the Xcode tools and are not included by default in the path.
export CPATH=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/
Usually fixes it, if you want to know wh
In edk2 speak Base just means does not depend on any phase of boot, so
basically standalone code. So you can pull a Base lib into SEC, PEI, DXE, SMM,
etc.
We never interned different Class Names for libs to map to the same library
class when we designed the build system.
One of the driving f
aren't the Base*Libs there in case you want to override existing
implementations or implement custom versions of them? I'm pretty sure
that's the logic behind it -- its a hack of sorts to try to get OOP out
of a purely procedural language. It works, but I don't think its
necessarily ideal. But
> On May 25, 2022, at 9:23 AM, M.T. wrote:
>
> Hello
>
> I'm working on a small UEFI shell app.
> I was hoping to make use of the JsonLib found in the Redfish Package.
>
> When I include the Redfish JsonLib and it's dependencies:
> JsonLib|RedfishPkg/Library/JsonLib/JsonLib.inf
> Ucs2Utf8Lib|
Cc: Isaac Oram
Cc: Nate DeSimone
Cc: Harikrishna Doppalapudi
Cc: Manickavasakam Karpagavinayagam
Signed-off-by: Sureshkumar Ponnusamy
---
Platform/Intel/WhitleyOpenBoardPkg/JunctionCity/PlatformPkg.dsc | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/Platform/Intel/Wh
I think we need to -D OPENSSL_NO_APPLE_CRYPTO_RANDOM in the INF.
Thanks,
Andrew Fish
> On May 25, 2022, at 7:39 PM, Rebecca Cran wrote:
>
> It's Library/OpensslLib/openssl/include/crypto/rand.h
>
> # include
>
> # if defined(__APPLE__) && !defined(OPENSSL_NO_APPLE_CRYPTO_RANDOM)
> # includ
It's Library/OpensslLib/openssl/include/crypto/rand.h
# include
# if defined(__APPLE__) && !defined(OPENSSL_NO_APPLE_CRYPTO_RANDOM)
# include
# if (defined(__MAC_OS_X_VERSION_MIN_REQUIRED) &&
__MAC_OS_X_VERSION_MIN_REQUIRED >= 101200) || \
(defined(__IPHONE_OS_VERSION_MIN_REQUIRED) &&
What is pulling in Availability.h? That sound more like and #ifdef issue in
some 3rd party header?
I think I might have seen that in SSL headers?
> On May 25, 2022, at 6:26 PM, Rebecca Cran wrote:
>
> Reviewed-by: Rebecca Cran
> Tested-by: Rebecca Cran
>
> This lets the build get further, b
Reviewed-by: Bob Feng
-Original Message-
From: Yang, Jie
Sent: Thursday, May 19, 2022 4:22 PM
To: devel@edk2.groups.io
Cc: Feng, Bob C ; Gao, Liming ;
Chen, Christine ; Yang, Jie
Subject: [PATCH] [edk2-staging] [PATCH] BaseTools/Bfm: Fix "-g" input FV is not
BFV issue
FCE tool provi
Reviewed-by: Rebecca Cran
Tested-by: Rebecca Cran
This lets the build get further, before it runs into Availability.h not
being found.
If I download
http://opensource.apple.com/source/CarbonHeaders/CarbonHeaders-18.1/Availability.h
and
http://opensource.apple.com/source/CarbonHeaders/Carbo
Sounds good. :-)
From: Pedro Falcato
Sent: Thursday, May 26, 2022 7:54 AM
To: edk2-devel-groups-io ; Yao, Jiewen
Cc: Ard Biesheuvel ; Rebecca Cran ;
Ard Biesheuvel ; Justen, Jordan L
; Gerd Hoffmann
Subject: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3)
NOOPT - undef
From: Theo Jehl
Removed prefix to match AsmRelocateApMailBoxLoopStart declaration.
This fixes a compilation issue.
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Jordan Justen
Cc: Gerd Hoffmann
Signed-off-by: Jehl Theo
---
OvmfPkg/TdxDxe/X64/ApRunLoop.nasm | 2 +-
1 file changed, 1 insertion(+), 1
Jiewen,
I'm definitely talking about the long term. Fixing this by just replacing
it with CopyMem is definitely the right call for the stable tag.
Best regards,
Pedro
On Thu, May 26, 2022 at 12:35 AM Yao, Jiewen wrote:
> OK. Just want to clarify:
>
>
>
>1. Are you discussing the solution n
Thanks to catch this. Look forward to the patch.
I hope this can be resolved in this stable tag.
The mismatch on ASM_PFX seems a big problem.
If we can extend CI to catch it earlier, that would be great.
Thank you
Yao Jiewen
From: Pedro Falcato
Sent: Thursday, May 26, 2022 2:03 AM
To: edk2-deve
OK. Just want to clarify:
1. Are you discussing the solution now to resolve this issue, maybe in this
stable tag?
2. Or are you discussing the long term solution?
For me, I am focusing on #1 how to resolve this issue in this stable tag.
I am not talking long term solution #2 here. I thin
Right. But as I said, GCC and Clang depend on 4 standard C library
functions. This behavior is documented, and has been stable for probably
the past decade or more. These are not intrinsics, but bog standard
functions you can totally redirect to the existing UEFI ones. I talked with
the LLVM people
“Don’t use structure assignment” is our best known method to avoid compiler
intrinsic in EDKII coding style since the project is created.
A third part library may include structure assignment, then we have to link
intrinsic.
If you only talk about memcpy, that is easy. But there might be others.
Is there a legitimate reason not to define memcpy? It'd be easier to do so
and comply to the compiler's requirements.
On Wed, 25 May 2022, 23:38 Yao, Jiewen, wrote:
> Hi
>
> Would you please use CopyMem() for the structure assignment?
>
> VgpuGop->GopModeInfo = *GopModeInfo;
>
>
>
> That is bes
Hi
Would you please use CopyMem() for the structure assignment?
VgpuGop->GopModeInfo = *GopModeInfo;
That is best known method to resolve memcpy symbol issue.
Thank you
Yao Jiewen
From: Pedro Falcato
Sent: Thursday, May 26, 2022 1:01 AM
To: Ard Biesheuvel
Cc: edk2-devel-groups-io ; Rebecca C
Hi Ayush,
Welcome! I'm excited about this project too and I look forward to
working you.
We will be reaching out soon to set up our regularly scheduled
discussions and meet you.
Regards,
Michael
On 5/21/2022 1:09 AM, Ayush Singh wrote:
Hello Everyone,
I am Ayush Singh, a 2nd-year univers
On Mon, May 23, 2022 at 11:24 PM, Gerd Hoffmann wrote:
>
> On Mon, May 23, 2022 at 04:48:05AM -0700, Albecki, Mateusz wrote:
>
>> @Ni, Ray
>>
>> I think EDK2 needs to provide a way for root port to operate without IO
>> space assigned in a platform-independent way. I can think of the following
Hi Rebecca,
That does indeed look like a bug for toolchains that prepend the underscore.
Our GSoC student already caught that bug and he's going to submit a patch
as soon as possible to fix it.
Mind waiting a few hours? This is a really nice way for him to learn the
ropes WRT edk2 patches :)
On W
Correction:
1. if a .LIB is passed to the linker instead, the linker searches the .LIB
for a particular
symbol (e.g. function, data). The specific .OBJ module that holds that
particular symbol, is
linked to the target.EFI.
(the linker creates an link-error, like yours, if one or more symbo
Hi xp,
your build failure is
1. the result of a “link-all” mechanism
or
2. the result of a library construction flaw that is commonly used in
EDK2.
or both
Let me explain the theory:
1. an .OBJ file is created by the compiler for each .C source code file
an .OBJ is considered
On Wed, May 25, 2022 at 5:45 PM Ard Biesheuvel wrote:
> On Wed, 25 May 2022 at 18:44, Pedro Falcato
> wrote:
> >
> >
> >
> > On Wed, May 25, 2022 at 4:50 PM Ard Biesheuvel wrote:
> >>
> >> On Wed, 25 May 2022 at 17:08, Rebecca Cran
> wrote:
> >> >
> >> > I noticed OvmfPkg/OvmfPkgX64.dsc doesn'
On 5/25/22 10:43, Pedro Falcato wrote:
On Wed, May 25, 2022 at 4:50 PM Ard Biesheuvel wrote:
On Wed, 25 May 2022 at 17:08, Rebecca Cran
wrote:
>
> I noticed OvmfPkg/OvmfPkgX64.dsc doesn't build with `-t CLANG38 -b
> NOOPT` (with clang version 14.0.2) with the latest edk2
I noticed OvmfPkg/OvmfPkgX64.dsc doesn't build with `-t XCODE5` (with
Apple clang 12.0.5)) with the latest edk2 master
(07c0c2eb0a5970db614ebce1060fc79d6904bdfd).
GenSec -s EFI_SECTION_VERSION -n 1.0 -o
/Users/bcran/src/uefi/edk2/Build/OvmfX64/DEBUG_XCODE5/FV/Ffs/BDCE85BB-FBAA-4f4e-9264-501A2
On Wed, 25 May 2022 at 18:44, Pedro Falcato wrote:
>
>
>
> On Wed, May 25, 2022 at 4:50 PM Ard Biesheuvel wrote:
>>
>> On Wed, 25 May 2022 at 17:08, Rebecca Cran wrote:
>> >
>> > I noticed OvmfPkg/OvmfPkgX64.dsc doesn't build with `-t CLANG38 -b
>> > NOOPT` (with clang version 14.0.2) with the l
On Wed, May 25, 2022 at 4:50 PM Ard Biesheuvel wrote:
> On Wed, 25 May 2022 at 17:08, Rebecca Cran wrote:
> >
> > I noticed OvmfPkg/OvmfPkgX64.dsc doesn't build with `-t CLANG38 -b
> > NOOPT` (with clang version 14.0.2) with the latest edk2 master
> > (07c0c2eb0a5970db614ebce1060fc79d6904bdfd):
Hello
I'm working on a small UEFI shell app.
I was hoping to make use of the JsonLib found in the Redfish Package.
When I include the Redfish JsonLib and it's dependencies:
JsonLib|RedfishPkg/Library/JsonLib/JsonLib.inf
Ucs2Utf8Lib|RedfishPkg/Library/BaseUcs2Utf8Lib/BaseUcs2Utf8Lib.inf
RedfishCrt
On Wed, 25 May 2022 at 17:08, Rebecca Cran wrote:
>
> I noticed OvmfPkg/OvmfPkgX64.dsc doesn't build with `-t CLANG38 -b
> NOOPT` (with clang version 14.0.2) with the latest edk2 master
> (07c0c2eb0a5970db614ebce1060fc79d6904bdfd):
>
> make: Nothing to be done for 'tbuild'.
> /usr/bin/ld: /usr/bin
I noticed OvmfPkg/OvmfPkgX64.dsc doesn't build with `-t CLANG38 -b
NOOPT` (with clang version 14.0.2) with the latest edk2 master
(07c0c2eb0a5970db614ebce1060fc79d6904bdfd):
make: Nothing to be done for 'tbuild'.
/usr/bin/ld: /usr/bin/ld: DWARF error: invalid or unhandled FORM value:
0x23
/hom
Merged https://github.com/tianocore/edk2/pull/2915
> -Original Message-
> From: Yao, Jiewen
> Sent: Wednesday, May 25, 2022 11:01 AM
> To: 'gaoliming' ; devel@edk2.groups.io; Xu, Min
> M ; Yamahata, Isaku
> Subject: RE: [edk2-devel] [PATCH] OvmfPkg: TdxDxe: Fix
> AsmRelocateApMailBoxLoop
Merged https://github.com/tianocore/edk2/pull/2916
> -Original Message-
> From: Yao, Jiewen
> Sent: Wednesday, May 25, 2022 11:00 AM
> To: devel@edk2.groups.io; Gao, Liming ;
> kra...@redhat.com
> Cc: 'Pawel Polawski' ; 'Oliver Steffen'
> ; 'Laszlo Ersek'
> Subject: RE: [edk2-devel] [PATC
Thanks a lot!
Joey Lee
On Tue, May 24, 2022 at 03:27:32PM +, Kinney, Michael D wrote:
> The details are on this Wiki page
>
> https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Issues
>
> Mike
>
> > -Original Message-
> > From: devel@edk2.groups.io On Behalf Of joeyli
35 matches
Mail list logo
