Re: [edk2] Compiling issues when using UNIX/cross compile environment

Subject: Re: [edk2] Compiling issues when using UNIX/cross compile environment

From: Laszlo Ersek <>

To: Bill Paul <>

Date: 2014-02-04 07:36:03

On 02/03/14 23:02, Bill Paul wrote:
> Since I'm building on FreeBSD, I'm using the generic UNIX instructions for 
> building with the EDK2. This means I'm using the cross-compiler tools 
> generated by the script.

(BaseTools/gcc/README.txt seems to imply that the output of these
scripts are not (regularly) tested on FreeBSD.)

> For the most part this works fine, but I noticed that when I build OVMF, I see 
> the following warnings:
> edk2/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c: In function 
> 'FvbGetPhysicalAddress':
> edk2/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c:249: error: 
> 'FwhInstance' may be used uninitialized in this function

> This appears to be due to lines like this:
>   EFI_FW_VOL_INSTANCE *FwhInstance;
> which should be this:
>   EFI_FW_VOL_INSTANCE *FwhInstance = NULL;
> This is easily corrected, but I'm wondering why nobody else seems to have 
> noticed it. Maybe newer versions of GCC ignore it?

At least in FvbGetPhysicalAddress(), there's an
ASSERT_EFI_ERROR(Status). Gcc's warning is incorrect (at least in DEBUG
builds). I guess newer gcc versions might deduce that.

> Maybe people are using 
> Windows?


> Also, I also noticed a few glitches when trying to build the sample apps in 
> AppPkg.
> For example:
> edk2/StdLib/BsdSocketLib/ns_print.c: In function '__ns_sprintrrf':
> edk2/StdLib/BsdSocketLib/ns_print.c:231: error: format '%Lu' expects type 
> 'long long unsigned int', but argument 3 has type 'u_long'
> edk2/StdLib/BsdSocketLib/ns_print.c:519: error: format '%Lu' expects type 
> 'long long unsigned int', but argument 5 has type 'u_long'
> Apparently it wants the %Lu to be just %u

Seems like a genuine bug (when built for Ia32).

> Similarly:
> edk2/StdLib/BsdSocketLib/res_debug.c: In function '__p_option':
> edk2/StdLib/BsdSocketLib/res_debug.c:539: error: format '%Lx' expects type 
> 'long long unsigned int', but argument 3 has type 'u_long'
> %Lx should be %x
> Lastly, during the link phase, I get errors like this:
> edk2/Build/AppPkg/RELEASE_UNIXGCC/IA32/StdLib/EfiSocketLib/EfiSocketLib/OUTPUT/EfiSocketLib.lib(Init.obj):/home/wpaul/edk/edk2/StdLib/EfiSocketLib/Init.c:57: 
> undefined reference to `mpfnEslConstructor'
> This is defined in StdLib/EfiSocketLib/UseEfiSocketLib.c along with a bunch of 
> other globals as follows:
> PFN_ESL_xSTRUCTOR mpfnEslConstructor __attribute__((weak)) = 
> EslServiceNetworkConnect;    ///<  Constructor for EfiSocketLib
> The issue seems to be that when using the weak attribute, the compiler ends up 
> producing objects with symbols like this:
> 00000000 D .weak._mpfnEslConstructor._EslServiceNetworkDisconnect
> The linker seems unable to resolve them because of the .weak prefix. I hacked 
> around this in my local tree by just getting rid of the __attribute__((weak)) 
> tag.

The weak attribute comes from SVN r13475, but the commit message doesn't
explain to me why the attribute was necessary.

> It's possible that all of this may be attributable to the cross compiler 
> toolchain being out of date, but these seem like genuine bugs to me. Again, 
> I'm surprised they haven't been noticed before.

You could be the first user ever to try to build these on FreeBSD, with
the UNIXGCC toolset. Can you try with GCC44+ instead?

(At least OvmfPkg/README has such a recommendation (from SVN r13569),
albeit for completely different grounds.) The ports tree seems to have
GCC46 even.


Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
edk2-devel mailing list