filo build failure: get_multiboot_info is undefined

The libpayload and filo code is from repos r4671.

Summary of the error:

...
  LD      build/filo
/home/fuchsk/coreboot/filo/build/libpayload/lib/libpayload.a(sysinfo.o): \
In function `lib_get_sysinfo':
sysinfo.c:(.text+0x18): undefined reference to `get_multiboot_info'
make: *** [/home/fuchsk/coreboot/filo/build/filo] Error 1
$

Downloaded code via http://tracker.coreboot.org/trac/coreboot/browser/trunk/payloads & http://tracker.coreboot.org/trac/filo/browser/trunk and the zip download
links at the bottom of each page.  Extracted onto a relatively current
(1-2 months old), trim (~600MB) Debian system.

libpayload was built as follows:

$ pushd ~/coreboot/trunk/payloads/libpayload
$ make clean
$ make defconfig
$ make
$ make DESTDIR=../../../filo/build install
$ pushd ../../../filo/
$ make menuconfig
<Save config without making any (new) selections.>
$ make
  CC      build/i386/context.o
  AS      build/i386/switch.S.o
  CC      build/i386/segment.o
  CC      build/i386/timer.o
  CC      build/i386/sys_info.o
  CC      build/i386/linux_load.o
  CC      build/main/filo.o
  CC      build/main/strtox.o
  CC      build/main/elfload.o
  CC      build/main/elfnote.o
  CC      build/main/ipchecksum.o
  CC      build/main/grub/grub.o
  CC      build/main/grub/builtins.o
  CC      build/main/grub/cmdline.o
  CC      build/main/grub/char_io.o
  CC      build/main/grub/completions.o
  CC      build/main/grub/md5.o
  CC      build/fs/blockdev.o
  CC      build/fs/vfs.o
  CC      build/fs/eltorito.o
  CC      build/fs/fsys_ext2fs.o
  CC      build/fs/fsys_fat.o
  CC      build/fs/fsys_reiserfs.o
  CC      build/fs/fsys_iso9660.o
  CC      build/fs/fsys_cbfs.o
In file included from /home/fuchsk/coreboot/filo/fs/fsys_cbfs.c:21:
include/cbfs.h:160: warning: â declared inside parameter list
include/cbfs.h:160: warning: its scope is only this definition or declaration, \
which is probably not what you want
  CC      build/fs/cbfs.o
In file included from /home/fuchsk/coreboot/filo/fs/cbfs.c:22:
include/cbfs.h:160: warning: â declared inside parameter list
include/cbfs.h:160: warning: its scope is only this definition or declaration, \
which is probably not what you want
/home/fuchsk/coreboot/filo/fs/cbfs.c: In function â:
/home/fuchsk/coreboot/filo/fs/cbfs.c:88: warning: assignment makes integer from\
 pointer without a cast
/home/fuchsk/coreboot/filo/fs/cbfs.c:108: warning: comparison between pointer a\
nd integer
  CC      build/fs/lzma.o
  CC      build/drivers/ide.o
  CC      build/drivers/intel.o
  CC      build/drivers/newusb/usb.o
  LD      build/filo
/home/fuchsk/coreboot/filo/build/libpayload/lib/libpayload.a(sysinfo.o): In fun\
ction `lib_get_sysinfo':
sysinfo.c:(.text+0x18): undefined reference to `get_multiboot_info'
make: *** [/home/fuchsk/coreboot/filo/build/filo] Error 1
$

Any suggestions for resolving this error?

Sincerely,

Ken Fuchs

[Myles Watson]

> The libpayload and filo code is from repos r4671.
>
> ction `lib_get_sysinfo':
> sysinfo.c:(.text+0x18): undefined reference to `get_multiboot_info'
> make: *** [/home/fuchsk/coreboot/filo/build/filo] Error 1
> $
>
> Any suggestions for resolving this error?

I've never built FILO separately that way.  Do you get the same error when
you use buildrom?  Check out buildrom, `make menuconfig` and select FILO as
the payload.  Then `make` and the payload should be deploy/filo-payload.elf.

If that works it should help you figure out what's wrong.

Thanks,
Myles

Solution to: filo build failure: get_multiboot_info is undefined

Ken Fuchs wrote:
> Summary of the error:
>
> ...
>   LD      build/filo

