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@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