Hi,
Looks like we are going to have a 1.5.12 before years end.
Prior to releasing this I'd like to hear from libtool package maintainers on
various distributions if they are patching their libtool packages, what the
patches are, and if we can get them into HEAD and the stable branch prior to
a r
On 2004-11-30T23:01+0900, Peter O'Gorman wrote:
) Prior to releasing this I'd like to hear from libtool package maintainers on
) various distributions if they are patching their libtool packages, what the
) patches are, and if we can get them into HEAD and the stable branch prior to
Red Hat's curre
On 2004-11-30T11:31-0500, Daniel Reed wrote:
) for multilib to be made available in branch-1-5 (possibly by incorporating
) .multilib2 into 1.5.12).
It's looking like I may be able to get current Libtool into the final RHEL 4
release.
Is there any chance .multilib2 can be incorporated into 1.5.12
* Daniel Reed wrote on Fri, Dec 03, 2004 at 12:36:24AM CET:
> On 2004-11-30T11:31-0500, Daniel Reed wrote:
> ) for multilib to be made available in branch-1-5 (possibly by incorporating
> ) .multilib2 into 1.5.12).
>
> It's looking like I may be able to get current Libtool into the final RHEL 4
>
On Thu, 2004-12-02 at 18:36 -0500, Daniel Reed wrote:
> Is there any chance .multilib2 can be incorporated into 1.5.12? As written,
> it simply causes libtool to ask gcc to find .la files if gcc is in use. It
> should have no impact on non-gcc builds and should not cause any files to be
> missed (
* Scott James Remnant wrote on Fri, Dec 03, 2004 at 10:06:01AM CET:
> On Thu, 2004-12-02 at 18:36 -0500, Daniel Reed wrote:
>
> > Is there any chance .multilib2 can be incorporated into 1.5.12? As written,
> > it simply causes libtool to ask gcc to find .la files if gcc is in use. It
> > should ha
On 2004-12-03T11:08+0100, Ralf Wildenhues wrote:
) * Scott James Remnant wrote on Fri, Dec 03, 2004 at 10:06:01AM CET:
) > On Thu, 2004-12-02 at 18:36 -0500, Daniel Reed wrote:
) > > Is there any chance .multilib2 can be incorporated into 1.5.12? As
written,
) > > it simply causes libtool to ask g
On 2004-12-03T08:33+0100, Ralf Wildenhues wrote:
) * Daniel Reed wrote on Fri, Dec 03, 2004 at 12:36:24AM CET:
) > It's looking like I may be able to get current Libtool into the final RHEL 4
) > release.
) Great! How much time do you have left?
The final cut off was a few months ago, but there w
On Fri, Dec 03, 2004 at 08:33:41AM +0100, Ralf Wildenhues wrote:
> * Daniel Reed wrote on Fri, Dec 03, 2004 at 12:36:24AM CET:
> > Is there any chance .multilib2 can be incorporated into 1.5.12? As written,
> > it simply causes libtool to ask gcc to find .la files if gcc is in use. It
> > should ha
On Fri, 3 Dec 2004, Albert Chin wrote:
On Fri, Dec 03, 2004 at 08:33:41AM +0100, Ralf Wildenhues wrote:
* Daniel Reed wrote on Fri, Dec 03, 2004 at 12:36:24AM CET:
Is there any chance .multilib2 can be incorporated into 1.5.12? As written,
it simply causes libtool to ask gcc to find .la files if gc
On 2004-12-03T11:48-0600, Bob Friesenhahn wrote:
) On Fri, 3 Dec 2004, Albert Chin wrote:
) > Shouldn't we come up with a more general solution first? Embedding
) > knowledge of a specific compiler in ltmain.sh is wrong. That's what
) > libtool.m4 is for.
The GCC-specific code operates (and must o
On Fri, 3 Dec 2004, Daniel Reed wrote:
On 2004-12-03T11:48-0600, Bob Friesenhahn wrote:
) On Fri, 3 Dec 2004, Albert Chin wrote:
) > Shouldn't we come up with a more general solution first? Embedding
) > knowledge of a specific compiler in ltmain.sh is wrong. That's what
) > libtool.m4 is for.
The
On 2004-12-03T13:03-0600, Bob Friesenhahn wrote:
) On Fri, 3 Dec 2004, Daniel Reed wrote:
) > The patch is specific to GCC, not Linux. Any operating system that uses a
) > multilib-capable GCC should be supported by the code introduced in this
) > patch.
) Profound changes like this should not be i
Bob Friesenhahn wrote:
Profound changes like this should not be introduced in a bug-fix branch.
So do you think it is okay for HEAD? I think Daniel would at least have
something to say to QA if it were applied to HEAD. It would also allow for
some testing before being backported to a release bran
On Sat, 4 Dec 2004, Peter O'Gorman wrote:
Bob Friesenhahn wrote:
Profound changes like this should not be introduced in a bug-fix branch.
So do you think it is okay for HEAD? I think Daniel would at least have
something to say to QA if it were applied to HEAD. It would also allow for
some testing
On 2004-12-03T17:18-0600, Bob Friesenhahn wrote:
) It is certainly much safer and wiser to make such changes to HEAD.
) It supports proving that the changes don't break for GCC users on
) other platforms without placing a stable release branch at risk. The
) reason for stable release branches is s
Daniel Reed wrote:
The check for GCC is done outside of the scope of the change; all that is
checked in the new code is whether -print-file-name works, which will pass
for all recent versions of GCC.
Silly question, but does gcc -print-search-dirs print different dirs when
64bit multilib options a
On Sat, 4 Dec 2004, Peter O'Gorman wrote:
Daniel Reed wrote:
The check for GCC is done outside of the scope of the change; all that is
checked in the new code is whether -print-file-name works, which will pass
for all recent versions of GCC.
Silly question, but does gcc -print-search-dirs print dif
Bob Friesenhahn wrote:
Silly question, but does gcc -print-search-dirs print different dirs
when 64bit multilib options are specified? Maybe we just need to add
CFLAGS etc to the -print-search-dirs test in libtool.m4?
The results are always the same for a multi-libed GCC under Solaris.
Darn, I k
* Bob Friesenhahn wrote on Sat, Dec 04, 2004 at 12:18:47AM CET:
> On Sat, 4 Dec 2004, Peter O'Gorman wrote:
> >Bob Friesenhahn wrote:
> >
> >>Profound changes like this should not be introduced in a bug-fix branch.
> >
> >So do you think it is okay for HEAD? I think Daniel would at least have
> >s
* Daniel Reed wrote on Fri, Dec 03, 2004 at 05:20:36PM CET:
> On 2004-12-03T08:33+0100, Ralf Wildenhues wrote:
>
> ) Technical issues with the patch:
> ) - Why is, after your patch, $found set twice before searching (is there a
> ) reason for this)?
>
> Libtool seems to use the state "$found = no
On 2004-12-08T18:47+0100, Ralf Wildenhues wrote:
) Before as well as after your change, the first part of the search
) algorithm finds the libstdc++.la which belongs to the 32bit version
) and shortcuts your second part. Linking tests/tagdemo/libfoo.la fails
) happily.
If something is specifying
22 matches
Mail list logo
