klibc - Apr 2011 - Bug#618616: arm build failure with latest binutils - usr/klibc/syscalls/_exit.S:29: Error: .size expression does not evaluate to a constant

tags 618616 pending
stop

On Wed, 16 Mar 2011, Lo?c Minier wrote:
>  I've fixed this in Ubuntu with the attached patch, but didn't find
>  where to upstream it; since you're a klibc upstream developer and
since
>  it probably already affects Debian, I figured it was probably best to
>  send it here  :-)
thank you applied after review by hpa and pushed out to klibc git.
Should be visible soonest on
http://git.kernel.org/?p=libs/klibc/klibc.git;a=summary
I will soon push out klibc 1.5.22 with it, once I have fixed
vorlon's arm patch to be upstreamable. as people are asking for the
fixed ipconfig.

Debian BTS is fine for patches or bug reports, otherwise you also just
send off to klibc mailinglist, both are looked and watched. The second
one is usually preferred as more people look at the klibc patches on ml.
 
 
>  BTW, do you have any idea why the build process forces such odd and
>  very old toolchain flags instead of just using the defaults?
>  (it forces -march=armv4 -mtune=strongarm)
what do you expect currently?

thank you.
 
-- 
maks

P.S. adding Arnaud as new debian linux-2.6 arm guy on cc

On Thu, Apr 14, 2011, maximilian attems wrote:
> >  BTW, do you have any idea why the build process forces such odd and
> >  very old toolchain flags instead of just using the defaults?
> >  (it forces -march=armv4 -mtune=strongarm)
> what do you expect currently?
 I'd like if klibc would just build with the toolchain defaults, unless
 there is a reason to diverge; this would provide optimized binaries
 with exactly the optimization level selected in the toolchain.  For
 instance in Debian armhf and Ubuntu armel, the defaults are armv7-a +
 thumb-2 which is faster and smaller code.
   It might also reveal build failures of klibc with these options and
 call for porting (of course the porters might force the flags to
 workaround the FTBFS temporarily).
   Finally, new versions of the ARM architecture have different ways to
 express certain assembly operations; for instance swp goes away and is
 replaced by things like strex and ldrex.  This might be important in
 SMP contexts.

 Another issue with -march=armv4 is that the toolchain is getting worse
 over time for older CPUs; ARMv4 is getting really old, and I saw some
 toolchain regressions affecting older CPUs recently, simply because
 these aren't tested as much.

-- 
Lo?c Minier