/home/fuchsk/coreboot/filo/build/libpayload/lib/libpayload.a(sysinfo.o):
\
> In function `lib_get_sysinfo':
> sysinfo.c:(.text+0x18): undefined reference to `get_multiboot_info'
> make: *** [/home/fuchsk/coreboot/filo/build/filo] Error 1
> $

--- Summary ---

libpayload was simply missing the CONFIG_MULTIBOOT option.

Replace "make defconfig" with "make menuconfig" in
http://www.coreboot.org/FILO.
Make them create the same configuration when no explicit option is
selected in "make menuconfig" on fresh source code.

--- Details ---

libpayload was simply missing the CONFIG_MULTIBOOT option.

"make defconfig" clears this option.  Whereas, "make menuconfig" with
_no_
selections sets it (on a fresh source code extraction).

The FILO instructions http://www.coreboot.org/FILO say in part ...

$ cd libpayload
 $ make defconfig        <========== replace with "make menuconfig"
 $ make
 $ make DESTDIR=../build install
 $ cd ..

$ make menuconfig

Making no selections in either libpayload or filo results in the build
failure
quoted above.

I understand that in the "make menuconfig", one is expected to make some
changes
to the configuration and sometimes they need to match the libpayload
configuration.
However, the instructions should also result in no build errors when
_no_ explicit
configuration changes where made to either software package.  This is
currently
not the case.

This may seem trivial, but most people don't expect to see build errors
when
they carefully follow the instructions and make only selections that are
explicit
within the instructions.

I also noticed that the following two invocations have different effect
on a
fresh extraction of either the libpayload or filo source code when it
seems
they should have the same effect:

$ make defconfig

$ make menuconfig
<Save config without making any (new) selections.>

Arguably, both the above make invocations should result in the same
configuration.
If not, I'd conclude that the configuration system has a trivial flaw,
but we'd
prefer to have no flaws at all.

------

I'm very impressed by the new build system and coreboot.org web site.
Both have
improved immensely over the past 4-5 years.  Commercial BIOS vendors are
no doubt
green with envy.

Sincerely,

Ken Fuchs

Solution to: filo build failure: get_multiboot_info is undefined

[Peter Stuge]

Ken,

[e-mail] wrote:
> libpayload was simply missing the CONFIG_MULTIBOOT option.

..
> Making no selections in either libpayload or filo results in the
> build failure quoted above.

Thanks for tracking this issue down! I think this is very important
from a QA and "user experience" perspective. There are so many
components related to coreboot that it is important to make sure that
they fit together really well.
> However, the instructions should also result in no build errors
> when _no_ explicit configuration changes where made to either
> software package.

I agree. A short term fix could be to disable multiboot support in
FILO by default.

Longer term, I can come up with two ideas:

1. FILO and other programs using libpayload can "autodetect" relevant
   settings in libpayload, and adjust their own configuration
   accordingly.

2. Make sure that libpayload and all it's users keep having
   harmonized default values.

Of these I think 1. is the only one which is really sustainable. In
practise it could take the shape of a pre-configuration script which
presets the current payload configuartion (FILO) according to how
libpayload was built, and a "validator" which is used to check that
any changes from e.g. make menuconfig are actually compatible with
how libpayload was configured. It would be very nice to catch this
already before trying to build, and give a helpful error message
rather than failing at the linker stage.

Ideally I would like libpayload Kconfig to be integrated with the
payload (e.g. FILO) Kconfig, so that there is really only one knob to
turn in order to get, say, multiboot support. Can that be done? I
think it's good for libpayload to also "reach into" the payload
config/build process. Normally I might not, but I think the
consistency it allows is a very important feature.
> This may seem trivial, but most people don't expect to see build
> errors when they carefully follow the instructions and make only
> selections that are explicit within the instructions.

This is a good point.

buildrom is still a good way to build coreboot and payloads, without
being forced to get into all the details of every single component.

But, this is an issue with libpayload that at least I haven't thought
much about earlier, and I think it would be nice to improve the
failure mode.
> I also noticed that the following two invocations have different
> effect
>
> $ make defconfig
>
> $ make menuconfig
> <Save config without making any (new) selections.>
>
> Arguably, both the above make invocations should result in the same
> configuration.

I'd also expect that. Can anyone say why they don't? defconfig just
pulls in the same config as menuconfig when started blank, or no?
> I'm very impressed by the new build system and coreboot.org web
> site. Both have improved immensely over the past 4-5 years. 
> Commercial BIOS vendors are no doubt green with envy.

