maemo.org - Talk - Working in progress: upgrading glibc

maemo.org - Talk (https://talk.maemo.org/index.php)

- Development (https://talk.maemo.org/forumdisplay.php?f=13)

- - Working in progress: upgrading glibc - standard c-library (https://talk.maemo.org/showthread.php?t=89467)

Working in progress: upgrading glibc - standard c-library

This post is about updating glibc (libc6) on Maemo5.

Stock Maemo5 has quite old eglibc-2.5.1 (2008-04-16).

glibc HISTORY:

Code:

2.3  - 2002-10-03

2.4  - 2006-03-06

2.5  - 2006-09-29

2.6  - 2007-05-15

2.7  - 2007-10-18

2.8  - 2008-04-12

2.9  - 2008-11-13

2.10 - 2009-05-09

2.11 - 2009-10-30

2.12 - 2010-05-03

2.13 - 2011-01-17

2.14 - 2011-05-31

2.15 - 2011-12-23 ... 2012-03-21

2.16 - 2012-06-30

2.17 - 2012-12-25

GOALS:
1) get it compiled
2) get it booted and running
3) optimize for N900

INVESTIGATING
I have tried to track origin of Maemo's eglibc and closest match is svn-2784 on eglibc-branch-2.5.

Code:

#sources of Maemo5 libc6

apt-get source libc6



#sources from upstream

svn checkout svn://svn.eglibc.org/branches/eglibc-2_5/ -r 2784 svn_eglibc-2.5_r2784



cd svn_eglibc-2.5_r2784

find ./ -name ".svn" | xargs rm -Rf

cd ..



tar xf glibc-2.5.1/glibc-2.5.tar.bz2

diff -Naur glibc-2.5/ svn_eglibc-2.5_r2784/libc/ | cat -n

#242 rows (where half of them are changelog)



diff -Naur linuxthreads svn_eglibc-2.5_r2784/linuxthreads/linuxthreads | cat -n

#115 rows



tar xf glibc-2.5.1/glibc-linuxthreads-2.5.tar.bz2

diff -Naur linuxthreads_db/ svn_eglibc-2.5_r2784/linuxthreads/linuxthreads_db/ | cat -n

#exactly same



tar xf glibc-2.5.1/glibc-ports-2007q3.tar.bz2

diff -Naur ports/ svn_eglibc-2.5_r2784/ports/ | cat -n

#977 rows (some 200 are about arm)



#Maemo source also contains tarred libidn, but it is already unpacked

tar xf glibc-2.5.1/glibc-libidn-2.5.tar.bz2

diff -Naur libidn/ glibc-2.5/libidn/

Then I figured out that patches added during packeting are almost useless, only arm-asm-page-header.diff is needed to get it compiled and running.

STEP1:
Starting with stock maemo SDK, i.e gcc-4.2.

Compile latest eglibc-2.5 from svn without Maemo-patches, but using very same packeting:

Code:

svn co svn://svn.eglibc.org/branches/eglibc-2_5 svn_eglibc-2.5

cd svn_eglibc-2.5

find ./ -name ".svn" | xargs rm -Rf



mv libc/ glibc-2.5

tar cjf ../glibc-2.5.tar.bz2 glibc-2.5



cd linuxthreads

tar cjf ../../glibc-linuxthreads-2.5.tar.bz2 linuxthreads  linuxthreads_db

cd ..



tar cjf ../glibc-ports-2007q3.tar.bz2 ports/



cd ..

rm -rf svn_eglibc-2.5



cp -r glibc-2.5.1/debian/ glibc-2.5.1/prep.sh svn_eglibc-2.5

#use only this patch

echo "arm-asm-page-header.diff" > svn_eglibc-2.5/debian/patches/00-list.armel



cd glibc-2.5.1

fakeroot dpkg-buildpackage

-> working package. Tested with fresh flashed device.

STEP2
Compile newer eglibc from upstream.

Fastest way to test them are just skip version numbering and use same commands as above but starting with:
svn co svn://svn.eglibc.org/branches/eglibc-2_6 svn_eglibc-2.5
-> works.

