[PATCH 3/4] winegcc: Search additional arch subdir to lib dirs when cross compiling to PE targtes.
Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> --- tools/winegcc/winegcc.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
Jacek Caban <jacek(a)codeweavers.com> writes:
@@ -635,6 +635,21 @@ static const char *get_multiarch_dir( enum target_cpu cpu ) } }
+static const char *get_pe_arch_dir( enum target_cpu cpu ) +{ + switch(cpu) + { + case CPU_x86: return "/i386"; + case CPU_x86_64: return "/x86_64"; + case CPU_ARM: return "/arm"; + case CPU_ARM64: return "/aarch64"; + case CPU_POWERPC: return "/powerpc"; + default: + assert(0); + return NULL; + } +}
I'm wondering if we shouldn't put everything into arch-specific subdirs, for generic cross-compilation support, and for 32on64 where we can't rely on the host multi-arch support. Maybe something like /i686-linux-gnu for .so and .def files, and /i686-w64-mingw32 for PE dlls and import libs? -- Alexandre Julliard julliard(a)winehq.org
On 4/6/21 1:58 PM, Alexandre Julliard wrote:
Jacek Caban <jacek(a)codeweavers.com> writes:
@@ -635,6 +635,21 @@ static const char *get_multiarch_dir( enum target_cpu cpu ) } }
+static const char *get_pe_arch_dir( enum target_cpu cpu ) +{ + switch(cpu) + { + case CPU_x86: return "/i386"; + case CPU_x86_64: return "/x86_64"; + case CPU_ARM: return "/arm"; + case CPU_ARM64: return "/aarch64"; + case CPU_POWERPC: return "/powerpc"; + default: + assert(0); + return NULL; + } +}
I'm wondering if we shouldn't put everything into arch-specific subdirs, for generic cross-compilation support, and for 32on64 where we can't rely on the host multi-arch support.
Maybe something like /i686-linux-gnu for .so and .def files, and /i686-w64-mingw32 for PE dlls and import libs?
I was mostly concerned about PE side of things and my understanding is that for 32on64 it would be enough to move PE files to /i*86*. For PE files, only CPU arch really matters so I thought it's better to just skip the rest. For example, we currently use i686-windows for clang msvc target and I think that it should use the same location for PE files as mingw target. (Sharing importlibs and static libs between PE targets is more tricky, but I think that it should work for what we need - or at least it's worth a try to allow that). For generic cross compilation, moving non-PE parts to something like /i686-linux-gnu sounds good to me. Maybe we could just uniform all PE targets to something generic like /i686-pe? Thanks, Jacek
Jacek Caban <jacek(a)codeweavers.com> writes:
On 4/6/21 1:58 PM, Alexandre Julliard wrote:
Jacek Caban <jacek(a)codeweavers.com> writes:
@@ -635,6 +635,21 @@ static const char *get_multiarch_dir( enum target_cpu cpu ) } } +static const char *get_pe_arch_dir( enum target_cpu cpu ) +{ + switch(cpu) + { + case CPU_x86: return "/i386"; + case CPU_x86_64: return "/x86_64"; + case CPU_ARM: return "/arm"; + case CPU_ARM64: return "/aarch64"; + case CPU_POWERPC: return "/powerpc"; + default: + assert(0); + return NULL; + } +} I'm wondering if we shouldn't put everything into arch-specific subdirs, for generic cross-compilation support, and for 32on64 where we can't rely on the host multi-arch support. Maybe something like /i686-linux-gnu for .so and .def files, and /i686-w64-mingw32 for PE dlls and import libs?
I was mostly concerned about PE side of things and my understanding is that for 32on64 it would be enough to move PE files to /i*86*. For PE files, only CPU arch really matters so I thought it's better to just skip the rest. For example, we currently use i686-windows for clang msvc target and I think that it should use the same location for PE files as mingw target. (Sharing importlibs and static libs between PE targets is more tricky, but I think that it should work for what we need - or at least it's worth a try to allow that).
Sure, I was thinking that the name would be hardcoded anyway, not derived from the host toolchain, so all PE toolchains would use the same name. I suggested i686-w64-mingw32 because people are familiar with it, but we could certainly pick a nicer name like i686-windows instead. OTOH if it's not going to work for import libs, then maybe we need to use the actual toolchain name for these, and i686-pe for the DLLs. -- Alexandre Julliard julliard(a)winehq.org
participants (2)
-
Alexandre Julliard -
Jacek Caban