details.
Now what? Are we going to live with that bug for 5.4.1?
At the very least, I propose to update to libtool 1.5.24 right after
5.4.1, unless there are significant concerns. FWIW, libtool 1.5.24 works
perfectly fine on all buil
> "TA" == Thomas Anders <[EMAIL PROTECTED]> writes:
>> 1.5.23b is not an official release, though. So what's the consensus now?
>> Stick with 1.5.22 for 5.1.4 and upgrade to 1.5.24 for 5.4.2?
TA> s/5.1.4/5.4.1/
TA> of course. It's late here.
Given 1.5.24 newness, I don't think it's wise to
Wes Hardaker wrote:
> I'd say 1.5.23b is probably safer because it's been out a while (feb).
> But 1.5.24 isn't even listed on their website and is only 9 days old.
> I'd vote against that one because it's better to be safe than sorry.
1.5.23b is not an official release, though. So what's the cons
Thomas Anders wrote:
> 1.5.23b is not an official release, though. So what's the consensus now?
> Stick with 1.5.22 for 5.1.4 and upgrade to 1.5.24 for 5.4.2?
s/5.1.4/5.4.1/
of course. It's late here.
+Thomas
-
This SF.n
> "BS" == Bruce Shaw <[EMAIL PROTECTED]> writes:
>> How much open source software requires libtool, and doesn't provide
>> it's own versions?
BS> Do we provide our own version?
Yeah, a version of libtool is actually distributed within net-snmp
itself. (which is how the whole thread got star
>From Sun's discussion:
>> The "some consolidations need it for development" argument is not
>> sufficient for delivering it. We don't ship tokenize or cw despite
>> that fact that some consolidations most definitely require them.
>> Perhaps libtool in its current form really belongs in a package
On 28/06/07, Wes Hardaker <[EMAIL PROTECTED]> wrote:
> So regardless of usage problems that libtool creates, I still believe
> it's the best choice.
Fair enough.
That's two votes for, and no objections.
I'm happy that this is as good as it gets.
Dave
-
Wes Hardaker wrote:
>> "RS" == Robert Story <[EMAIL PROTECTED]> writes:
>
> RS> Then they should provide 'compat' libraries. That's why there are
> RS> versions in the library names - so multiple versions can be
> RS> installed.
>
> I've told them that; they generally don't want to maintain t
> "DS" == Dave Shield <[EMAIL PROTECTED]> writes:
DS> a) The bunch of problems that libtool sets out to solve.
DS> (most notably portable production of shared libraries)
DS> b) The bunch of problems that libtool introduces
DS> (mostly related to version numbering, I think)
DS> Is a) signif
> "RS" == Robert Story <[EMAIL PROTECTED]> writes:
RS> Then they should provide 'compat' libraries. That's why there are
RS> versions in the library names - so multiple versions can be
RS> installed.
I've told them that; they generally don't want to maintain that many
versions. Granted, they
Robert Story wrote:
> On Tue, 26 Jun 2007 15:17:24 -0700 Wes wrote:
> WH> There are vendors that try to be more backwards compatible than we do,
> WH> and I hear from them all the time that their users complain about our
> WH> .so suffix numbers jumping upward because it breaks older application
>
On Tue, 26 Jun 2007 15:17:24 -0700 Wes wrote:
WH> There are vendors that try to be more backwards compatible than we do,
WH> and I hear from them all the time that their users complain about our
WH> .so suffix numbers jumping upward because it breaks older application
WH> builds. (and no, they don
Dave Shield wrote:
> Yes - Two.
>
> a) The bunch of problems that libtool sets out to solve.
> (most notably portable production of shared libraries)
>
> b) The bunch of problems that libtool introduces
> (mostly related to version numbering, I think)
I understand. Still, t
On 27/06/07, Thomas Anders <[EMAIL PROTECTED]> wrote:
Bruce> It appears [libttol] use is deprecated for a number of
Bruce> reasons I didn't necessarily follow.
Wes> Cause it is a pain in the neck to deal with, that's why. It solves a
Wes> lot of problems and creates a bunch more.. libtool h
Dave Shield wrote:
> On 26/06/07, Wes Hardaker <[EMAIL PROTECTED]> wrote:
>> BS> One of the Open Solaris mailing lists (sfwnv-discuss) just had a flame
>> BS> war about libtool. It appears its use is deprecated for a number of
>> BS> reasons I didn't necessarily follow.
>>
>> Cause it is a pain in
On 26/06/07, Wes Hardaker <[EMAIL PROTECTED]> wrote:
> BS> One of the Open Solaris mailing lists (sfwnv-discuss) just had a flame
> BS> war about libtool. It appears its use is deprecated for a number of
> BS> reasons I didn't necessarily follow.
>
> Cause it is a pain in the neck to deal with, th
Bruce Shaw wrote:
> Given that it appears we're stuck with it for the moment (I believe
> autoconf needs it) I'd want to have the most up-do-date version. Be
> that as it may, the last stable release here
> (http://www.gnu.org/software/libtool/) is 1.5.22. Where are you getting
> your version fro
> "TA" == Thomas Anders <[EMAIL PROTECTED]> writes:
TA> I've reviewed them and they look safe:
Your definition of safe and mine are likely different...
I'd say 1.5.23b is probably safer because it's been out a while (feb).
But 1.5.24 isn't even listed on their website and is only 9 days old.
Wes Hardaker wrote:
>>>>>> "TA" == Thomas Anders <[EMAIL PROTECTED]> writes:
>
> TA> I've just updated SVN trunk to libtool 1.5.24 [1] (from 1.5.22).
> TA> Is it worth considering to do the same for 5.4.x before 5.4.1.rc1?
>
> Have you
>>>>> "TA" == Thomas Anders <[EMAIL PROTECTED]> writes:
TA> I've just updated SVN trunk to libtool 1.5.24 [1] (from 1.5.22).
TA> Is it worth considering to do the same for 5.4.x before 5.4.1.rc1?
Have you reviewed the changelog/deltas/announcement/whatev
> "BS" == Bruce Shaw <[EMAIL PROTECTED]> writes:
BS> One of the Open Solaris mailing lists (sfwnv-discuss) just had a flame
BS> war about libtool. It appears its use is deprecated for a number of
BS> reasons I didn't necessarily follow.
Cause it is a pain in the neck to deal with, that's wh
Christensen.
>I've just updated SVN trunk to libtool 1.5.24 [1] (from 1.5.22).
Is it worth considering to do the same for 5.4.x before 5.4.1.rc1?
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addr
I've just updated SVN trunk to libtool 1.5.24 [1] (from 1.5.22).
Is it worth considering to do the same for 5.4.x before 5.4.1.rc1?
+Thomas
[1] http://pogma.com/misc/libtool/
-
This SF.net email is sponsored by DB2 Ex
23 matches
Mail list logo
