On Thu, 2010-07-29 at 03:53 -0400, Charles Wilson wrote: > From (patch v3-7/9): > The = in func_replace_sysroot_result is the source of > forwards-compatibility problems of older Libtools. > Maybe --mode=finish could get rid of those. For platforms > such as mingw where both native and cross-compilation makes > sense, it would provide an easy way to deploy .la files > that are usable without a new libtool.
libtool --mode=finish isn't run when installing with DESTDIR. > + Caution: .la files generated with sysroot support will _not_ be > + usable in general with older Libtools. This is a problem, particularly if using sysroot-enabled libs on the $host, where libtool is almost certain to not be that new. > > Furthermore, do these patches address the issue that -L$libdir and > > -Wl,-rpath,$libdir are passed even when $libdir (or $sysroot$libdir) is > > in $sys_lib_search_path_spec? > > It doesn't appear so, but that is not a sysroot-specific issue, is it? I > mean, you still get that behavior now, even for native compilers, right? I suppose so, but it's particularly a problem with cross-compiling, as I found out lately. > However, how does this affect your decision? If --with-sysroot defaults > to no, then...nothing changes. If you choose to use > --prefix=$sysroot$prefix, it'll work just as well (or as badly) as the > same arrangement works on other $builds. (If it defaults to yes, and > you still want to use $sysroot$prefix, then you could simply add > --without-sysroot to all configures, right?) It's a matter of API/ABI: among the various cross-samples I'm working with, a few will need changes depending on whether we go with --prefix= $sysroot$prefix or --prefix=$prefix and DESTDIR=$D$sysroot. Since I'm working with a pretty small sample, I can only assume that more packages would be affected down the road. So if libtool is going to be fixed *right now*, then we'll go with that, otherwise we'll have to deal with the consequences of changing sometime later. > OTOH, if you choose to use --prefix=$prefix and the new sysroot support > in libtool, that's great (I'd want to go that route) but...it still > doesn't solve the foo-config problem -- unless you go forward with your > cross_sysrootize() function in cygport. I would also prefer to do this as well, as I did in beta1, as this is AFAICS the ultimate purpose of sysroots and would solve the issues you raised with cross-compiling libraries for the host. If libtool does get fixed, then I don't see foo-config as difficult enough by itself to warrant not going that route. Yaakov
