Patchwork unify types in kconfig

On Tue, Aug 25, 2009 at 12:41 PM, Myles Watson<mylesgw@gmail.com> wrote:
> On Tue, Aug 25, 2009 at 11:37 AM, ron minnich<rminnich@gmail.com> wrote:
>> On Tue, Aug 25, 2009 at 10:14 AM, Uwe Hermann<uwe@hermann-uwe.de> wrote:
>>
>>> Hm, you could be right. This was per-mainboard in Config.lb, but in
>>> kconfig it should be a global/common option, and not set in each board.
>>
>> yes, we really need to start using the power of Kconfig now. Let's
>> make it so people can choose this in menuconfig.
>
 Here's another attempt.
 Signed-off-by: Myles Watson <mylesgw@gmail.com>

  It doesn't link.  The errors I'm getting look familiar, but the past
solution isn't working for me:
    CC         coreboot_ram
/home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram.o:
In function `div_long':
(.text+0x11c79): undefined reference to `__umoddi3'
/home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram.o:
In function `div_long':
(.text+0x11c92): undefined reference to `__udivdi3'
/home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram.o:
In function `idiv_long':
(.text+0x11dca): undefined reference to `__moddi3'
/home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram.o:
In function `idiv_long':
(.text+0x11de3): undefined reference to `__divdi3'
collect2: ld returned 1 exit status
make: *** [/home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram]
Error 1

These errors look like the same ones that can be fixed with
gcc-multilib, but I have that installed.  I'm not sure how these files
should be built now.

Thanks,
Myles

On Tue, 2009-08-25 at 15:41 -0600, Myles Watson wrote:
> On Tue, Aug 25, 2009 at 12:41 PM, Myles Watson<mylesgw@gmail.com> wrote:
> > On Tue, Aug 25, 2009 at 11:37 AM, ron minnich<rminnich@gmail.com> wrote:
> >> On Tue, Aug 25, 2009 at 10:14 AM, Uwe Hermann<uwe@hermann-uwe.de> wrote:
> >>
> >>> Hm, you could be right. This was per-mainboard in Config.lb, but in
> >>> kconfig it should be a global/common option, and not set in each board.
> >>
> >> yes, we really need to start using the power of Kconfig now. Let's
> >> make it so people can choose this in menuconfig.
> >
>  Here's another attempt.
>  Signed-off-by: Myles Watson <mylesgw@gmail.com>
> 
>   It doesn't link.  The errors I'm getting look familiar, but the past
> solution isn't working for me:
>     CC         coreboot_ram
> /home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram.o:
> In function `div_long':
> (.text+0x11c79): undefined reference to `__umoddi3'
> /home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram.o:
> In function `div_long':
> (.text+0x11c92): undefined reference to `__udivdi3'
> /home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram.o:
> In function `idiv_long':
> (.text+0x11dca): undefined reference to `__moddi3'
> /home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram.o:
> In function `idiv_long':
> (.text+0x11de3): undefined reference to `__divdi3'
> collect2: ld returned 1 exit status
> make: *** [/home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram]
> Error 1
> 
> These errors look like the same ones that can be fixed with
> gcc-multilib, but I have that installed.  I'm not sure how these files
> should be built now.

Hello,

I stumbled upon these errors when porting to Asus M2V-MX-SE, and they
are related to libgcc. Coreboot needs to be linked against libgcc when
using 64bit arithmetic in 32bit code. 

There are a few approaches for fixing this, like:
-link against libgcc (statically)
-implement the needed functions ourselves (copied from libgcc)
-avoid using 64bit arithmetic

I'm in inclined to vote for the first approach.

Cristi

On Wed, Aug 26, 2009 at 1:01 AM, Cristi
Magherusan<Cristi.Magherusan@net.utcluj.ro> wrote:

> There are a few approaches for fixing this, like:
> -link against libgcc (statically)

Won't work on FC11.

From a note on 9fans:

=============
also, i discovered something new today:

"... decided to link everything dynamically. To enforce this (allmost)
all static libraries are removed (or not even build)..."

$ gcc t.c -static
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
==============


> -implement the needed functions ourselves (copied from libgcc)

I vote for this one. Every time we count on stable (or even sane)
behavior from all linux distros or gnu toolchain, we get burned. I
think we need to be as standalone as possible.

There are, what, four functions at issue?

What really amazes me is that with all the inlining that is done
nowadays, these trivial functions are not inlined!

ron

>  Here's another attempt.
>  Signed-off-by: Myles Watson <mylesgw@gmail.com>
Ping.  Now it builds.

Thanks,
Myles

On Wed, 2009-08-26 at 08:27 -0700, ron minnich wrote:
> On Wed, Aug 26, 2009 at 1:01 AM, Cristi
> Magherusan<Cristi.Magherusan@net.utcluj.ro> wrote:
> 
> > There are a few approaches for fixing this, like:
> > -link against libgcc (statically)
> 
> Won't work on FC11.
> 
> From a note on 9fans:
> 
> =============
> also, i discovered something new today:
> 
> "... decided to link everything dynamically. To enforce this (allmost)
> all static libraries are removed (or not even build)..."
> 
> $ gcc t.c -static
> /usr/bin/ld: cannot find -lc
> collect2: ld returned 1 exit status
> ==============
> 
> 
> > -implement the needed functions ourselves (copied from libgcc)
> 
> I vote for this one. Every time we count on stable (or even sane)
> behavior from all linux distros or gnu toolchain, we get burned. I
> think we need to be as standalone as possible.
> 
> There are, what, four functions at issue?
> 
> What really amazes me is that with all the inlining that is done
> nowadays, these trivial functions are not inlined!
> 
> ron
> 
Hello,

This issue will be decided and fixed in time, maybe even cleaner,
but now we need to have as much boards as possible work with
kconfig/Kbuild and the workaround I submitted makes it possible, not to
mention it was already done the same way in the older buildsystem.


Cristi

On Wed, Aug 26, 2009 at 9:01 AM, Cristi
Magherusan<Cristi.Magherusan@net.utcluj.ro> wrote:

> This issue will be decided and fixed in time, maybe even cleaner,
> but now we need to have as much boards as possible work with
> kconfig/Kbuild and the workaround I submitted makes it possible, not to
> mention it was already done the same way in the older buildsystem.


Agreed. You all made the right decision.

ron