svn co svn://svn.eglibc.org/branches/eglibc-2_7 svn_eglibc-2.5
-> works

svn co svn://svn.eglibc.org/branches/eglibc-2_8 svn_eglibc-2.5
no need for "arm-asm-page-header.diff" anymore
-> works

svn co svn://svn.eglibc.org/branches/eglibc-2_10 svn_eglibc-2.5
-> works

svn co svn://svn.eglibc.org/branches/eglibc-2_11 -r 8593 svn_eglibc-2.11_8593
#version 2.10.90.
-> works

NOTE: 'ldd' with this version and later needs bash!

This is the end of this approach: later commits have new file ports/sysdeps/arm/eabi/backtrace.c which causes linking error:
backtrace.c:105: undefined reference to `_Unwind_Backtrace'

I'm pretty sure this is because of too old GCC (because it happens even I use newer binutils)

(Btw: even this will be workarounded, eglibc-2.12 fails, because it needs CFI support:
checking whether the CFI directive .cfi_sections is supported... no
configure: error: need .cfi_sections in this configuration

CFI stands for Call Frame Information and is a GNU AS extension to manage call frames.
http://www.logix.cz/michal/devel/gas-cfi/ I don't know is this used, but at least it is checked and failed.)

Here is the deb, I have tested it just reflashed N900 and didn't encounter any issues.
http://cc.oulu.fi/~rantalai/maemo5/e...emo1_armel.deb

STEP3
Use newer compiler: gcc-4.7.2 (and binutils-2.22)

Upstream versions between 2.5 ... 2.15 need one patch and then they can be compiled:
http://cc.oulu.fi/~rantalai/maemo5/e...ctor-nscd.diff

There are problem that locales might break: Every text on the screen looks like: "wdgt_va_24h_time"
(nothing helps from here: http://talk.maemo.org/showthread.php?t=52443)

This is tested way to get eglibc-2.10.90 compiled with gcc-4.7 fully working (including working locales).
You do not need thumb-support, but you need libstdc++6_4.7.2 and libgcc1_4.7.2 installed.

Code:

#FLASH (flasher-3.5 -f -R -F RX-51_2009SE_20.2010.36-2_PR_COMBINED_MR0_ARM.bin)

# (no rd-mode, just press continue on startup-wizard)

#enable wlan

#with hildon-application-manager: install openssh-server 

#continue over ssh:

apt-get install wget binutils bash

apt-get remove mp-fremantle-generic-pr

wget http://maemo.merlin1991.at/cssu/develdebs/gcc-4.7.2_fremantle_armel/packages/libstdc%2b%2b6_4.7.2-0%2bcssu0_armel.deb

wget http://maemo.merlin1991.at/cssu/develdebs/gcc-4.7.2_fremantle_armel/packages/libgcc1_4.7.2-0%2bcssu0_armel.deb

dpkg -i libgcc1_4.7.2-0+cssu0_armel.deb     libstdc++6_4.7.2-0+cssu0_armel.deb



#I'm pretty sure this is needed step.

mkdir 42 ; cd 42

wget http://cc.oulu.fi/~rantalai/maemo5/eglibc/2.10/with_gcc42_deb/libc6_2.10.90-maemo1_armel.deb

cd ..

dpkg -i 42/libc6_2.10.90-maemo1_armel.deb





mkdir 47 ; cd 47

wget http://cc.oulu.fi/~rantalai/maemo5/eglibc/2.10/with_gcc47_deb/libc6_2.10.90-maemo1_armel.deb

cd ..

dpkg -i 47/libc6_2.10.90-maemo1_armel.deb





reboot

#locale works

STEP4
Latest eglibc I could compiled so far is 2.16_r17194, version number 2.15.90. Next commit, svn-r17195, starts to complain about:
intl/dcigettext.c:714: undefined reference to `__libc_enable_secure'
elf/dl-addr.c:36: undefined reference to `_rtld_global'
(these are defined, but it fails to link them)
Commit message is "Merge changes between r17050 and r17194 from /fsf/trunk."

But locales are broken. Investigating from commandline: command locale gives three errors before shows current locale:

Code:

locale

locale: Cannot set LC_CTYPE to default locale: No such file or directory

locale: Cannot set LC_MESSAGES to default locale: No such file or directory

locale: Cannot set LC_COLLATE to default locale: No such file or directory

With 2.10.90 (one) workaround was first install very same version compiled older gcc, but now this is not an option.

STEP4b:
Take smaller steps. eglibc-2.11.0 (svn_r9170) with gcc-4.7 upgrading from 2.10.90.
-> locales are broken, this time only:
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Stracing shows:

Code:

Nokia-N900:~# strace locale

execve("/usr/bin/locale", ["locale"], [/* 63 vars */]) = 0

brk(0)                                  = 0x18000

uname({sys="Linux", node="Nokia-N900", ...}) = 0

mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001d000

access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)

open("/etc/ld.so.cache", O_RDONLY)      = 3

fstat64(3, {st_mode=S_IFREG|0644, st_size=37968, ...}) = 0

mmap2(NULL, 37968, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40026000

close(3)                                = 0

open("/lib/libc.so.6", O_RDONLY)        = 3

read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\310o\1\0004\0\0\0"..., 512) = 512

fstat64(3, {st_mode=S_IFREG|0755, st_size=1167548, ...}) = 0

mmap2(NULL, 1209588, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40030000

mprotect(0x4014a000, 32768, PROT_NONE)  = 0

mmap2(0x40152000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11a) = 0x40152000

mmap2(0x40155000, 9460, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40155000

close(3)                                = 0

mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001e000

set_tls(0x4001e110, 0x4001e7e8, 0x40025050, 0x4001e110, 0x40025050) = 0

mprotect(0x40152000, 8192, PROT_READ)   = 0

mprotect(0x15000, 4096, PROT_READ)      = 0

mprotect(0x40024000, 4096, PROT_READ)   = 0

munmap(0x40026000, 37968)               = 0

open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3

fstat64(3, {st_mode=S_IFREG|0644, st_size=23911920, ...}) = 0

mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40158000

close(3)                                = 0

brk(0)                                  = 0x18000

brk(0x39000)                            = 0x39000

open("/usr/share/locale/locale.alias", O_RDONLY) = -1 ENOENT (No such file or directory)

open("/usr/lib/locale/en_GB/LC_CTYPE", O_RDONLY) = -1 ENOENT (No such file or directory)

open("/usr/lib/locale/en/LC_CTYPE", O_RDONLY) = -1 ENOENT (No such file or directory)

write(2, "locale: ", 8locale: )                 = 8

write(2, "Cannot set LC_CTYPE to default l"..., 37Cannot set LC_CTYPE to default locale) = 37

write(2, ": No such file or directory", 27: No such file or directory) = 27

write(2, "\n", 1

)                       = 1

open("/usr/share/locale/en_GB/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)

open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)

write(2, "locale: ", 8locale: )                 = 8

write(2, "Cannot set LC_ALL to default loc"..., 35Cannot set LC_ALL to default locale) = 35

write(2, ": No such file or directory", 27: No such file or directory) = 27

write(2, "\n", 1

)                       = 1

fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0

mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001f000

write(1, "LANG=en_GB\n", 11LANG=en_GB

)            = 11

write(1, "LC_CTYPE=\"en_GB\"\n", 17LC_CTYPE="en_GB"

)    = 17

write(1, "LC_NUMERIC=en_GB\n", 17LC_NUMERIC=en_GB

)      = 17

write(1, "LC_TIME=en_GB\n", 14LC_TIME=en_GB

)         = 14

write(1, "LC_COLLATE=\"en_GB\"\n", 19LC_COLLATE="en_GB"

)  = 19

write(1, "LC_MONETARY=en_GB\n", 18LC_MONETARY=en_GB

)     = 18

write(1, "LC_MESSAGES=en_GB\n", 18LC_MESSAGES=en_GB

)     = 18

write(1, "LC_PAPER=en_GB\n", 15LC_PAPER=en_GB

)        = 15

write(1, "LC_NAME=en_GB\n", 14LC_NAME=en_GB

)         = 14

write(1, "LC_ADDRESS=en_GB\n", 17LC_ADDRESS=en_GB

)      = 17

write(1, "LC_TELEPHONE=en_GB\n", 19LC_TELEPHONE=en_GB

)    = 19

write(1, "LC_MEASUREMENT=en_GB\n", 21LC_MEASUREMENT=en_GB

)  = 21

write(1, "LC_IDENTIFICATION=en_GB\n", 24LC_IDENTIFICATION=en_GB

) = 24

write(1, "LC_ALL=\n", 8LC_ALL=

)                = 8

exit_group(0)                           = ?

Re: Working in progress: upgrading glibc - standard c-library

Maybe you need a newer locale-gen?? Also try this:
ln -s /usr/share/X11/locale/locale.alias /usr/share/locale/locale.alias

The file exists in our N900 (at least in mine), got it from here:
http://bts.grml.org/grml/issue655

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by pablocrossa (Post 1328972)

Installing corresponding locales.deb contains working /usr/share/locale/locale.alias. And there are also something wrong with locale-gen (coming from new package)

echo en_GB.UTF-8 UTF-8 > /etc/locale.gen
locale-gen

Calls localedef -i en_GB -c -f UTF-8 -A /usr/share/locale/locale.alias en_GB.UTF-8
which updates file: /usr/lib/locale/locale-archive
But it should create new subdirectory instead (at least locale is looking directory), so running manually
localedef -i en_GB -c -f UTF-8 -A /usr/share/locale/locale.alias en_GB.UTF-8 --no-archive

Creates subdirectory: /usr/lib/locale/en_GB.utf8
And locale is still looking them at /usr/lib/locale/en_GB
Symlinking is enough

ln -s /usr/lib/locale/en_GB.utf8/ /usr/lib/locale/en_GB

-------
Summary (not tested fresh flashed)

Code:

dpkg -i libc6_2.15.90-maemo1_armel.deb locales_2.15.90-maemo1_armel.deb

localedef -i en_GB -c -f UTF-8 -A /usr/share/locale/locale.alias en_GB.UTF-8 --no-archive

ln -s /usr/lib/locale/en_GB.utf8/ /usr/lib/locale/en_GB

reboot

#english locale is working

Adding more languages to the Settings->Languages

Code:

localedef -i fi_FI -c -f UTF-8 -A /usr/share/locale/locale.alias fi_FI.UTF-8 --no-archive

ln -s /usr/lib/locale/fi_FI.utf8/ /usr/lib/locale/fi_FI

-> English and Finnish tested
----------
Glibc-2.15.90: So far I haven't found any crash issues, every preinstalled application can be at least started. I have no idea about speed or battery consuming.

Check screenshot: This glibc version is not fooled on scratchbox's host kernel version.

Re: Working in progress: upgrading glibc - standard c-library

Tested with reflashed device:

Code:

#FLASH

#install openssh-server via application manager

apt-get install wget

wget http://cc.oulu.fi/~rantalai/maemo5/eglibc/2.15/with_gcc47_deb/libc6_2.15.90-maemo1_armel.deb

wget http://cc.oulu.fi/~rantalai/maemo5/eglibc/2.15/with_gcc47_deb/locales_2.15.90-maemo1_armel.deb



dpkg -i libc6_2.15.90-maemo1_armel.deb locales_2.15.90-maemo1_armel.deb

reboot

#locale broken



localedef -i en_GB -c -f UTF-8 -A /usr/share/locale/locale.alias en --no-archive

reboot

#locale working again



#metapackage

apt-get remove mp-fremantle-generic-pr



#ldd needs it

apt-get install bash

Without reboot between installing and localedef device might (happened at least once) stuck reboot-loop, where it might (happened) wake up only in RD-mode.

Re: Working in progress: upgrading glibc - standard c-library

1. When I was testing my build of Harmattan libc6, locales broke the menu translations, (wdgt and etc.)
2. There were some LC_* problems in easy debian, but don't remember which

Re: Working in progress: upgrading glibc - standard c-library

I have a problem

HTML Code:

# apt-get -f install

Reading package lists... Done

Building dependency tree       

Reading state information... Done

Correcting dependencies... Done

The following packages will be REMOVED:

  libc6-dev libgl1-mesa-dev libglew1.5-dev

  libglewmx1.5-dev libglu1-mesa-dev libqt4-dev

  libsignoncrypto-qt-dev libsqlite3-dev

0 upgraded, 0 newly installed, 8 to remove and 0 not upgraded.

After this operation, 45.5MB disk space will be freed.

Do you want to continue [Y/n]?

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by amr.fayz (Post 1330271)

I have a problem

HTML Code:

# apt-get -f install

Reading package lists... Done

Building dependency tree       

Reading state information... Done

Correcting dependencies... Done

The following packages will be REMOVED:

  libc6-dev libgl1-mesa-dev libglew1.5-dev

  libglewmx1.5-dev libglu1-mesa-dev libqt4-dev

  libsignoncrypto-qt-dev libsqlite3-dev

0 upgraded, 0 newly installed, 8 to remove and 0 not upgraded.

After this operation, 45.5MB disk space will be freed.

Do you want to continue [Y/n]?

Your old libc6-dev needs old libc6. When you upgrade libc6 you need upgrade also libc6-dev. (Actually this is true for every library).

Re: Working in progress: upgrading glibc - standard c-library

First I like To thank you AapoRantalainen for your great efforts

What about update gstreamer Version: 0.10.34

It depends on

libc6 >= 2.7 Was successfully By you
libglib2.0-0 >= 2.26.0 Was successfully By you

libgcc1 >= 1:4.1.1 We Have >=4.7.2-0+cssu0
libxml2 >= 2.6.27 We Have >= 2.6.32+0cssu1

and other sources is her http://xmlsoft.org/sources/old/

Think you can update gstreamer Or there are other problems ?

Re: Working in progress: upgrading glibc - standard c-library

Do you plan to push it into cssu?

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by amr.fayz (Post 1330279)

What about update gstreamer Version: 0.10.34

I have 'done' 0.10.33 (upstream, without packaging).
Seems that from Debian we can get 0.10.32 or 0.10.36.
http://packages.debian.org/search?se...ords=gstreamer

And from Ubuntu (Oneiric) 0.10.35.
http://packages.ubuntu.com/search?la...searchon=names
Will this be good version?

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by marmistrz (Post 1330340)

Do you plan to push it into cssu?

I would love to see this in widely used, but I'm not the person to push anything to the cssu.

As I started on different thread: http://talk.maemo.org/showthread.php?t=89416 I think we need Maemo5-reloaded, something like Maemo5.5, which brings everything together, CSSU, recent SDK, kernel, extras-builder and so on.

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by AapoRantalainen (Post 1330362)

I would love to see this in widely used, but I'm not the person to push anything to the cssu.

Hmm? Why is that? I'd prefer to see the efforts joined rather than spread. Why do you think you are not welcome in CSSU?

Quote:

As I started on different thread: http://talk.maemo.org/showthread.php?t=89416 I think we need Maemo5-reloaded, something like Maemo5.5, which brings everything together, CSSU, recent SDK, kernel, extras-builder and so on.

Count me in :)

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by freemangordon (Post 1330366)

Hmm? Why is that? I'd prefer to see the efforts joined rather than spread. Why do you think you are not welcome in CSSU?

I think it's called "being deferential" or "not being presumptuous" :-)

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by freemangordon (Post 1330366)

Hmm? Why is that? I'd prefer to see the efforts joined rather than spread. Why do you think you are not welcome in CSSU?

Ade's worldclock replacement and iDont's busybox-power precedenses, vs. ease of inclusion (in cssu-devel or cssu-testing) things from "core cssu members", like Pali's bits, or Nicolai's camera-ui, or... ?

Nevertheless, I would, of course, be glad to see here's efforts merged into CSSU. Thumbs up.

/Estel

// Edit

To freemangordon below: It seems that it is - last time I checked both people I've mentioned were interested in their work getting included, and got ridiculous answers. No surprise, that people are switching to "If CSSU want it, they may grab it", instead of wanting to get there on their own. Too much hassle, especially, that cssu doesn't have clear rules what can be included, and what can't.

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by Estel (Post 1330419)

[OT]
Being "core" CSSU dev is not something one is appointed to, it is up to the developer, take luf for example ;)
[/OT]

Sorry for the noise.

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by freemangordon (Post 1330429)

[OT]
Being "core" CSSU dev is not something one is appointed to, it is up to the developer, take luf for example ;)
[/OT]

Sorry for the noise.

[OT]
Let's try to separate two cases there:
1. Developers being on IRC almost daily, having frequent contact with merlin1991
2. Developers only being incidentally on IRC, but having made agreements about steps to come to inclusion of stuff into CSSU.

As I put myself in the last group in this case (ask marmistrz the same question in relation to a more recent sqlite3 version),
I did my steps as agreed upon, the CSSU maintainer(s) should do their part. On one hand commitment is asked for maintenance,
on the other hand no follow up is given. As I said before I do not really care if the clock replacement end up in CSSU, but don't suggest
it is the developer to blame for that.
[/OT]

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by ade (Post 1330445)

[OT]As I put myself in the last group in this case (ask marmistrz the same question in relation to a more recent sqlite3 version),
I did my steps as agreed upon, the CSSU maintainer(s) should do their part. On one hand commitment is asked for maintenance,
on the other hand no follow up is given. As I said before I do not really care if the clock replacement end up in CSSU, but don't suggest
it is the developer to blame for that.
[/OT]

In this case I'm actually to blame. I promised to deliver a mechanism for ham in order make "optional" cssu packages possible, but never came through. Back then we decided to test that mechanism with the worldclock replacement first.
Sqlite3 is a different beast though, the upgraded sqlite3 requires a newer version of tcl/tk which has braking changes to the older version.
Therefore we'd need a sqlite3 build without tcl/tk (just like the stock maemo one), but that didn't happen.
The other project marmistrz suggested to include to cssu (meego qt libs) is only stalled because of the current upload situation, first the build didn't work, and when I noticed that he fixed that cssu upload was b0rked. It will probably end up in the next sucessfull upload.

And to ruin Estels argument regaring busybox-power, we had a discussion with iDont where he agreed that it's better to keep shipping it via extras.

Re: Working in progress: upgrading glibc - standard c-library

sqlite3 needs some scratchbox fixup, it's in my harmattan sqlite3 build.

With the tcl8.5 in extras sqlite3 worked perfect, so the only thing was that it was in the extras (normal extras)

Re: Working in progress: upgrading glibc - standard c-library

Hi AapoRantalainen,first thanks for the new libc6,i already try and install without problem.for now everything look good,no problem with apps,but i lost my sound,maybe this is happen because i am not installed them(libc6)after clean flash i have kp51+thumb2,however i restored my phone with backupmenu by Robbie,or maybe do something like this:
sudo gainroot
apt-get install --reinstall libc6=2.5.1-1eglibc27+0m5

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by merlin1991 (Post 1330497)

And to ruin Estels argument regaring busybox-power, we had a discussion with iDont where he agreed that it's better to keep shipping it via extras.

[OT]Sure, as shipping busybox binary via a fake .deb replacing file by mv is a proper way to distribute it (but only possible if CSSU is excluded), and doesn't qualify for CSSU mantra of "system packages, that can't be provided by other means". Following your philosophy, whole cssu could be provided via extras packages that do binary replacement :rolleyes:

Last time I checked, iDont was interested in having busybox-power in CSSU, but ridicolous, argument-less reaction of "some" busybox-power hater on IRC, who have big influence in CSSU maintainership, + idiotic ideas like having iDont to split busybox-power into two packages (one castrated for CSSU and one normal), for no sane reason, made him wave hand and remain in extras. Not everyone have time for hours of useless discussions on IRC (or IRC as a whole, which is huge time sink).

Sure, you observations may wary, but judging from ade's impression and iDont posts in bb-p thread, CSSU maintainers haven't provided a friendly welcome to those two guys.

And what kind of argument is that cssu-extras? camera-ui replacement which don't even try to fully mimic stock-camera-ui can be in CSSU, and ade's "almost mirror" work can't? Suuure, it isn't because Nicolai was/is considered core CSSU team member, and ade isn't.

What a hypocrisy...
[OT]

[half-OT]Maybe, to avoid polluting this productive thread, separate topic about cssu maintainership and murky inclusion rules should be created?[/half-OT]

/Estel

Re: Working in progress: upgrading glibc - standard c-library

Hi AapoRantalainen,if you find a time could you answer me to one question
That problem with no sound,when installing the new libc6,still existing or already is resolved
regards
edit:After installing libc6: 2.10.90-maemo1,I noticed than my sygic suddenly stop working,i don't know this problem related with the new libc6,but when downgraded to old libc6,problem is solved

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by disappear (Post 1351894)

Hi AapoRantalainen,if you find a time could you answer me to one question
That problem with no sound,when installing the new libc6,still existing or already is resolved
regards

sound Working perfectly with libc6: 2.10.90-maemo1

Re: Working in progress: upgrading glibc - standard c-library

What about including this into cssu?

Re: Working in progress: upgrading glibc - standard c-library

Ask cssu?blabla ten chars

Re: Working in progress: upgrading glibc - standard c-library

seems like its politics everywhere in Maemo even CSSU ??

edit: please someone create another thread regarding these problems. i don't want to go offtopic here. i want to know what is going on.

Re: Working in progress: upgrading glibc - standard c-library

You want new topic with what content? Nothing is going re this inside CSSU, AFAIK. CSSU require people interested in own work getting included to apply actively.

OTOH, after CSSU'ish fiasco with iDont's busybox-power and ade's worldclock inclusion, I don't think that anyone with at least two working brain cells, is going to dance around them to get integrated.

/Estel

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by panjgoori (Post 1352728)

seems like its politics everywhere in Maemo even CSSU ??

edit: please someone create another thread regarding these problems. i don't want to go offtopic here. i want to know what is going on.

Please create that thread, I'll try to answer to the extent of my knowledge.

Aapo, sorry for the OT

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by disappear (Post 1351894)

That problem with no sound,when installing the new libc6,still existing or already is resolved

sounds:
2.10.90 working
2.13 working
2.14 not working
2.15 not working

I'm bisecting this...
[EDIT]
Bisection eglibc-svn ->
svn-13059 (actually same than 13054) works
svn-r13060 not working.

13060 is merging/syncing with fsf-glibc -> bisecting glibc-git

Code:

4bff6e0175ed195871f4e01cc4c4c33274b8f6e3 is the first bad commit

commit 4bff6e0175ed195871f4e01cc4c4c33274b8f6e3

Author: Andreas Schwab <schwab@redhat.com>

Date:   Fri Feb 25 20:49:48 2011 -0500



   - Fix memory leak in dlopen with RTLD_NOLOAD (BZ#12509)

http://sourceware.org/ml/libc-hacker.../msg00004.html

--
Which e.g. Ubuntu is reverting for 2.15
eglibc (2.15~pre6-0ubuntu4) precise; urgency=low
* Issue #13579, revert the fix for #12509. LP: #893605.
https://bugs.launchpad.net/bugs/893605

And proper fix is on glibc-2.16:
http://sourceware.org/bugzilla/show_bug.cgi?id=13579
"This is now fixed for 2.16 by my commit 0479b305c5b7c8e3fa8e3002982cf8cac02b842e"

So seems it will be better to get 2.16 working than tried to get it fixed by myself.

Re: Working in progress: upgrading glibc - standard c-library

eglibc-2.17.90 debs for Fremantle here: http://www.cs.helsinki.fi/u/rantalai.../libc-2.17.90/

It is latest code from eglibc-svn (24.06.2013 http://www.eglibc.org/cgi-bin/viewvc...revision=23297). Here is source for debs: http://www.cs.helsinki.fi/u/rantalai...maemo1.tar.bz2

*Sounds are working.
*Calendar is not working!
*All other default Maemo5 applications are at least starting (not heavily tested yet).
*localedef needs to be manually run: http://talk.maemo.org/showpost.php?p...78&postcount=4
---
Is there any way to debug why Calendar crashes right after start? gdb, strace and valgrind tested, but without source code (or debug symbols) of Calendar I can't figure anything.

I can bisect what is first commit to cause Calendar to break.

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by AapoRantalainen (Post 1354484)

There are some reported backwards compatibility breaking changes in eglibc (as reported in few other projects, e.g. http://us.generation-nt.com/answer/b...205129881.html and http://osdir.com/ml/debian-glibc/2012-11/msg00045.html ).

Taking that to consideration, together with the fact that Debian aims to provide backwards compatibility when possible, I have to ask one question which may sound silly :D Did you try to apply standard Debian patches (e.g. ones from http://packages.debian.org/pl/source/sid/eglibc , file eglibc_2.17-6.debian.tar.xz , directory debian/patches/arm) to the sources and then build and check the Calendar? AFAIK Maemo's eglibc was based on Debian's version, so I would suspect there might be (just might, I'm not saying that for sure) a little chance that, after aplying Debian's fancy patches, the new version will be binary compatible with the previous version. The plain eglibc is known to have ABI incompatibilities even between versions used in Fremantle (2.5) and Harmattan (2.10.1) (see http://linuxtesting.org/compatibilit...at_report.html , "libc.so.6" section and further details for more info).

Re: Working in progress: upgrading glibc - standard c-library

I'm trying out your compile of libc 2.10 as per your instructions, and everything works fine except some fcamera-reliant apps are suddenly spitting out glib errors and generally bombing out.

Could there be a correlation? I try not to talk out of my butt, but this seems like a high probability I'm not totally wrong.

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by misiak (Post 1354486)

Maybe some patches from Maemo 2.5 would need to be applied...

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by Raimu (Post 1354896)

some fcamera-reliant apps are suddenly spitting out glib errors and generally bombing out.

Can you recompile them against libc-2.10-dev? Or libglib must be compiled against newer libc? I'm not sure, but I think that applying old maemo patches won't be the correct solution.

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by AapoRantalainen (Post 1355049)

\I'm not sure, but I think that applying old maemo patches won't be the correct solution.

The possibility is relatively low, I know. But it's always possible that one at-first-sight-redundant patch would do the trick.

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by AapoRantalainen (Post 1355049)

Can you recompile them against libc-2.10-dev? Or libglib must be compiled against newer libc? I'm not sure, but I think that applying old maemo patches won't be the correct solution.

I wish I had a dev environ and some trust in my skills, but I honestly can't do compiling for the n900. I did confirm however that reverting to an older situation with the stock Maemo PR1.3 libc did fix all the apps that use the fcam-drivers package.

Re: Working in progress: upgrading glibc - standard c-library

OK, it turned out that missing locales is a bug in gcc 4.7.2, at least for glibc2.5 :( . I will push the needed changes in glibc thumb-testing branch so won't explain the details here.

EDIT:

this https://gitorious.org/community-ssu/...ad0cf41410ae23

Re: Working in progress: upgrading glibc - standard c-library

Hi All!

May I kindly ask if anyone has the upgraded glibc deb packages...? Since the links in the first post are not working I'm trying to make a package from svn but some of the commands in STEP1 are not clear for me (e.g. how to get arm-asm-page-header.diff or how to have glibc-2.5.1 directory, etc...).

Thanks,

jm

Edit:// OK, found out things, trying to build it now... But already built packegages would be still useful and appreciated if building won't succeed...

Edit2:// Successfully build version 2.10.

Re: Working in progress: upgrading glibc - standard c-library

anyone can reupload libc6_2.10.90-maemo1_armel.deb

link is dead. i need it!!!

Re: Working in progress: upgrading glibc - standard c-library

Quote:

Originally Posted by EL_CID_CAMPEADOR (Post 1544515)

anyone can reupload libc6_2.10.90-maemo1_armel.deb

link is dead. i need it!!!

Hmm... do you really need it...? :rolleyes:

Since no links were added I built it from svn as it is described in the first comment. You can find it here if you REALLY need it. Use at your own risk...

Note that maybe backupmenu won't work (at least it is not working for me since I installed it).