I checkout latest stable tag: edk2-stable202205 I use VS2015 toolchain. It works on my side…

git clone --recursive https://github.com/tianocore/edk2.git That works! You forgot “—recursive”

Hi xp, Sorry: I didn’t suggest, I just explained the root cause for such trouble. That is true for all tool chains. But, comparing the two library files from the sourcecode MdeModulePkg tells me, that

Correction: 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

Hi xp, your build failure is 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: an .OBJ file is crea

Hi Gerd, additionally I would suggest once more to adjust the DLINK_FLAGS in tools_def.txt to hold CompilerNameINTRIN32/64.LIB as a search library as already introduced in https://edk2.groups.io/g/dev

Hi, If the source code below was linkable for all UEFI targets PEI+DXE+SMM+Shell, then the most urgent integer/memset()/memcpy() issues would be gone. NOTE: The program can not run anywhere. > That me

Hi Andrew, hi Mike, hi Gerd, >Very cool idea but … The good news: A common solution for the / % << >> C operator issue for all platforms is in sight for 64Bit integers. I will discuss my findings alon

Hi Pedro, what are you talking about? Please send disassemblies, map files, C samples programs. Let’s focusing on the most urgent intrinsic function needed for / % << and >> operators first. Quick not

Hi Gerd, >* On my system the gcc intrinsics are only available as shared library, > so the "just unpack the lib and use the object files" idea is not > going to work. This little C program makes an un

Hi Mike, thank you for your explanation. I understand all the technical aspects. But let me go into the details of my approach, that skips step 2) to 5) and adds step 1.5) >I think in practice, the in

The 64-bit integer math intrinsics and other intrinsic problems could be solved easily for ever: Putting all .OBJ files together from LIBCMT.H or INT64.LIB (for ll*.obj and ull*.obj only) ltod3.obj ft

Hi Andrew, hi Jordan, hi Maciej, hi all, this task was suggested by @ajfish and @jljusten at tianocore / tianocore.github.io: https://github.com/tianocore/tianocore.github.io/wiki/Tasks#port-acpi-ca-t

Hi Maciej, hi all, I didn’t get any feedback from you, what exactly you would like CdePkg to do for Redfish. So I chose to demonstrate all functions from wchar.h and wctype.h that are implemented in t

Hi Maciej, hi all, regrettably the announced CdePkgBlog for today is still under process and will be published next Sunday. And also the schedule for the other CdePkgBlogs has changed: Here are some i

Hi All, as announced in my last CdePkgBlog I’d like to demonstrate how to design, create and build missing tools for the UEFI Shell, that are still known today from the Windows command line: FIND and

Hi Maciej, CdePkg is already integrated into EDK2 and satisfies all your needs for pre-/post-memory PEI, DXE, (SMM in latest releases only), BDS and UEFI Shell too. I have introduced CdePkg for POST u

Hi All, as announced last summer, I’d like to start a comprehensive tutorial on how to use Standard C / ANSI C in the UEFI environment and how to design and implement such a library for Shell and POST

Hi Maciej, I have updated and fixed build errors in branch CdePkg (https://github.com/tianocore/edk2-staging.git). Also a POST trace is recorded on my MinnowBoard and stored here: https://raw.githubus

Hi all, I plan to come back with the https://github.com/tianocore/edk2-staging/tree/CdePkg end of this year and to unroll the source code of fundamental parts of my C Library and discuss that along th