01.11.2011 01:39, KP Kirchdoerfer пишет: > 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? This wasn't happened earlier (maybe except one or two exclusions) - at least, updating autoconf/automake wasn't > 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. Let's look. > 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 This is not for uClibc. This is for right cross-compilation. iproute2 makefile isn't designed for cross-compilation (it has hardcoded gcc name and it's flags & so on). This is one of mentioned non-trivial exclusions. Possible in later versions it will be fixed and we'll not need to have such ugly tricks in our makefile.
------------------------------------------------------------------------------ RSA® Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
