I suspect it is for big distributions, like debian, to keep track of
different versions of software. We aren't in debian yet, so I guess we
can ignore it pretty much for now.

Bill.

2009/3/15 Jason Moxham <ja...@njkfrudils.plus.com>:
>
> On Sunday 15 March 2009 18:06:20 Bill Hart wrote:
>> Did we decide this:
>>
>> This 3.4.1
>> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/\/\/\/\/\/\/\/\/\\//\/\/\/\/\/\/
>>\/\\/ 379214 2009-03-08 02:33 /usr/local/lib/libmpir.so.3.4.1* 37788
>> 2009-03-08 02:33 /usr/local/lib/libmpirxx.a 1123 2009-03-08 02:33
>> /usr/local/lib/libmpirxx.la* 18 2009-03-08 02:33
>> /usr/local/lib/libmpirxx.so -> libmpirxx.so.3.1.1* 18 2009-03-08 02:33
>> /usr/local/lib/libmpirxx.so.3 -> libmpirxx.so.3.1.1* 24073 2009-03-08
>> 02:33 /usr/local/lib/libmpirxx.so.3.1.1*
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> This 3.1.1
>>
>> was harmless?
>>
>> Bill.
>>
>
> This is what we did before and we didn't have a problem , so I suppose they
> are OK. It's only when we put the --enable-gmplink option in did we notice
> that the numbers are somewhat unrelated to the library version numbers.
> For example gmp-4.2.4 has the numbers
>
> assert.o  extract-dbl.o  libgmp.lai        libgmpxx.a    libgmpxx.so.4@
> mp_clz_tab.o   mp_set_fns.o  randdef.o   randmt.o   randsd.o
> compat.o  invalid.o      libgmp.so@        libgmpxx.la@  libgmpxx.so.4.0.4*
> mp_dv_tab.o    rand.o        randiset.o  randmts.o  randsdui.o
> dummy.o   libgmp.a       libgmp.so.3@      libgmpxx.lai  memory.o
> mp_get_fns.o   randbui.o     randlc2s.o  randmui.o  tal-reent.o
> errno.o   libgmp.la@     libgmp.so.3.4.4*  libgmpxx.so@  mp_bpl.o
> mp_minv_tab.o  randclr.o     randlc2x.o  rands.o    version.o
>
>
>
>
>> 2009/3/15 Bill Hart <goodwillh...@googlemail.com>:
>> > I haven't seen Michael online except for very basic sage maintenance
>> > for days. I assume he is still ill. I will be seeing him personally in
>> > a couple of weeks. I will ensure you get trac access.
>> >
>> > In the mean time, could you write a ticket and I will add it. I have
>> > no idea what re-use error in mpz_urandomm is about. I haven't been
>> > able to find it on the gmp website.
>> >
>> > Bill.
>> >
>> > 2009/3/15 Jason Moxham <ja...@njkfrudils.plus.com>:
>> >> On Sunday 15 March 2009 17:46:31 Bill Hart wrote:
>> >>> Should we tar it up and call it rc1?
>> >>
>> >> Yep
>> >>
>> >>> Does make dist remove svn dirs? Does it now touch .c and .h files in
>> >>> demos/calc? Does it name the tarball mpir-1.0.0.tar.gz automatically?
>> >>
>> >> Yes,yes,yes
>> >>
>> >>> We should also test the c++ headers on a couple of systems to ensure
>> >>> we didn't break anything there.
>> >>>
>> >>> I also want to add a ticket to trac for the issue Jason Moxham fixed
>> >>> that was reported on the gmp list. Can you remind me what that was?
>> >>
>> >> I've still not got trac access !
>> >> re-use error in mpz_urandomm , fixed , but no testcase , difficult to
>> >> write testcase for random stuff, re-use make it harder !
>> >>
>> >>> Once tarred up we can do some testing to make sure that at least
>> >>> configure is not broken on all the SkyNet machines, and check that it
>> >>> builds and passes make check on a random sample of them. We should
>> >>> test all Core 2 and Nocona machines fully as we've changed that code
>> >>> again.
>> >>>
>> >>> Bill.
>>
>>
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com
To unsubscribe from this group, send email to 
mpir-devel+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/mpir-devel?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to