On 07/23/15 14:44, David Woodhouse wrote: > On Thu, 2015-07-23 at 14:41 +0200, Laszlo Ersek wrote: >> >>> Right. So what are the options? >>> >>> 1. Push a patch into OpenSSL upstream that marks ERR_add_error_data() >>> and any other varargs functions with EFIAPI. (Ick, no. I can't >>> imagine them accepting that requirement.) >>> >>> 2. Maintain the same patch for ourselves in perpetuity. (Ick, we >>> really don't *want* to be carrying patches, especially like that >>> one.) >>> >>> 3. Switch to -mabi=ms across the board (can we ditch GCC 4.4?) >>> >>> 4. Fix PR#50818. (Doesn't help until we can require a fixed GCC, in >>> which case we might as well just go with option #3). >>> >>> 5. Add -UNO_BUILTIN_VA_FUNCS to OpenSSL build flags or otherwise >>> tweak OpenSslSupport.h to avoid tripping up on it. (As with option >>> #1 and #2, this might work for OpenSSL but I'd rather have a fix >>> for the *general* case of non-explicitly-EFIAPI varargs functions. >>> Those are currently broken on x86_64 ELF builds *anywhere* in >>> Tianocore, right? Like in the PrintString function in >>> DuetPkg/DxeIpl/Debug.c, found with a very quick grep...) >>> >>> Anything I missed? >>> >>> I'm leaning towards a combination of #3 and #5. Switch to -mabi=ms >>> where we can, so the whole mess can go away in time. And the minimal >>> tweak to fix it for OpenSSL builds, although there *are* still issues >>> elsewhere in the tree. >> >> I'd go with #3 (phase out gcc-4.4, hardcode -mabi=ms). > > That's viable for LLVM too, right? It should be.
Andrew?... :) ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
