Re: another 1.5 release

[Ralf Wildenhues]

* 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 
> >something to say to QA if it were applied to HEAD. It would also allow for 
> >some testing before being backported to a release branch.
> 
> 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 so that minor releases may be 
> made without requiring re-testing the software on all supported 
> platforms.  The 2.0 branch has not yet produced a release so it is 
> still feasable to alter a feature although our focus needs to be to 
> get 2.0 out the door since it has been gestating for over a year.
> 
> I believe that we should adhere to Albert Chin's advice that compiler 
> feature tests should be restricted to libtool.m4.

OK, how 'bout this:

We make a new config variable `shlibpath_cmd', determined in libtool.m4
(_LT_LINKER_SHLIBS) to be either empty or invoke the tag-dependent
compiler to find the file in its path.  This will then be used in ltmain
the way Daniel proposes.

For HEAD, we can try to set shlibpath_cmd on as many systems as
possible, and for branch-1-5, we either
- propose for him to use a patch only enabling this for gnu-linux/gcc
- or also integrate this restricted patch into branch-1-5 ourselves.

For branch-2-0, let's see.

Issues I'm not sure with yet:  Do we have to worry about unnormalized
paths?  Example:
$ gcc -print-file-name=libc.so.6
/lib/../lib64/libc.so.6
$ gcc -print-file-name=libxml2.la
/usr/lib/gcc/x86_64-redhat-linux/3.4.2/../../../../lib64/libxml2.la

Regards,
Ralf