Of all the gin joints in all the towns in all the world, Laszlo Ersek had to
walk into mine at 14:36:03 on Monday 03 February 2014 and say:
> 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 mingw-gcc-build.py script.
>
> (BaseTools/gcc/README.txt seems to imply that the output of these
> scripts are not (regularly) tested on FreeBSD.)
It shouldn't matter if it's FreeBSD or not: all that's important is that the
config/build of gcc and binutils succeeds. (Well, and that you have Python.)
The only thing that gives me trouble is that gcc wants libmpfr and libgmp,
which are in /usr/local on FreeBSD, and gcc's configure script doesn't figure
that out automatically. I always fix that by doing:
% setenv CFLAGS -I/usr/local/include
% setenv LDFLAGS -L/usr/local/lib
before I run the script.
> > 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.
I'm not doing a DEBUG build: I'm doing a RELEASE build. That probably makes
the ASSERTs no-ops, in which case the warning is valid.
> > Maybe people are using
> > Windows?
>
> Yes.
>
> > 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).
It triggers for me with X64 builds too. I'm pretty sure unsigned long is
always 32 bits.
> > 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/O
> > UTPUT/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.
Again, it doesn't matter that it's on FreeBSD. The cross compiler would behave
the same if I built it on Solaris instead.
> 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.
>
> Thanks
> Laszlo
Uhm... I can't just "try with GCC44+ instead," can I?
I need the cross compiler environment to build EFI binaries, and the mingw-
gcc-build.py script is set up for gcc 4.3.0. One assumes that it picks the
gcc/binutils versions that it does because these are known to work: I'm not
going to spend hours building a bunch of different gccs/binutils trying to
find another one by trial and error.
-Bill
--
=============================================================================
-Bill Paul (510) 749-2329 | Senior Member of Technical Staff,
[email protected] | Master of Unix-Fu - Wind River Systems
=============================================================================
"I put a dollar in a change machine. Nothing changed." - George Carlin
=============================================================================
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
