Re: another 1.5 release

[Daniel Reed]

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 introduced in a bug-fix
) branch.

Unfortunately, this problem must be resolved before Red Hat can ship
Libtool. That is, either I have to see multilib support added to the stock
Libtool or Red Hat will have to continue shipping a patched Libtool.

We can not ship a non-multilib-aware Libtool: Without multilib support in
Libtool, parts of our distribution do not build on some of our supported
targets. (Specifically, any package that links against the libraries of
another package, where such required libraries were built by Libtool and
have .la files installed *and* where both 32-bit and 64-bit versions of said
libraries are installed, fails to build.)


Right now, Red Hat is shipping a Libtool patched to add Red Hat
Linux-specific support (1.4.2-multilib); I would prefer to use GCC-specific
support (such as 1.5.10.multilib2) instead. However, if both multilib
patches are deemed inappropriate for canonical branch-1-5 and no third style
of multilib support can be proposed in the next two weeks, I have to make a
decision as to which existing patch to use in our [patched] Libtool package.

So, if neither multilib patch can be added for 1.5.12, which one would be
best to patch into our Libtool? My preference is to go with .multilib2, but
it will be a harder sell to QA to allow changing our Libtool package if only
to change which upstream-rejected patch we use :/

-- 
Daniel Reed <address@hidden>    http://people.redhat.com/djr/   
http://naim.n.ml.org/
It's true you can be anything you want--but it's far easier when your
ambition is complemented by the ambition of others. -- Kurt Vonnegut