* 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 _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool