Am Montag, 31. Oktober 2011, 12:40:12 schrieb Andrew: > 31.10.2011 13:05, KP Kirchdoerfer пишет: > > Am Montag, 31. Oktober 2011, 11:19:38 schrieb Andrew: > >> 31.10.2011 12:05, KP Kirchdoerfer пишет: > >>> Am Samstag, 29. Oktober 2011, 22:37:10 schrieb Andrew: > >>>> Hi all. > >>>> Today I have enough free time to spent it for LEAF toolchain. > >>>> Now I finished very basic rework on it, it looks like now it > >>>> should successfully compile C applications and has working C++ > >>>> compiler w/o c++ libraries (I planned to replace libstdc++ to > >>>> uClibcpp). Now compiler has native architecture - so it'll be no > >>>> pain with cross-compilation in future and it'll be easy to build > >>>> all for new architectures that are binary-incompatible with x86. > >>>> Also it reduces count of ugly tricks in toolchain. > >>> > >>> Andrew; > >>> > >>> in my case it failed while trying to build gcc: > >>> > >>> "checking for the correct version of gmp.h... no > >>> configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and > >>> MPC 0.8.0+" > >>> > >>> kp > >> > >> Do you have libgmp installed in your system? I exclude it from > >> toolchain because it is present in all modern distros, and it was > >> needed earlier only due to cross-compile x86 gcc binaries on x86_64 > >> system. > > > > I have had installed libgmp, but it does not provide gmp.h, so I > > installed libgmp-dev, libmpfr-dev and libmpc-dev. Seems to be > > different to other distributions. > > > > So it seems to build now... > > Right, development headers are needed for software building. > > >> P.S. Do we really need to pull all host-related binaries (automake, > >> etc) in toolchain? Why we can't simply use system ones, and add them > >> into buildenv prerequisites? > > > > As you can see above, even the prerequistes changes between > > distribution; but over the years we ran in all sorts of issues, when > > a host system has been changed, too new version of autoconf, later > > outdated versions, that failed due to changes in the buildtool.cfg > > files etc... So the aim was to have the buildenvironment as > > self-containded as possible to be independent of the build system. It > > is my experience that this is still the better way in the long-term. > > > > kp > > Usually troubles are present with too new versions and too old packages > - but this will be noticed by all developers who used modern distros > (and, of course, me - I use gentoo so I have enough fresh > libtool/automake/autoconf). > About old distros - maybe CentOS can be common example for such distro > (it has enough old automake/autoconf because software isn't updated > through distro lifecycle - there are only backported fixes), and I think > that there are no 'older' distros in use among peoples who are > interested in building all from source. > So IMHO it'll be enough to check building on CentOS 5 and some modern > distro (Gentoo or latest Fedora/Ubuntu) to be sure that it'll be built > on almost all target hosts. > Also, we really didn't pull all dependencies - at least Perl, make, > libtool (which sometimes cause headache), etc - so IMHO partial > dependency isn't enough good solution.
Hi Andrew; the main question is, what will happen, if a new distro breaks the toolchain? I remember vaguely, we have had struggled with this years ago... I predict, that we'll have to include prerequisites within two years :) But then, I'l be happy if it'll proof me wrong. I'm surprised about the changes for iproute (haven't had the time to look into the latest commits). I compiled iproute2 with uclibc-0.9.32 successfully without the chanes you committed. What caused the changes, if not uClibc? Just to understand, what may occur if we update other packages. kp btw: 4.1.1-beta1 has been build successfully in the background... ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
