Andrew at 23.12.2010 13:40, Andrew wrote: > 23.12.2010 14:31, Erich Titl пишет: >> Andrew >> >> at 13.12.2010 14:27, Andrew wrote: >>> 13.12.2010 09:54, Erich Titl пишет: >>>> Hi >>>> >>>> at 12.12.2010 22:52, KP Kirchdoerfer wrote: >>>>> Am Sonntag, 12. Dezember 2010, 22:34:53 schrieb Andrew: >>>>>> Hi all. >>>>>> Currently we have libgmp 4.3.2 into buildenv, and separate libgmp 5.0.1 >>>>>> as package. I want to remove separate library and assemble one that >>>>>> already present in tree. I tried to build GCC with fresh libgmp 5.0.1 >>>>>> and fresh libmpfr - when they are placed in GCC dir building is failed. >>>>>> So I have a question: we really need freshest libgmp? IMHO most software >>>>>> will run perfectly with 4.3.2 version - now and in nearest 1-2 years. >>>>> Etitl comitted the 5.0.1 package with openswan. >>>>> >>>>> openswan seem to be only package using libgmp. >>>>> So we need his knowledge to decide. >>>> Actually I just used the latest from the repository, as I did with >>>> OpenSwan. I have not been able to quickly find a hard dependency in the >>>> OpenSwan docs. When I built OpenSwan I was not aware that the compiler >>>> itself used libgmp and would not expose it afterwards, a ridiculous >>>> behaviour IMHO. >>>> >>>> Trying to find libgmp instances in my build tree revealed interesting ones >>>> >>>> ./build/openssl/usr/lib/engines/libgmp.so >>>> ./build/libgmp >>>> ./build/libgmp/usr/lib/libgmp.so.10.0.1 >>>> ./build/libgmp/usr/lib/libgmp.so >>>> ./build/libgmp/usr/lib/libgmp.la >>>> ./build/libgmp/usr/lib/libgmp.so.10 >>>> ./build/libgmp/usr/lib/libgmp.a >>>> ./source/buildenv/gcc-4.4.5-final/stage1-gmp/.libs/libgmp.lai >>>> ./source/buildenv/gcc-4.4.5-final/stage1-gmp/.libs/libgmp.la >>>> ./source/buildenv/gcc-4.4.5-final/stage1-gmp/.libs/libgmp.a >>>> ./source/buildenv/gcc-4.4.5-final/stage1-gmp/libgmp.la >>>> ./source/buildenv/gcc-4.4.5-final/gmp/.libs/libgmp.lai >>>> ./source/buildenv/gcc-4.4.5-final/gmp/.libs/libgmp.la >>>> ./source/buildenv/gcc-4.4.5-final/gmp/.libs/libgmp.a >>>> ./source/buildenv/gcc-4.4.5-final/gmp/libgmp.la >>>> ./source/buildenv/gcc-4.4.5-final/prev-gmp/.libs/libgmp.lai >>>> ./source/buildenv/gcc-4.4.5-final/prev-gmp/.libs/libgmp.la >>>> ./source/buildenv/gcc-4.4.5-final/prev-gmp/.libs/libgmp.a >>>> ./source/buildenv/gcc-4.4.5-final/prev-gmp/libgmp.la >>>> ./source/buildenv/gcc-4.4.5-initial/gmp/.libs/libgmp.lai >>>> ./source/buildenv/gcc-4.4.5-initial/gmp/.libs/libgmp.la >>>> ./source/buildenv/gcc-4.4.5-initial/gmp/.libs/libgmp.a >>>> ./source/buildenv/gcc-4.4.5-initial/gmp/libgmp.la >>>> ./source/openssl/openssl-0.9.8o/engines/libgmp.so >>>> ./source/libgmp >>>> ./source/libgmp/gmp-5.0.1/.libs/libgmp.so.10.0.1 >>>> ./source/libgmp/gmp-5.0.1/.libs/libgmp.so >>>> ./source/libgmp/gmp-5.0.1/.libs/libgmp.lai >>>> ./source/libgmp/gmp-5.0.1/.libs/libgmp.la >>>> ./source/libgmp/gmp-5.0.1/.libs/libgmp.so.10 >>>> ./source/libgmp/gmp-5.0.1/.libs/libgmp.a >>>> ./source/libgmp/gmp-5.0.1/libgmp.la >>>> ./package/libgmp.lrp >>>> ./staging/usr/lib/libgmp.so.10.0.1 >>>> ./staging/usr/lib/libgmp.so >>>> ./staging/usr/lib/libgmp.la >>>> ./staging/usr/lib/libgmp.so.10 >>>> ./staging/usr/lib/libgmp.a >>>> >>>> So at least openssl builds its own in the engines directory and gcc >>>> build one for whatever reason. >>>> >>>> Does the current gcc build leave a usable library somewhere? Mine for >>>> once doesnt. >>>> If so, is there an upgrade path for buildenv to have the latest >>>> environment, so I can use the library provided by the previous build of >>>> gcc to try to compile openswan? >>>> Should we install libgmp by default then or just make a package which is >>>> assembled from whatever gc builds? >>> Now I added building of libgmp into buildenv. I commented unneeded code >>> in libgmp package makefile, so it acts now as simple package >>> description. If it'll work OK, we will clean all unneeded code. >> Did you check in the buildenv code which does this. Do you have an idea >> how to update buildenv without crumbling up everything? >> >> I would like to update ipsec with the new libgmp locations and commit >> it, but I guess I need to upgrade my buildenv first, and doing it from >> scratch is a pain in the butt. Maybe we need to think about our makefile >> and/or buildtool.cfg dependencies. >> >> cheers >> >> Erich > You don't need to rebuild all from scratch; you can just update > buildtool.cfg/buildtool.mk (or just remove them - they'll be loaded at > build) and run buildtool.pl -f buildenv. > It'll be enough, and in that case GCC will not be rebuilt. >
It does not look like these are updated in CVS or at least diff does not see it. # buildtool config file for # the buildenvironment # $Id: buildtool.cfg,v 1.7 2010/10/29 16:00:11 davidmbrooke Exp $ # used to download everything... # $Id: buildtool.mk,v 1.10 2010/11/01 11:02:08 nitr0man Exp $ # changed for working with uclibc-bering buildtool by Arne Bernin <a...@alamut.de> # m...@luna:~/leaf/bering-uclibc/devel/src/bering-uclibc4/source/buildenv> export CVS_RSH=ssh m...@luna:~/leaf/bering-uclibc/devel/src/bering-uclibc4/source/buildenv> cvs -z3 -d:ext:et...@leaf.cvs.sourceforge.net:/cvsroot/leaf diff buildtool.cfg et...@leaf.cvs.sourceforge.net's password: m...@luna:~/leaf/bering-uclibc/devel/src/bering-uclibc4/source/buildenv> cvs -z3 -d:ext:et...@leaf.cvs.sourceforge.net:/cvsroot/leaf diff buildtool.mk et...@leaf.cvs.sourceforge.net's password: cheers Erich ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel