i'm wondering if there was a change between gcc 4.4 and 4.6. there are a few libm related issues floating, google turns up a few reports about missing libm. Maybe it was previously assumed and automatically added.

So far it seems that -lm is needed in place where earlier doesn't needed.

--
About multiple definition of `gnu_dev_major' etc. It is not warning, but error.

I found this post which I think be the most relevant:
http://us.generation-nt.com/answer/g...170398461.html

Summary:
"
The glibc support for the C99 inline semantics was added in glibc-2.6. Gcc-4.3 and later use C99 inline semantics in -std=gnu99 mode. To use any earlier version of glibc with Gcc-4.3 you need at least to backport the large patch.
"
(We have: libc6: 2.5.1-1eglibc27+0m5)

'-std=gnu99 mode' doesn't sound bad, but seems to me that it is hard to know if using some libraries triggers this.

apologies for needing to ask, but if I write the following, won't it work?
Are we allowed to use inline to write code for Maemo5? Maybe I'm missing your point? Why does do we need more recent compiler and if you convince us, what are its dependencies/pre-requesites?

Reasons are multiple, but from my perspective the most important one is 4.2 has a lot of bugs. If you try to compile most of latest libtcod using programs for example you end up having to rewrite lots of code. 4.3 and above compile without any problems (at least for libtcod, guessing 4.6 will fix even more). Autobuilder for repos uses 4.2 so porting is not easy using SDK build-essentials package. If 4.6 got into the repos you could then use it to build packages. With time more and more packages will be unbuildable on 4.2, so this will prolong N900 life immensely (until we hit a wall when newer libc/libstdc++ and rest is needed which would require updating whole maemo, which in turn with closed source components might be impossible)

I just tested to recompile some packages and they can't be compiled with newer compiler, and I'm struggling what is problem. There are also packages I haven't wrote and I have no idea are they using inlines, or are there some libraries using inlines.

Good question, I updated first post. Shortly: a) some applications need it. b) It *may* be 'better'.

I'm just solving this locally, and I'm planning to push them to the extras-devel:
make3.81 (extras-devel)
bison-2.4 (extras-devel)
binutils-2.22 (I have locally working, and maybe could be omitted)
-> gcc-4.6 can be compiled and it 'sometimes works' (as I wrote earlier).

We might need new libc6 for really using new compiler. Seems it can compile some packages, but not all. (But maybe there are no need for compile all?)

If it works, why not. Have you also seen http://stackoverflow.com/questions/4...e-math-library

According to this one: http://stackoverflow.com/questions/1...h-library-in-c the C++ runtime libstdc++ requires libm, so if you compile a C++ program with GCC (g++), you will automatically get libm linked in.

Finally, http://stackoverflow.com/questions/7...n-ubuntu-11-10 some versions require -lm to be in a certain place in command sequence or it could be because a default flag in the linker.

Theres another interesting piece of information on that page

Does the old version of GCC have TLS enabled?

It seems some other libraries need also manually added, e.g. with gcc-4.2 -lSDL_net was enough, now it must be -lSDL_net -lSDL.

gcc-4.2 -v --version doesn't response enough. I don't know answer or way to solve it.

Finally got around to reading through this entire thread, so now a question:

Why is there hesitance to recompile and upgrade libc6? I know just about every C program depends on it, but would the version difference be enough to break that much? If that's unknown, I'd be happy to use one of my N900s as a testing device (I have two, one used just for development/testing, that I'm happy to reflash).

Also, I just realized that this is why newest Subversion versions were segfaulting on the N900 - the default config/make configuration was to compile with NEON support (and it worked when you compiled without NEON), which judging by comments on this thread, was a feature that wasn't added in until a more recent version of GCC for this platform that what is currently default.

Building gcc-4.6 on autobuilder might be near impossible.
Builder won't build package with same name on SDK, e.g binutils. "Package binutils provides binary package binutils which is also available on the device or Nokia repository. Build of this package has been prevented."

Even there are package bison-2.4 which replaces bison, autobuilder wont' install it.
"E: Packages need to be removed but remove is disabled."
Solution: package 'bison-2.4' doesn't conflicts with 'bison' but contains file 'bison-2.4', and it must be called by that name.

There are now binutils2.22 on extras, and it will replace binutils, so builder won't install it -> there must be ld-2.22, ar-2.22 and so on....

**
Another finding: gcc-4.2 depends binutils *with* version, so there must be package named exactly binutils, providing it is not enough. (7.5 on http://www.debian.org/doc/debian-pol...tionships.html ). So gcc-4.2 and binutils2.22 can't be installed same time (and that was exactly my plan to compile gcc-4.6 on builder).

***

My goal was make this transparently and I though autobuilder is transparent; public build-logs, accessible source and binary packages.


Any ideas what is the second best way? Locally built and dumb to the non-free section (autobuilder might then could use gcc-4.6, but not binutils2-22)? How to get builder's policy changed? How to get builder working with CSSU-repository?

i think the reluctance is only beacuse of the risk of breaking dynamically linked closed source apps. for desktop some used to come with their own version of libc and run using a modified path to ensure its use (maybe original quake 3?). as long as it don't break compatibility, by all means testing would be much appreciated if you have the device to spare.

with regards to autobuilder, you know more than me. maybe its time for cssu-sdk repo