[PATCH 3/4] winegcc: Search additional arch subdir to lib dirs when cross compiling to PE targtes.
Alexandre Julliard
julliard at winehq.org
Tue Apr 6 11:00:57 CDT 2021
Jacek Caban <jacek at codeweavers.com> writes:
> On 4/6/21 1:58 PM, Alexandre Julliard wrote:
>> Jacek Caban <jacek at 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 at winehq.org
More information about the wine-devel
mailing list