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. -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
