Jim,
Could you try to build Juno AARCH64 UEFI image from Tianocore EDK II & Linaro OpenPlatformPkg to see if the error persists?
Alexei.
-----Original Message----- From: Jim Wilson [mailto:jim.wilson@linaro.org] Sent: 22 February 2017 17:20 To: Evan Lloyd Evan.Lloyd@arm.com Cc: Leif Lindholm leif.lindholm@linaro.org; ard.biesheuvel@linaro.org; Mitch Ishihara Mitch.Ishihara@arm.com; Girish Pathak Girish.Pathak@arm.com; linaro-toolchain@lists.linaro.org; ryan.harkin@linaro.org; linaro-uefi@lists.linaro.org; Alexei Fedorov Alexei.Fedorov@arm.com; Sami Mujawar Sami.Mujawar@arm.com Subject: Re: Problem with building AML file from Dsdt.asl for Juno
On Wed, Feb 22, 2017 at 4:51 AM, Evan Lloyd Evan.Lloyd@arm.com wrote:
I doubt that gcc is messing with file names. I would suspect a newlib change.
So does that imply the GCC behaviour change will not get reverted?
I haven't seen a GCC behaviour change yet. I got the mingw32 gcc-linaro-5.3-2016.05 working. When I run gcc -E on a TMP.C file that includes a TMP.H file, I see both TMP.C ahd TMP.H in the -E output as expected. I see the same behaviour from a mingw gcc-linaro-4.9-2016.02. Unfortunately, I can't run any linaro release I've tried from 2016.08 or later and I don't know why. I don't know what you might be doing different that might be generating different results.
I looked at the gcc and newlib sources, but I don't see anything obvious downcasing filenames except for some filename hash table code in libiberty which doesn't appear to be used by either gcc or newlib.
Jim IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.