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

Reply via email to