Please sync dietlibc 0.33~cvs20111108-3 (universe) from Debian unstable (main)

[Thorsten Glaser]

Binary package hint: dietlibc

Hi,

I’m currently trimming the Ubuntu changes required for the mksh package, and
I think I’m down to one:

 - debian/control, debian/rules: Exclude dietlibc on powerpc/ppc64
   and sparc (cf. LP: #381332)

Please sync/merge a newer dietlibc from Debian, in the hope that this change
can also be abandoned; Debian has 0.32-5 already, which has solved a few
of the problems already. The dietlibc package in *buntu has received no new
version for ages, and from time to time I still get mails about build failures on
ARM because I provided a diff for the last one to solve an immediate problem…

[David Sugar (dyfet-deactivatedaccount)]

I have a merge for 0.32-5 from debian. I had to adjust the ubuntu toolchain bug and remove the obsolete stdarg fix. Will post shortly.

[Stefano Rivera (stefanor)]

Hi, merge looks mostly good, but some issues:
* Please run update-maintainer to get rid of the old deprecated MOTU maintainer.
* Please better describe the current ubuntu delta, I recommend something like:
  * Merge from debian unstable (LP: #584980) remaining changes:
    - debian/diff/0900-ubuntu-toolchain.diff:
      + Use -fno-stack-protector for sparc and powerpc architectures.
      + build against Ubuntu toolchain
    - debian/rules: Add support for armel port.
    - debian/control: Build dietlibc binary package.
  * Dropped changes:
    - fix-stdarg-gcc44 no longer needed.
  * Fixed ubuntu toolchain patch for ppc & sparc for newer upstream.
* You re-add the dietlibc binary package, but it doesn't get built on i386, as it's supposed to be. Can we just drop it again? (as debian has done) or do we need some install rules?
* Just a note: I don't think it'll build on armel, my qemu chroot's gcc segfaulted

[Thorsten Glaser (mirabilos)]

> * Just a note: I don't think it'll build on armel, my qemu chroot's gcc segfaulted

See: http://thread.gmane.org/gmane.linux.lib.dietlibc/1510

Thanks for looking at it anyway.

[David Sugar (dyfet-deactivatedaccount)]

I will have a chance to look at this and revise it midweek. I can retest and build on live arm hw to validate if arm really is broken.

[David Sugar (dyfet-deactivatedaccount)]

bin-arm/diet gcc -D__dietlibc__ -pipe -nostdinc -Os -fomit-frame-pointer -fstrict-aliasing -mabi=aapcs-linux -mfloat-abi=soft -mno-thumb-interwork -W -Wall -Wextra -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wno-switch -Wno-unused -Wredundant-decls -o bin-arm/elftrunc contrib/elftrunc.c
make[1]: *** [bin-arm/elftrunc] Illegal instruction

Yes...I can confirm this on arm, and I see we do not build it as thumb, either. This too makes me agree we should drop the binaries since it's not building binaries with the same abi/build options as the rest of the platform as a whole, as well as solving the headache with i386 :).

[Artur Rona (ari-tczew)]

Up this one. Could you prepare a new debdiff to fix Stefano's suggestions? If you are not interested, could you tell what restored binary package? Can we drop again it or still ship?

[Artur Rona (ari-tczew)]

Stefano, we didn't yet receive response from David Sugar. What's the decision?

[Artur Rona (ari-tczew)]

Jani, I subscribed you to this bug because I guess you have knowledge with arm-related stuff. Could you look on this case?

Thanks and regards

[Jani Monoses (jani)]

I think the merging from sid is an independent task from armel FTBFS or runtime problems. That one is https://bugs.launchpad.net/ubuntu/+source/dietlibc/+bug/381914
I'd rather have this synced first, then the arm specific issues looked at.

[Stefano Rivera (stefanor)]

> I think the merging from sid is an independent task from armel FTBFS or runtime problems.

Sounds good. As to the dietlibc binary package, I'd follow Debian as I don't know any better...

[Thorsten Glaser (mirabilos)]

In the meanwhile, I got co-maintenance of dietlibc in Debian.

So I suggest you guys do split the update from ARM support,
and talk to Héctor Orón and (to a limited amount) me about
both. The Debian package _should_ get (better) ARM support
soonish, and I am monitoring the mailing list as well, where
there were related patches. But first, for Ubuntu, I’d say
is to get a recent version and see what patches are still
required and what old bugs go away.

Also, if interested, I’m sure one of you could also join
the new pkg-dietlibc “fun”…

[Matthias Klose (doko)]

now synced to let it build unmodified

[Matthias Klose (doko)]

and ftbfs ...

[Matthias Klose (doko)]

0.33~cvs20110710-2 still ftbfs

[...]
rm -f ttt
bin-'arm'/diet -v -Os gcc -nostdinc -static -o ttt debian/test/tc523086.c
gcc -nostdlib -static -L/scratch/packages/tmp/dietlibc-0.33~cvs20110710/bin-arm /scratch/packages/tmp/dietlibc-0.33~cvs20110710/bin-arm/start.o -nostdinc -static -o ttt debian/test/tc523086.c -isystem /scratch/packages/tmp/dietlibc-0.33~cvs20110710/include -D__dietlibc__ -Os -fomit-frame-pointer /scratch/packages/tmp/dietlibc-0.33~cvs20110710/bin-arm/dietlibc.a -lgcc /scratch/packages/tmp/dietlibc-0.33~cvs20110710/bin-arm/dietlibc.a
/scratch/packages/tmp/dietlibc-0.33~cvs20110710/bin-arm/dietlibc.a(vprintf.o): In function `vprintf':
vprintf.c:(.text+0x2c): warning: warning: the printf functions add several kilobytes of bloat.
./ttt
make: *** [build-stamp] Segmentation fault
dpkg-buildpackage: error: debian/rules build gave error exit status 2

[Thorsten Glaser (mirabilos)]

Matthias Klose dixit:

>0.33~cvs20110710-2 still ftbfs

Héctor, can you debootstrap oneiric on one of your ARM boxen
and reproduce this there? I’ve got no ARM hardware.

bye,
//mirabilos
--
22:59⎜<Vutral> glaub ich termkit is kompliziert | glabe nicht das man
damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil
zuviel bilder │ wie ein spiel | 23:00⎜<Vutral> die meisten raffen auch
nicht mehr von windows | 23:01⎜<Vutral> bilderbücher sind ja auch nich
wirklich verbreitet als erwachsenen literatur ‣ who needs GUIs thus?

[Thorsten Glaser (mirabilos)]

Matthias Klose dixit:

>0.33~cvs20110710-2 still ftbfs

This is fun – I built a sid and a precise chroot today, i386,
and built mksh against dietlibc-dev_0.33~cvs20110918-4_i386.deb
from Debian sid (dpkg -i’d on precise). It segfaults only on
Ubuntu, not on Debian. It is _not_ -fstack-protector-all.

Investigating. May be some gcc default flags difference…
Matthias, if you have an idea already, shoot.

bye,
//mirabilos
--
<ch> you introduced a merge commit │<mika> % g rebase -i HEAD^^
<mika> sorry, no idea and rebasing just fscked │<mika> Segmentation
<ch> should have cloned into a clean repo │ fault (core dumped)
<ch> if I rebase that now, it's really ugh │<mika:#grml> wuahhhhhh

[Thorsten Glaser (mirabilos)]

Dixi quod…

>This is fun – I built a sid and a precise chroot today, i386,
>and built mksh against dietlibc-dev_0.33~cvs20110918-4_i386.deb
>from Debian sid (dpkg -i’d on precise). It segfaults only on
>Ubuntu, not on Debian. It is _not_ -fstack-protector-all.
>
>Investigating. May be some gcc default flags difference…
>Matthias, if you have an idea already, shoot.

OK, I got it:

Dump of assembler code for function main:
   0x0804820c <+0>: push ebp
   0x0804820d <+1>: push edi
   0x0804820e <+2>: push esi
   0x0804820f <+3>: push ebx
   0x08048210 <+4>: sub esp,0x90
   0x08048216 <+10>: mov ebp,DWORD PTR [esp+0xa8]
=> 0x0804821d <+17>: mov eax,gs:0x14
   0x08048223 <+23>: mov DWORD PTR [esp+0x8c],eax
   0x0804822a <+30>: xor eax,eax
   0x0804822c <+32>: call 0x805dfd4 <chvt_reinit>
[…]

The marked line SIGSEGVs.

(gdb) info r
eax 0xf7ffd420 -134228960
ecx 0x3 3
edx 0x0 0
ebx 0x0 0
esp 0xffffd2e0 0xffffd2e0
ebp 0xffffd394 0xffffd394
esi 0xffffd4a8 -11096
edi 0x0 0
eip 0x804821d 0x804821d <main+17>
eflags 0x10282 [ SF IF RF ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0

What’s in GS and why does the gcc-generated function prologue
try to access it, anyway? This doesn’t happen on MirBSD… nor,
incidentally, on Debian sid, where main() starts like this:

Dump of assembler code for function main:
=> 0x0804820c <+0>: push ebp
   0x0804820d <+1>: push edi
   0x0804820e <+2>: push esi
   0x0804820f <+3>: push ebx
   0x08048210 <+4>: add esp,0xffffff80
   0x08048213 <+7>: mov edi,DWORD PTR [esp+0x98]
   0x0804821a <+14>: call 0x805debc <chvt_reinit>

Since this issue arises in gcc-generated code, similar breakage
may occur on other platforms (I can check amd64 but not ARM or,
at the moment, powerpc; I’m just most familiar with i8086/i386,
myself).

bye,
//mirabilos
--
In traditional syntax ' is ignored, but in c99 everything between two ' is
handled as character constant. Therefore you cannot use ' in a preproces-
sing file in c99 mode. -- Ragge
No faith left in ISO C99, undefined behaviour, etc.

[Thorsten Glaser (mirabilos)]

Matthias Klose dixit:

>0.33~cvs20110710-2 still ftbfs
>
>[...]
>make: *** [build-stamp] Segmentation fault

The versions shipped with oneiric were unusable on all architectures.
On ARM it just happened to segfault during package build. It may or
may not have been the same issue; please test with the upload I did
to Debian experimental right now.

The fix was to always pass -fno-stack-protector from diet to gcc iff
dietlibc was built without SSP support.

If ARM on *buntu is still broken after this, we can re-investigate,
but I needed to fix this first, as it happened on _all_ platforms.

Hector Oron dixit:

[ tc523086 ]
>Not sure if it can be an armhf buildd issue.

If armhf has an experimental buildd, we’ll see; otherwise I would
appreciate a manual schedule here, too. (Now, to see about hppa…)

I wonder why armel and armhf behave so different, anyway. At one
point I even had the Linaro patch as suspect… let’s see here, too,
how far we get with -5 and fix onwards from there.

FWIW, both mksh 40.2-2 and 40.2-3 (the one with all hardening
options, PIE and bindnow and whatnot, enabled) build fine in
a precise/i386 chroot with this version; all regression tests
of mksh pass.

bye,
//mirabilos
--
<dileks> ch: good, you corrected yourself. ppl tend to tweet such news
immediately, sth. like "grml devs seem to be buyable" <ch> dileks: we
_are_. if you throw enough money in our direction, things will happen
<mika> everyone is buyable, it's just a matter of price <mrud> and now
comes [mira] and uses this as a signature ;0 -- they asked for it…

[Thorsten Glaser (mirabilos)]

Dixi quod…

>Matthias Klose dixit:
>
>>0.33~cvs20110710-2 still ftbfs

>The versions shipped with oneiric were unusable on all architectures.
>On ARM it just happened to segfault during package build. It may or
>may not have been the same issue; please test with the upload I did
>to Debian experimental right now.

Please test dietlibc (0.33~cvs20111108-2) on all *buntu platforms.
If it passes, we’ll upload to unstable; I _think_ that the ARM,
Alpha and humppa problems will be fixed with it.

Thanks,
//mirabilos
--
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜<thkoehler:#grml> also warum machen die xorg Jungs eigentlich alles
kaputt? :) 15:49⎜<novoid:#grml> thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…

[Thorsten Glaser (mirabilos)]

OK, let’s make a fresh SyncRequest out of this; doko has synched already, but that version did not yet work.

The new version – http://packages.qa.debian.org/d/dietlibc/news/20111111T193320Z.html – was tested by one of the guys in #ubuntu-arm on IRC successfully, so it SHOULD fix most (if not all) outstanding LP bugs.

@ubuntu-sponsors, please process this as sync request.

[Stefano Rivera (stefanor)]

Sync request ACKed

[Thorsten Glaser (mirabilos)]

thanks everyone, the new dietlibc built with no errors on all four(?) *buntu arches.