[maemo-developers] some tests with dt_gnu_hash
After giving up on using scratchbox, I was able to build a new binutils and glibc with the patch to add support for the new hash format. I then upgraded the 770 libc. To test it, I recompiled the largest lib that I have the source for (gtk+ gtk+2.0_2.6.10-2.osso19). The results are interesting. The size went from 2989688 to 2987348 ( 1%), but the time to dlopen it and dlsym gtk_init improved from 0.25 to 0.21 (16%). Note that I have compiled only gtk and glibc. Not all the dependencies! The glibc patch is attached. I will try to backport the binutils patch and post it later. Best Regards, Rafael glibc-maemo.patch.bz2 Description: BZip2 compressed data ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] location of the source packages
Why does sardine source packages are located at http://repository.maemo.org/pool/sardine/main/source instead of using the more usual layout of having the source in the same directory as the binaries? This is causing some problems. For example, apt-get source busybox fails with Err http://repository.maemo.org sardine/main busybox 3:1.01-4.osso10 (tar) 404 Not Found [IP: 200.157.208.234 80] Best Regards, Rafael ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] where is the busybox source?
After sending the previous email, I realised that the busybox source is missing :-( Where is it? I tried to download the 1.01 release from the busybox site, but this is not the version that the dsc expects: dpkg-source: warning: extracting unsigned source package (./busybox_1.01-4.osso10.dsc) dpkg-source: error: file busybox_1.01.orig.tar.gz has size 115 instead of expected 1170390 Best Regards, Rafael ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] please package gnu find a grep
I have been able to create a chroot with sardine packages. Now I am trying to build some packages in it. One problem is that the utilities provided in busybox are not powerful enough. Compiling gnu grep and findutils I was able to replace busybox with the gnu packages and now I can build some packages in the new chroot :-) Best Regards, Rafael P.S.: I will send bug reports when the bugzilla is back ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] please use #!/usr/bin/perl instead of #!/scratchbox/tools/bin/perl
The autotool packages in sardine use /scratchbox/tools/bin/perl as the interpreter. Because of this, it is not possible to use them outside scratchbox. Changing the interpreter to /usr/bin/perl should fix this. The package would continue to work on scratchbox and would also work in an ordinary chroot. Best Regards, Rafael ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] using a chroot instead of scratchbox
I had so many problems with scratchbox that I decided to try to use a simple chroot instead. With the changes I have send in the previous emails ,I am now able to run debootstrap and use the resulting chroot to build gtk! Next step: build an ARM chroot :-) Rafael ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] please use #!/usr/bin/perl instead of #!/scratchbox/tools/bin/perl
I believe this suggestion was already given to you, so I wonder if you have any particular reason to not follow it. bugzilla was (is?) down, -- Misha Rafael ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] please use #!/usr/bin/perl instead of #!/scratchbox/tools/bin/perl
It does not seem to be down: I just checked the bugs and filed a new one. :) Are you sure you used https as the protocol? What error message do you get? It was a sql error. It is ok now. Thanks, Rafael ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] invalid Release files in repository.maemo.org
The Release files (http://repository.maemo.org/dists/mistral/Release for example) don't include the necessary checksums. The Release files in tableteer are ok (http://catalogue.tableteer.nokia.com/certified/dists/mistral/Release). Not having the checksums breaks debootstrap. Best Regards, Rafael ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] small changes to the dependencies to make debootstrap work
debootstrap dependency computation is not very smart, so I had to make some changes to get debootstrap to work: 1) remove debconf dependency on debconf-i18n (only debconf-english is available) 2) replace sysvinit dependency on coreutils with busybox 3) replace osso-af-utils dependency on osso-icons with sdk-default-icons Best Regards, Rafael ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] i386 dbus init.d script checks for an ARM cpu
The /etc/init.d/dbus script contain the line echo `uname -m` | grep ^armv /dev/null This causes the script to fail when run on a i386 (because of a set -e at the top). Best Regards, Rafael ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] use DT_GNU_HASH
yes, PyGTK slowness came mostly from resolving about 3k symbols. :-) PyGTK also uses a lot of time creating python objects during startup. But this will surely help, and GTK itself also exports many symbols. Rafael, does your 50% is related to _gtk.so import? It is a test that just dlopens the same libraries as openoffice. Rafael ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] use DT_GNU_HASH
Jakub Jelinek has developed a new hash section for elf DSOs. It uses a better hash function and a much better chain format. In a test that dlopens a lot of files, the new hash format produces a 50% speedup! Should we consider using it in maemo? Best Regards, Rafael ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] ld.so: rtld.c: 288: _dl_start_final: [patch] Assertion `info-l.l_tls_modid == 0' failed!
I have found that this assertion failure is caused by a uninitialized variable in libc. The attached patch fixes the problem. Best Regards, Rafael libc.patch Description: Binary data ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] bug in ARM thumb usermode emulation
Running python 2.4 in qemu sometimes causes this assert Inconsistency detected by ld.so: rtld.c: 288: _dl_start_final: Assertion `info-l.l_tls_modid == 0' failed! The same error is present in all versions tested (0.8.1, 0.8.2 and CVS). I have been able to create a small ARM chroot that contais a test program and python 2.4. It is available at http://www.maemo.org.br/platform/rafael/qemu-bug.tar.bz2 The test program sets some environment variables and execs python. The test can be run with sudo chroot bug/ ./test An equivalent test program that skips qemu runs correctly in a real ARM device, so I thing that the bug is really in qemu. The bug is very dependent on the environment variables and argv. Small changes can hide the bug. Do you have any suggestions on how to debug this? Thanks, Rafael ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: using __attribute__ ((visibility hidden)))
An updated patch is attached. The results are
without the patch
atk.so: 616 relocations, 600 relative (97%), 252 PLT entries, 0 for
local syms (0%), 0 users
pango.so: 727 relocations, 710 relative (97%), 280 PLT entries, 0 for
local syms (0%), 0 users
pangocairo.so: 67 relocations, 59 relative (88%), 42 PLT entries, 0
for local syms (0%), 0 users
_glade.so: 64 relocations, 53 relative (82%), 55 PLT entries, 0 for
local syms (0%), 0 users
gtkunixprint.so: 108 relocations, 98 relative (90%), 63 PLT entries, 0
for local syms (0%), 0 users
_gtkimpl.so: 12509 relocations, 12468 relative (99%), 3452 PLT
entries, 0 for local syms (0%), 0 users
with patch
atk.so: 592 relocations, 576 relative (97%), 252 PLT entries, 0 for
local syms (0%), 0 users
pango.so: 708 relocations, 691 relative (97%), 280 PLT entries, 0 for
local syms (0%), 0 users
pangocairo.so: 66 relocations, 58 relative (87%), 42 PLT entries, 0
for local syms (0%), 0 users
_glade.so: 63 relocations, 52 relative (82%), 55 PLT entries, 0 for
local syms (0%), 0 users
gtkunixprint.so: 104 relocations, 94 relative (90%), 63 PLT entries, 0
for local syms (0%), 0 users
_gtkimpl.so: 12314 relocations, 12273 relative (99%), 3452 PLT
entries, 0 for local syms (0%), 0 users
Best Regards,
Rafael
Python for Maemo,
INdT
Index: codegen/codegen.py
===
RCS file: /cvs/gnome/pygtk/codegen/codegen.py,v
retrieving revision 1.118
diff -u -r1.118 codegen.py
--- codegen/codegen.py 14 Jul 2006 01:39:07 - 1.118
+++ codegen/codegen.py 17 Jul 2006 14:30:44 -
@@ -10,6 +10,8 @@
import override
import reversewrapper
+visibility = '__attribute__ ((visibility (hidden)))'
+
class Coverage(object):
def __init__(self, name):
self.name = name
@@ -91,7 +93,7 @@
class Wrapper:
type_tmpl = (
-'PyTypeObject Py%(typename)s_Type = {\n'
+'PyTypeObject ' + visibility + ' Py%(typename)s_Type = {\n'
'PyObject_HEAD_INIT(NULL)\n'
'0, /* ob_size */\n'
'%(classname)s, /* tp_name */\n'
@@ -1287,16 +1289,17 @@
self.fp.write('\n\n')
def write_type_declarations(self):
+#todo use 'static' if used only in one file
self.fp.write('/* -- forward type declarations -- */\n')
for obj in self.parser.boxes:
if not self.overrides.is_type_ignored(obj.c_name):
-self.fp.write('PyTypeObject Py' + obj.c_name + '_Type;\n')
+self.fp.write('PyTypeObject ' + visibility + 'Py' + obj.c_name + '_Type;\n')
for obj in self.parser.objects:
if not self.overrides.is_type_ignored(obj.c_name):
-self.fp.write('PyTypeObject Py' + obj.c_name + '_Type;\n')
+self.fp.write('PyTypeObject ' + visibility + 'Py' + obj.c_name + '_Type;\n')
for interface in self.parser.interfaces:
if not self.overrides.is_type_ignored(interface.c_name):
-self.fp.write('PyTypeObject Py' + interface.c_name + '_Type;\n')
+self.fp.write('PyTypeObject ' + visibility + 'Py' + interface.c_name + '_Type;\n')
self.fp.write('\n')
def write_body(self):
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] using __attribute__ ((visibility hidden)))
I am trying to improve the load time of the gtk module. The attached patch is a first attempt at reducing the number of relocations. The results of applying this patch were _gtk.so-orig: 12122 relocations, 12081 relative (99%), 3451 PLT entries, 0 for local syms (0%), 0 users _gtk.so-patch: 11928 relocations, 11887 relative (99%), 3451 PLT entries, 0 for local syms (0%), 0 users I think that most relative relocations are generated because of global tables with pointer to strings of functions. I have no idea why there are so many PLTs. Rafael Python for maemo, INdT visibily.patch Description: Binary data ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
