[PATCH v3 2/3] tools: compiled-in paths should not be used when cross-compiling.

[Jacek Caban]

Hi Kevin,

On 2/21/22 03:12, Kevin Puetz wrote:
> When cross-compiling wine (or winelib applications), one configures
> and builds wine __tooldeps__ in one prefix,
> then builds the target separately (using --with-wine-tools)
>
> Any paths compiled into wine's tool binaries via FOODIR or BIN_TO_FOODIR
> would thus refer to that --with-wine-tools build, not to the target.
> Previously BIN_TO_LIBDIR was exempted from being prefixed by $SYSROOT,
> but really it should just not be used at all when cross-compiling.
>
> Add --wine-libdir and --wine-includedir options so these paths can be
> explicitly specified if they are not a standard location inside $SYSROOT.
> This should match the --includedir or --libdir options to configure,
> and will entirely override any built-in guessing.
>
> Signed-off-by: Kevin Puetz <PuetzKevinA at JohnDeere.com>
> --
>
> Previously it was possible to compile with a cross-winelib
> only if wine was installed inside of $SYSROOT, in one of the 3 subfolders
> that the get_lib_dir would try ($PREFIX, /usr, or /usr/local).
> And even then, build configuration's files (variables from init_argv0_dir)
> would be first in the ist and preferred if they existed.
>
> This worked for most libraries because .h and .def files aren't
> architecture-specific, so the build/host confusion caused little harm.
> And prior to wine 6.22 few libraries used static importlib.a files,
> Even for those that did the linker would *probably* reject and skip
> over wrong-architecture .a files, though more subtle problems could
> manifest if e.g. both --host and --build were some flavor of linux-x86,
> but perhaps using different gcc versions or options.


Sine wine-6.9, we install libraries into target-specific subdirectories 
of lib dir. This means that get_lib_dir() should already skip lib lib 
directories that are not compatible with specified target.


> Allowing --wine-{include,lib}dir to be specified explicitly clears up
> all this ambiguity and guessing; a cross-compiler can just say where
> the host wine binaries are and be sure winegcc won't find something else.


While we may end up needing something like this anyway (for more 
complicated cases), I think that ideally we would make the experience 
seamless by not requiring those options. One way to achieve that, would 
be to make more use of target-specific subdirectories. It should be 
possible to not use sysroot for importlibs and includes at all. I can 
imagine installing importlibs into the non-sysrooted wine tools 
installation, making this single installation capable of handling 
multiple targets. This matches a common practice for cross compilation 
sysroots: for example, I have aarch64 sysroot in 
/usr/aarch64-unknown-linux-gnu/, but GCC uses 
/usr/lib/gcc/aarch64-unknown-linux-gnu/ for libraries (and includes) 
bundled with the compiler. Once something like that is setup, it should 
work just fine now (well, I didn't try, so there may be some bugs, but 
it shouldn't be too hard to get working). This patch would prevent such 
setup from using BIN_TO_FOODIR in such case. Would better support for 
such configuration be good for your use case? Maybe we should look at 
making such thing easy to setup.


Also, as I mentioned above, lib dir should already be able to skip 
target incompatible lib dir, but we don't have similar tool for include 
dirs and I can see a point in making that more reliable. The problem 
with current architecture is that libdir and includedir may be very 
different and there is no good way to translate one path to the other. 
The solution that compilers use (both GCC and Clang) is to ship internal 
headers inside libdir. While that may seem less intuitive, it makes 
sense for such cases. From compiler's perspective, places like 
/usr/include are mostly for 3rd party libraries to expose their 
interfaces, while internal compiler headers are an implementation detail 
of the compiler itself (and are potentially tied to its compiler 
version/config). Those considerations are similar to Wine headers and 
winegcc. If we followed that pattern, we could just just use strmake( 
"%s/include", get_lib_dir()) for include dir and headers would just 
match libraries version with no extra work needed. Anyway, this part 
likely not needed for your case and I can't be sure if it's a good idea 
without trying, but that's what I came out with when I was thinking 
about more reliable way to locate includes.


Thanks,

Jacek