Wow! Very kind words, thank you so much Ken. You just made my day. :)
And thanks for helping with further improvement!

//Peter

Solution to: filo build failure: get_multiboot_info is undefined

[Peter Stuge]

[e-mail] wrote:
> > LD      build/filo
>
> /home/fuchsk/coreboot/filo/build/libpayload/lib/libpayload.a(sysinfo.o):
> \
> > In function `lib_get_sysinfo':
> > sysinfo.c:(.text+0x18): undefined reference to `get_multiboot_info'
> > make: *** [/home/fuchsk/coreboot/filo/build/filo] Error 1
> > $
>
> --- Summary ---
>
> libpayload was simply missing the CONFIG_MULTIBOOT option.

Looking closer at this, it seems very strange. This is the code in
sysinfo.c:

#ifdef CONFIG_MULTIBOOT
        /* Get the information from the multiboot tables,
         * if they exist */
        get_multiboot_info(&lib_sysinfo);
#endif

Can anyone say why this wouldn't work properly?

//Peter

Solution to: filo build failure: get_multiboot_info is undefined

[Peter Stuge]

Peter Stuge wrote:
> #ifdef CONFIG_MULTIBOOT
>         /* Get the information from the multiboot tables,
>          * if they exist */
>         get_multiboot_info(&lib_sysinfo);
> #endif
>
> Can anyone say why this wouldn't work properly?

--8<-- Config.in:
config MULTIBOOT
        bool "Multiboot header support"
-->8--

configs/defconfig:# CONFIG_MULTIBOOT is not set

Should a bool ever be unset?

arch/i386/Makefile.inc:TARGETS-$(CONFIG_MULTIBOOT) += arch/i386/multiboot.o

Is the fix simply to set CONFIG_MULTIBOOT=n in defconfig?

//Peter

Solution to: filo build failure: get_multiboot_info is undefined

[Myles Watson]

On Sat, Sep 26, 2009 at 11:22 AM, Peter Stuge  wrote:
> Peter Stuge wrote:
> > #ifdef CONFIG_MULTIBOOT
> >         /* Get the information from the multiboot tables,
> >          * if they exist */
> >         get_multiboot_info(&lib_sysinfo);
> > #endif
> >
> > Can anyone say why this wouldn't work properly?

Shouldn't it be #if CONFIG_MULTIBOOT instead of #ifdef?
> --8<-- Config.in:
> config MULTIBOOT
>        bool "Multiboot header support"
> -->8--
>
> configs/defconfig:# CONFIG_MULTIBOOT is not set
>
> Should a bool ever be unset?

My understanding is that CONFIG_MULTIBOOT = n when you see that
message.  If it isn't defined at all it doesn't appear in the config
file.

Thanks,
Myles

Solution to: filo build failure: get_multiboot_info is undefined

[Stefan Reinauer]

Myles Watson wrote:
> On Sat, Sep 26, 2009 at 11:22 AM, Peter Stuge  wrote:
> > Peter Stuge wrote:
> > > #ifdef CONFIG_MULTIBOOT
> > >         /* Get the information from the multiboot tables,
> > >          * if they exist */
> > >         get_multiboot_info(&lib_sysinfo);
> > > #endif
> > >
> > > Can anyone say why this wouldn't work properly?
>
> Shouldn't it be #if CONFIG_MULTIBOOT instead of #ifdef?

It should in coreboot, but not in libpayload or filo, afaict. We changed
the default behavior in coreboot explicitly because there was so much
code that assumed that behavior, and we didn't want to create an awful
lot of blind breakage or difference between Config.lb and Kconfig
> > --8<-- Config.in:
> > config MULTIBOOT
> >        bool "Multiboot header support"
> > -->8--
> >
> > configs/defconfig:# CONFIG_MULTIBOOT is not set
> >
> > Should a bool ever be unset?

Well, we're using Kconfig, and that's how Kconfig handles it... Maybe
that question is better answered by the Kconfig folks.

I think their idea was to have a positive for #if CONFIG_MULTIBOOT and
#ifdef CONFIG_MULTIBOOT if CONFIG_MULTIBOOT was true, and a negative for
both when it's false. Not many other ways to get that behavior
> My understanding is that CONFIG_MULTIBOOT = n when you see that
> message.  If it isn't defined at all it doesn't appear in the config
> file.

That's what I think too.

Stefan