[PATCH 3/4] winegcc: Search additional arch subdir to lib dirs when cross compiling to PE targtes.

[Jacek Caban]

Signed-off-by: Jacek Caban 
---
  tools/winegcc/winegcc.c | 17 +++++++++++++++++
  1 file changed, 17 insertions(+)

[Alexandre Julliard]

Jacek Caban  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?

[Jacek Caban]

On 4/6/21 1:58 PM, Alexandre Julliard wrote:
> Jacek Caban  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

[Alexandre Julliard]

Jacek Caban  writes:
> On 4/6/21 1:58 PM, Alexandre Julliard wrote:
> > Jacek Caban  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.