Active Topics
-
Firefox with Leste (10)
to Maemo 7 / Leste by teroyk - 3 days, 9 hrs ago - more...
ivgalvez |
2012-01-26
, 10:47
|
|
Posts: 1,397 |
Thanked: 2,126 times |
Joined on Nov 2009
@ Dublin, Ireland
|
#11
|
Originally Posted by Hurrian
Yes, for example Tracker, PulseAudio, Dbus... some of the components could bring bug fixes or better performance, while others could bring new features (and new bugs!) to play with.
| The Following User Says Thank You to ivgalvez For This Useful Post: | ||
|
|
2012-01-26
, 11:13
|
|
Posts: 3,074 |
Thanked: 12,960 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#12
|
Originally Posted by Hurrian
[OT]
... afaik THUMB is broken on the N900's SoC, and the workaround's overhead > benefit of THUMB
Will you be more specific on the above, i.e. which workaround overhead aganst which benefit. I will appreciate any data on the matter.
[/OT]
| The Following 3 Users Say Thank You to freemangordon For This Useful Post: | ||
|
|
2012-01-26
, 11:25
|
|
Posts: 1,225 |
Thanked: 1,905 times |
Joined on Feb 2011
@ Quezon City, Philippines
|
#13
|
Originally Posted by freemangordon
The overhead for the 430973 bug against Thumb's purported reduced code size.
[OT]
Will you be more specific on the above, i.e. which workaround overhead aganst which benefit. I will appreciate any data on the matter.
[/OT]
__________________
N9 PR 1.3 Open Mode + kernel-plus for Harmattan
@kenweknot, working on Glacier for Nemo.
N9 PR 1.3 Open Mode + kernel-plus for Harmattan
@kenweknot, working on Glacier for Nemo.
|
|
2012-01-26
, 11:46
|
|
Posts: 839 |
Thanked: 3,386 times |
Joined on Mar 2009
|
#14
|
Not all packages can be automatically recompiled with gcc-4.6, there are some stricter rules which needs hand tuning.
---
How much used binutis affects resulting binary (size/speed)? I made test compilation with gcc-4.6.1 and with old binutils and I got bigger and slower binaries (run on N900) than just using old compiler.
What are needed flags for thumb et cetera for compiling most optimized (as speed e.g.) code?
About *programs*: some programs has new features on upstream and we could just take and use them (I would say we should do it). But new versions can be using new version of libraries, so we must upgrade libraries too.
Some libraries we can just upgrade from upstream (so just do it). But some libraries aren't backward compatible and they cause recompilation of packages. And if some of them are closed source, we must drop that package. There are 355 packages waiting for alternatives (or judgement to be dropped entirely): http://wiki.maemo.org/Fremantle_closed_packages
Is there something in non-free extras we should worry?
---
How much used binutis affects resulting binary (size/speed)? I made test compilation with gcc-4.6.1 and with old binutils and I got bigger and slower binaries (run on N900) than just using old compiler.
What are needed flags for thumb et cetera for compiling most optimized (as speed e.g.) code?
Originally Posted by Hurrian
I have all ready started this, libglib: http://talk.maemo.org/showthread.php?p=1155248
While we're on the subject, why not upgrade other open components from upstream?
About *programs*: some programs has new features on upstream and we could just take and use them (I would say we should do it). But new versions can be using new version of libraries, so we must upgrade libraries too.
Some libraries we can just upgrade from upstream (so just do it). But some libraries aren't backward compatible and they cause recompilation of packages. And if some of them are closed source, we must drop that package. There are 355 packages waiting for alternatives (or judgement to be dropped entirely): http://wiki.maemo.org/Fremantle_closed_packages
Is there something in non-free extras we should worry?
| The Following 5 Users Say Thank You to AapoRantalainen For This Useful Post: | ||
|
|
2012-01-26
, 15:09
|
|
Posts: 3,074 |
Thanked: 12,960 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#16
|
Originally Posted by Hurrian
Well, I am pretty aware of that errata, I was asking for some real data, not what your expectations are.
The overhead for the 430973 bug against Thumb's purported reduced code size.
In short - what is the overhead from workaround for ARM errata 430973.
Because I can give some hard values for thumb2:
from only Qt, gtk, hildon-desktop, hildon-home and hildon-status-menu thumb2 compiled the reduction of code size is exactly 19MB. If you wish I can search on #maemo-ssu for how is memory consumption reduced (for several Qt/QML applications), but it varies between 2 and 6 %. And from my personal experience helium-moble-browser is much faster and less laggy when run on top of thumb2 compiled Qt.
Have in mind that I am not arguing whether it is better to have thumb2 (with errata workaround) or not, I am missing data to do the evaluation, thus my question.
@AapoRantalainen - if you feel this is totally OT, my apologies, I will start a new thread, just say it.
| The Following 6 Users Say Thank You to freemangordon For This Useful Post: | ||
|
|
2012-01-26
, 19:20
|
|
Posts: 2,076 |
Thanked: 3,268 times |
Joined on Feb 2011
|
#17
|
Can't vouch for Aapo, but as long this is on-topic in regards to optimizations (available/possible in near future) and compiling seems totally fine for me. For on-device compilators this would be an awesome improvement - more space for libs, more memory (less restarts when compiling things that take >700mb of memory).
Having no-clue really about the underlying mechanics, but the few pdfs out there do hint at ~20% more space (or ~6% with speed increase), so would love to see this happen (all the above posts point to this being enormous project though requiring refresh of the whole system). If someone has an idea how to get this done, please share. I am willing to test all the closed packages compatibility with newer libstdc++/gcc, if someone knows how to approach this.
Having no-clue really about the underlying mechanics, but the few pdfs out there do hint at ~20% more space (or ~6% with speed increase), so would love to see this happen (all the above posts point to this being enormous project though requiring refresh of the whole system). If someone has an idea how to get this done, please share. I am willing to test all the closed packages compatibility with newer libstdc++/gcc, if someone knows how to approach this.
| The Following 3 Users Say Thank You to szopin For This Useful Post: | ||
|
|
2012-02-08
, 08:58
|
|
Posts: 839 |
Thanked: 3,386 times |
Joined on Mar 2009
|
#18
|
Here is some results, I hope somebody could give some hint.
--
Binutils.
Seems recent binutils is needed and will not itself has hard dependencies, so I started from it.
Binutils-2.22 from debian packed fine
modifications/configured:
* with_multiarch := no (compiling for i386 will be easier)
* # with_gold = yes (there are bug in gcc-4.2 and it can't compile gold (internal compiler error). "gold = A new, faster, ELF only linker, still in beta test." Seems to be optional).
* using 'tar -c -z' instead of 'tar -c --xz' (Maemo's tar can't handle xz)
Packages can be installed and they seems work, but linking causes warnings:
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.22 assertion fail ../../bfd/elf32-arm.c:11467
which is:
And sometimes I must add "-lm" even sources were compiled earlier without it.
Linked binaries work on device.
-----------
Gcc
gcc-4.6.1-9 from Ubuntu 11.10.
Modifications:
*version's of dependencies dropped (seems ubuntu is over rated them)
dpkg-dev (1.16.0 -> 1.14.15)
gcc (4.4 -> 4.2)
libmpfr (3.0.0 -> 2.4.2)
libgmp-dev 5.0.1 -> libgmp3-dev 4.3.1
libelf0 0.8.12 -> 0.8.10
doxygen (1.7.2 -> 1.5.1)
*multi_arch =no
*uses binutils-2.22)
Packages can be installed, compilation works, but linking NOT. There are many errors like this:
File /usr/include/sys/sysmacros.h is coming from libc6-dev.
---------
Libc
eglibc-2.13-20 from Ubuntu 11.10
Modifications:
* Maemo's patch doesn't understand: " patch: unrecognized option `--reject-format=unified' "
* Some dependencies were too high
Compilation fails with rpcgen. According to the FAQ
-----------
So do I must compile libc6 also? Doest this cause harm when running on device? Is my compilation order correct?
--
Binutils.
Seems recent binutils is needed and will not itself has hard dependencies, so I started from it.
Binutils-2.22 from debian packed fine
modifications/configured:
* with_multiarch := no (compiling for i386 will be easier)
* # with_gold = yes (there are bug in gcc-4.2 and it can't compile gold (internal compiler error). "gold = A new, faster, ELF only linker, still in beta test." Seems to be optional).
* using 'tar -c -z' instead of 'tar -c --xz' (Maemo's tar can't handle xz)
Packages can be installed and they seems work, but linking causes warnings:
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.22 assertion fail ../../bfd/elf32-arm.c:11467
which is:
Code:
/* If the output has no requirement about FP hardware,
follow the requirement of the input. */
if (out_attr[i].i == 0)
{
11467 BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0);
out_attr[i].i = in_attr[i].i;
out_attr[Tag_ABI_HardFP_use].i
= in_attr[Tag_ABI_HardFP_use].i;
break;
}
Linked binaries work on device.
-----------
Gcc
gcc-4.6.1-9 from Ubuntu 11.10.
Modifications:
*version's of dependencies dropped (seems ubuntu is over rated them)
dpkg-dev (1.16.0 -> 1.14.15)
gcc (4.4 -> 4.2)
libmpfr (3.0.0 -> 2.4.2)
libgmp-dev 5.0.1 -> libgmp3-dev 4.3.1
libelf0 0.8.12 -> 0.8.10
doxygen (1.7.2 -> 1.5.1)
*multi_arch =no
*uses binutils-2.22)
Packages can be installed, compilation works, but linking NOT. There are many errors like this:
Code:
test.o: In function `gnu_dev_major': //usr/include/sys/sysmacros.h:43: multiple definition of `gnu_dev_major'
---------
Libc
eglibc-2.13-20 from Ubuntu 11.10
Modifications:
* Maemo's patch doesn't understand: " patch: unrecognized option `--reject-format=unified' "
* Some dependencies were too high
Compilation fails with rpcgen. According to the FAQ
1.22. `make' fails when running rpcgen the first time, what is going on? How do I fix this?
{CO} The first invocation of rpcgen is also the first use of the recently compiled dynamic loader. If there is any problem with the dynamic loader it will more than likely fail to run rpcgen properly. This could be due to any number of problems.
The only real solution is to debug the loader and determine the problem yourself. Please remember that for each architecture there may be various patches required to get glibc HEAD into a runnable state. The best course of action is to determine if you have all the required patches.
So do I must compile libc6 also? Doest this cause harm when running on device? Is my compilation order correct?
| The Following 8 Users Say Thank You to AapoRantalainen For This Useful Post: | ||
|
|
2012-02-10
, 09:54
|
|
Posts: 1,203 |
Thanked: 3,027 times |
Joined on Dec 2010
|
#19
|
can't recall off the top of my head. normally i rebuild them only when creating a toolchain for building distros, not updating an existing one. having said that, i would still use the same order you are using. with respect to bootstrapping, other than comparing builds, it helps remove traces of old gcc from build by compiling itslef with newly generated binary:
1st build: gcc 4.6 built with 4.2
2nd build: 4.6 built with 4.6 built with 4.2
3rd build 4.6 built with 4.6 built with 4.6
are you sure you're making use of the new binutils?
libc6 (provided in glibc) in ubuntu used to depend on libgcc1, might still do, so you might have circular dependancies using current build method. what happens if you try to build+boostrap just gcc c compiler, then come back and do c and c++ without bootstrap after glibc?
make sure libtool using correct paths after gcc build. it might still be hardcoded to old version of gcc.
1st build: gcc 4.6 built with 4.2
2nd build: 4.6 built with 4.6 built with 4.2
3rd build 4.6 built with 4.6 built with 4.6
are you sure you're making use of the new binutils?
libc6 (provided in glibc) in ubuntu used to depend on libgcc1, might still do, so you might have circular dependancies using current build method. what happens if you try to build+boostrap just gcc c compiler, then come back and do c and c++ without bootstrap after glibc?
make sure libtool using correct paths after gcc build. it might still be hardcoded to old version of gcc.
| The Following 3 Users Say Thank You to Android_808 For This Useful Post: | ||
|
|
2012-02-10
, 11:36
|
|
Posts: 839 |
Thanked: 3,386 times |
Joined on Mar 2009
|
#20
|
I installed new binutils and new gcc and checked gcc-4.6 --version -v
if there are anything suspicious (or even not-perfect) in configurations, please comment.
compiled by GNU C version 4.6.1, GMP version 4.3.2, MPFR version 2.4.2-p1, MPC version 0.9
GNU ld (GNU Binutils for Debian) 2.22
And this gcc-packaging uses 'ld --sysroot', which is not working with old binutils, so I'm sure it is compiled with new binutils.
(It is possible to compile gcc-4.6 with binutils-2.18, just disabling --sysroot. Truly speaking I do not know what this means.)
(and g++ -> g++-4.6)
--
I made more application tests with gcc-4.6 and binutils-2.22
A) multifile complex c-application which is using sin (libm.so)
B) c-application without sin:
works
c) c++ application without sin:
works
d) naive sin-test: works:
---
So I'm still wondering is there need for compiling libc6?
My fault was start testing new compiler with huge and complex application. It caused lots of warning relating /usr/include/sys/stat.h and libm.so, which come from libc6-dev and libc6. (Same test compiles under Ubuntu with gcc-4.6 so it is not just deprecation of gcc-4.2). Maybe I should just compile everything lying on hard disk with gcc-4.6 and collect similarities from every failing applications.
Last edited by AapoRantalainen; 2012-02-10 at 17:36. Reason: typo
Code:
Using built-in specs. COLLECT_GCC=gcc-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6.1/lto-wrapper gcc-4.6 (Debian 4.6.1-9ubuntu3) 4.6.1 Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi Thread model: posix gcc version 4.6.1 (Debian 4.6.1-9ubuntu3) COLLECT_GCC_OPTIONS='--version' '-v' /usr/lib/gcc/arm-linux-gnueabi/4.6.1/cc1 -quiet -v -imultilib . -imultiarch arm-linux-gnueabi help-dummy -quiet -dumpbase help-dummy -auxbase help-dummy -version --version -o /tmp/ccl7Wdzd.s GNU C (Debian 4.6.1-9ubuntu3) version 4.6.1 (arm-linux-gnueabi) compiled by GNU C version 4.6.1, GMP version 4.3.2, MPFR version 2.4.2-p1, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='--version' '-v' as -meabi=5 --version -o /tmp/ccc8qQgm.o /tmp/ccl7Wdzd.s GNU assembler (GNU Binutils for Debian) 2.22 This assembler was configured for a target of `arm-linux-gnueabi'. COMPILER_PATH=/usr/lib/gcc/arm-linux-gnueabi/4.6.1/:/usr/lib/gcc/arm-linux-gnueabi/4.6.1/:/usr/lib/gcc/arm-linux-gnueabi/:/usr/lib/gcc/arm-linux-gnueabi/4.6.1/:/usr/lib/gcc/arm-linux-gnueabi/ LIBRARY_PATH=/usr/lib/gcc/arm-linux-gnueabi/4.6.1/:/usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../://lib/://usr/lib/ COLLECT_GCC_OPTIONS='--version' '-v' /usr/lib/gcc/arm-linux-gnueabi/4.6.1/collect2 --sysroot=/ --build-id --no-add-needed --as-needed --eh-frame-hdr -dynamic-linker /lib/ld-linux.so.3 -X --hash-style=both -m armelf_linux_eabi --version /usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../crt1.o /usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../crti.o /usr/lib/gcc/arm-linux-gnueabi/4.6.1/crtbegin.o -L/usr/lib/gcc/arm-linux-gnueabi/4.6.1 -L/usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../.. -L//lib -L//usr/lib /tmp/ccc8qQgm.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/arm-linux-gnueabi/4.6.1/crtend.o /usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../crtn.o collect2 version 4.6.1 (ARM GNU/Linux with ELF) /usr/bin/ld --sysroot=/ --build-id --no-add-needed --as-needed --eh-frame-hdr -dynamic-linker /lib/ld-linux.so.3 -X --hash-style=both -m armelf_linux_eabi --version /usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../crt1.o /usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../crti.o /usr/lib/gcc/arm-linux-gnueabi/4.6.1/crtbegin.o -L/usr/lib/gcc/arm-linux-gnueabi/4.6.1 -L/usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../.. -L//lib -L//usr/lib /tmp/ccc8qQgm.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/arm-linux-gnueabi/4.6.1/crtend.o /usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../crtn.o GNU ld (GNU Binutils for Debian) 2.22
Originally Posted by Android_808
Seems I'm doing this already:
it helps remove traces of old gcc from build by compiling itslef with newly generated binary:
1st build: gcc 4.6 built with 4.2
2nd build: 4.6 built with 4.6 built with 4.2
3rd build 4.6 built with 4.6 built with 4.6
compiled by GNU C version 4.6.1, GMP version 4.3.2, MPFR version 2.4.2-p1, MPC version 0.9
Originally Posted by Android_808
GNU assembler (GNU Binutils for Debian) 2.22
are you sure you're making use of the new binutils?
GNU ld (GNU Binutils for Debian) 2.22
And this gcc-packaging uses 'ld --sysroot', which is not working with old binutils, so I'm sure it is compiled with new binutils.
(It is possible to compile gcc-4.6 with binutils-2.18, just disabling --sysroot. Truly speaking I do not know what this means.)
Originally Posted by Android_808
libtool is pointing to the gcc. I have /usr/bin/gcc -> gcc-4.6
make sure libtool using correct paths after gcc build. it might still be hardcoded to old version of gcc.
(and g++ -> g++-4.6)
--
I made more application tests with gcc-4.6 and binutils-2.22
A) multifile complex c-application which is using sin (libm.so)
Code:
/usr/bin/ld: test.a(test.o): undefined reference to symbol 'sinf@@GLIBC_2.4' /usr/bin/ld: note: 'sinf@@GLIBC_2.4' is defined in DSO /usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../libm.so so try adding it to the linker command line /usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../libm.so: could not read symbols: Invalid operation collect2: ld returned 1 exit status
works
c) c++ application without sin:
works
d) naive sin-test: works:
Code:
/*gcc math_test.c -lm*/
#include <stdio.h>
#include <math.h>
#define PI 3.14159265
int main ()
{
double param, result;
param = 30.0;
result = sinf (param*PI/180);
printf ("The sine of %lf degrees is %lf.\n", param, result );
return 0;
}
So I'm still wondering is there need for compiling libc6?
My fault was start testing new compiler with huge and complex application. It caused lots of warning relating /usr/include/sys/stat.h and libm.so, which come from libc6-dev and libc6. (Same test compiles under Ubuntu with gcc-4.6 so it is not just deprecation of gcc-4.2). Maybe I should just compile everything lying on hard disk with gcc-4.6 and collect similarities from every failing applications.
Last edited by AapoRantalainen; 2012-02-10 at 17:36. Reason: typo
| The Following 4 Users Say Thank You to AapoRantalainen For This Useful Post: | ||