Re: another 1.5 release?

[Ralf Wildenhues]

* Daniel Reed wrote on Thu, Jan 27, 2005 at 10:11:25PM CET:
> On 2005-01-27T13:20+0100, Ralf Wildenhues wrote:
> ) Apart from the pending icc changes, my patch queue for branch-1-5 has
> ) mostly been flushed.  Not in the sense that there are no open issues
> ) or bugs, but in the sense that I for one most likely won't have time
> ) to attack any of the more involved ones within the next month.  Unless
> ) anybody else steps up right away, how about postponing them (most are
> ) issues for 2.0 and post anyway)?  1.5 has enough changes worthy of
> ) another update.
> 
> As far as I know, the multilib2 patch (based on gcc's -print-file-name) is in
> limbo rather than being rejected; is there any way it can go in for 1.5.12?

Not unless someone has a significant amount of time to spend, let's say,
in the next few days, to work on this.  It is not forgotten, though.

> I'd like to either have it in an official release or have it be rejected.
> Patching it in to our packages beyond one release cycle makes me feel dirty :/

It has a couple of issues:
- Platform-dependent stuff should go in libtool.m4, not in ltmain.in.
  This is not hard to do, just a bit of work.
- The patch exposes the need for normalized paths.  I posted a
  normalization function last week.  The hard work will be to find all
  the right places it needs to be used.  (Generally, path normalization
  is necessary even without multilib2, though.)
- For gcc specifically: Even your modified search algo will not work
  with a custom gcc-4 installation.  Why?  If both lib{,64}/libstdc++.la
  are installed, libtool will find the first and then bail if you
  compiled for the other ABI (and the compiler search path is looked at
  before your -print-file-name).  I noted this issue a while ago, I don't
  think it's a very major one, but it needs to be looked at eventually.

Another issue I have not checked yet:
Using stuff like pkg-config breaks very nicely if they add both
  -L/foo/lib  and -L/foo/lib64
to the command line (because we search that before -print-file-name as
well).  I do not know the extent of such possible breakage.


I'll welcome any work on this as I won't have time for it myself the
next month.  And I would very much like for the result to go into
Libtool proper.

Regards,
Ralf (sitting in front of a x86_64/FC3 at the moment)