This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: cygport cross-compiling beta2
On 7/28/2010 11:22 PM, Yaakov (Cygwin/X) wrote:
> On Wed, 2010-07-28 at 19:28 -0400, Charles Wilson wrote:
>> From Paolo's most recent version of his patches to provide sysroot
>> support in libtool:
>>
>> http://www.mail-archive.com/libtool-patches-mXXj517/zsQ@public.gmane.org/msg05556.html
>> [RFT PATCH v3 3/9] add --with-sysroot
>
> I still think your previous concerns about the '=' notation are valid,
> and I have yet to see those addressed. Why is it necessary in the first
> place?
AFAICT, it serves as the placeholder so that the library build process
can indicate to the client build, WHICH paths should be
sysroot-prefixed, and which should not.
E.g. it's possible you might have multiple $host trees on $build: the
regular sysroot one, but also, for instance, a separate tree for
non-free libs?
Anyway, it'd be up to the system architect to figure out how to make
that work (e.g. the paths would have to match exactly on both $build and
$host), but SOME paths in the .la might NOT be appropriate for sysroot
treatment. Using an indicator character allows you to enable this use
case, instead of blindly assuming that ALL paths shall be sysrooted.
Also, I seem to remember reading about the use of '=' in path specifiers
in some other context. ld.so.config maybe? linux's $ORIGIN support?
It's right on the tip of my brain...
Buried in the comments of the most recent patch series, Paolo had some
thoughts:
>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.
which seems like a good idea to me: maybe --mode=finish could accept a
new set of options:
--explicit-sysroot to put the $sysroot back, where
the '=' placeholder is
--no-sysroot-support just strip any '=' placeholders
or maybe just
--replace-sysroot=[] where empty is an acceptable arg.
>From (patch v3-9/9, aka the NEWS entry):
+ - Sysroot support. When cross-compiling, Libtool will try to build
+ .la files that have no references to the path of the build system
+ under which the dependent libraries are placed on the build system.
+
+ Sysroot support is enabled whenever the compiler is GCC and has
+ ben itself configured with a sysroot. It can be forced using
+ the --with-sysroot configure option, or it can be disabled using
+ the --without-sysroot configure option.
+
+ Caution: .la files generated with sysroot support will _not_ be
+ usable in general with older Libtools.
+
Also, it appears to me that, contrary to what Paolo stated, you have to
configure using --with-sysroot, or none of this activates; your .la
files will not get sysroots stripped, and won't have the '=' character
in them:
AC_ARG_WITH([sysroot],
[ --with-sysroot[=DIR] Search for dependent libraries within DIR
(or the compiler's sysroot if not specified).],
[], [with_sysroot=no])
So, the default action is to set with_sysroot=no. But then, lt_sysroot
is empty, and all '=' go away...
> 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?
> Besides causing erroneous -L flags
> pointing to the native root, this currently leads to ELF RPATHs pointing
> to the sysroot even when packages are configured with --prefix=$prefix.
Hmmm. I'll have to play with that some.
>> Ralf has promised a review this weekend, so I expect this series or
>> something close to it will be committed to libtool git master quite soon.
>
> You're being surprisingly optimistic given their track record.
Remember, cross compilers are very big in non-cygwin, non-win32,
non-red-headed-step-child areas. Hence...more support and quicker reviews.
> Sigh,
> alright, I'll let this go a few more days, but I'd really like to get
> this release out already so that we can move on to other things.
Better right and (a little) late, than wrong and early.
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?)
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.
--
Chuck