Re: [Mingw-w64-public] [PATCH 03/18] crt: Add an initial libarm64 directory with def files

[Martin Storsjö]

On Wed, 9 Aug 2017, Jacek Caban wrote:


On 08.08.2017 22:32, Martin Storsjö wrote:

The libarm64 directory is a copy of libarm32 with minimal modifications
(renamings in the *.mri scripts and in Makefile.am).



In that case I don't think we should have actual copies of every single
.def file. It should be possible to use the same files for both
platforms by simply modifying Makefile.am. Maybe we should have libarm/
for common files and then libarm32/ and libarm64/ for things that
differ? I'm not sure about the exact solution, but I think we should
share those one way or another.


So, I took an initial look at this. It's rather messy though...

First off, there's a bucketload of completely unnecessary def files in 
there, that aren't DLL files that you want to link to (but that are loaded 
as some sort of plugin, among other there are keyboard layout drivers...), 
and lots of files that have nothing exported than DllMain and something 
such. Getting rid of these thins down lib64 by hundred of files already.


There's 123 files that have the exact same list of symbols in lib64 and 
libarm32. Other than that, most have a few differences.


This is most probably since lib64 have been dumped from an older version 
of windows than libarm32. So for these, we should probably make some 
decision to just go with the newer version (even though it's dumped from 
an arm version), or redump def files from a current version of windows to 
serve as base for both.


When looking at wine's spec files, only the following DLLs have -arch 
annotations about functions only existing in specific architectures:

- api-ms-win-*
- msvcrt*, msvcp*, ucrtbase (and concrt140, vcruntime140)
- kernel32, kernelbase, krnl386
- ntdll, ntoskrnl
- rpcrt4
- user32
- vssapi

So for any DLL outside of these, architecture specific differences are 
most probably nonsignificant and we could probably go with either version.


Anyway, I'll post my initial patchset for cleaning up at least some amount 
of it.


// Martin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 03/18] crt: Add an initial libarm64 directory with def files

[Martin Storsjö]

On Wed, 9 Aug 2017, Martell Malone wrote:


Martin added a patch to add support for stripping the @4, @8, @12 for
llvm-dlltool which led us to discover this issue.
http://cygwin.com/ml/binutils/2004-09/msg00031.html
https://msdn.microsoft.com/en-us/library/deaxefa7.aspx

With that in mind we should probably also add x86 to the unified def
proposal but at the same time keep the old i386 def files for binutils
dlltool.
We can use a flag to just change between them both at compile time.

The def files for x86 should be identical to x64, arm, arm64 etc bar
functions it does not have because we should not need any macro trickery we
discussed previously as InitializeCriticalSection will convert directly to
_InitializeCriticalSection when the short library is created, given the
fact we do not need the @4 this is directly equivalent to
_InitializeCriticalSection@4 in the old format.


No, you're drawing the completely wrong conclusions here, as I also said 
in the review discussion for llvm-dlltool.


We can't live without the stdcall suffixes in def files for i386, they're 
essential for actually being able to link to the import library (and 
dlltool can't make up the suffix out of thin air). It's only that when you 
link to it, the reference to the DLL should refer to a undecorated name 
(handled via -k for GNU dlltool afaik, handled via setting the "name type" 
to undecorate in lld/llvm-dlltool/link.exe).


// Martin

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 03/18] crt: Add an initial libarm64 directory with def files

[Martell Malone]

Hey All,


> If I remember correctly, I will have to reconfirm though we should not
> need the @ for short import libraries

After some testing I can confirm I was correct about not needing the @
decorator for short import libraries.
Nor do we need to prepend `_`, msvc lib.exe does that automatically and we
can easily enable the same `_` behaviour on llvm-dlltool with the flag I
linked in a previous email. https://github.com/llvm-mirror/llvm/blob/master/
include/llvm/Object/COFFModuleDefinition.h#L48

Martin added a patch to add support for stripping the @4, @8, @12 for
llvm-dlltool which led us to discover this issue.
http://cygwin.com/ml/binutils/2004-09/msg00031.html
https://msdn.microsoft.com/en-us/library/deaxefa7.aspx

With that in mind we should probably also add x86 to the unified def
proposal but at the same time keep the old i386 def files for binutils
dlltool.
We can use a flag to just change between them both at compile time.

The def files for x86 should be identical to x64, arm, arm64 etc bar
functions it does not have because we should not need any macro trickery we
discussed previously as InitializeCriticalSection will convert directly to
_InitializeCriticalSection when the short library is created, given the
fact we do not need the @4 this is directly equivalent to
_InitializeCriticalSection@4 in the old format.

Best,
Martell


On Wed, Aug 9, 2017 at 2:37 PM, Martell Malone 
wrote:

> Nevertheless llvm-dlltool should learn at least the '==' aliasing.  We
>> rely on it in our runtime, so I think it would be pretty helpful.
>
> Sorry I should clarify in case I caused confusion.
> llvm-dll tool supports `==` aliasing, it just does it using PE/COFF Aux
> spec 3 weak externals.
> binutils dlltool does it's own custom thing outside of the spec which lld
> and link.exe don't like.
> the binutils linker as a result only supports what binutils dlltool does
> for `==` and not the within spec way.
>
> Best,
> Martell
>
> On Wed, Aug 9, 2017 at 2:32 PM, Kai Tietz via Mingw-w64-public <
> mingw-w64-public@lists.sourceforge.net> wrote:
>
>> 2017-08-09 15:11 GMT+02:00 Martell Malone :
>> >>
>> >> Just out of curiosity - the 800 def files that only are available for
>> >> x86_64 but not for i686, are they something that somebody practically
>> care
>> >> about? Should we try to add them to i686 as well (given that they
>> probably
>> >> actually exist there as well)? Do they serve any real purpose?
>> >
>> >
>> > I don't want to put this on you for this patch but while we are on this
>> > discussion, I want to bring the issue up.
>> > The same thing should apply to x64 and x86 also.
>> > binutils dlltool and mingw-w64 does some weird wrapping of the `_` for
>> x86
>> > to make it appear more like x64 symbols that is not done by msvc lib.exe
>> > and the msvc headers.
>> > We would ideally update dlltool and mingw-w64 to not do this anymore.
>> >
>> > In llvm I left room to easily enable and disable this for llvm-dlltool
>> > https://github.com/llvm-mirror/llvm/blob/master/include/
>> llvm/Object/COFFModuleDefinition.h#L48
>> >
>> > I talked to Rui a little bit before about adding a flag for
>> llvm-dlltool to
>> > disable this
>> > The same flag should be added to dlltool so that we can share def files
>> > between all 4 targets.
>> >
>> > For the rest, I guess it needs more or less manual labour to sort out
>> the
>> >> differences into some sort of template like what I described. The i686
>> ones
>> >> with stdcall probably aren't mergeable at all, unless we do even more
>> >> elaborate macro trickery like FUNC_STDCALL(InitializeCriticalSection,
>> @4).
>> >
>> > If I remember correctly, I will have to reconfirm though we should not
>> need
>> > the @ for short import libraries but binutils dlltool doesn't use short
>> > import libs. :(
>> > ld supports them however.. even though it does not support the PE/COFF
>> Aux
>> > spec 3 for weak externals i.e. the `==` functions in llvm-dlltool
>> > So there are 3 issues here at least for sharing i686 with the rest.
>>
>> Right, and we have to consider backward compatibility about mangled stuff
>> ...
>>
>> > With that in mind it might be a good idea just to share the other 3 for
>> now
>> > leaving i686 as is?
>>
>> Yes, I think we should keep x86 separate.  It is pretty painful to
>> support all this nasty x86 symbol decoration stuff in a compatible way
>> for the other 3 architectures.
>>
>> Nevertheless llvm-dlltool should learn at least the '==' aliasing.  We
>> rely on it in our runtime, so I think it would be pretty helpful.
>>
>> Regards,
>> Kai
>>
>> >
>> >
>> >
>> > On Wed, Aug 9, 2017 at 1:50 PM, Martin Storsjö 
>> wrote:
>> >
>> >> On Wed, 9 Aug 2017, Jacek Caban wrote:
>> >>
>> >> On 08.08.2017 22:32, Martin Storsjö wrote:
>> >>>
>>  The libarm64 directory is a copy of libarm32 with minimal
>> modifications
>>  (renamings in the *.mri scripts and in Makefile.am).
>> 

Re: [Mingw-w64-public] [PATCH 03/18] crt: Add an initial libarm64 directory with def files

[Martell Malone]

>
> Nevertheless llvm-dlltool should learn at least the '==' aliasing.  We
> rely on it in our runtime, so I think it would be pretty helpful.

Sorry I should clarify in case I caused confusion.
llvm-dll tool supports `==` aliasing, it just does it using PE/COFF Aux
spec 3 weak externals.
binutils dlltool does it's own custom thing outside of the spec which lld
and link.exe don't like.
the binutils linker as a result only supports what binutils dlltool does
for `==` and not the within spec way.

Best,
Martell

On Wed, Aug 9, 2017 at 2:32 PM, Kai Tietz via Mingw-w64-public <
mingw-w64-public@lists.sourceforge.net> wrote:

> 2017-08-09 15:11 GMT+02:00 Martell Malone :
> >>
> >> Just out of curiosity - the 800 def files that only are available for
> >> x86_64 but not for i686, are they something that somebody practically
> care
> >> about? Should we try to add them to i686 as well (given that they
> probably
> >> actually exist there as well)? Do they serve any real purpose?
> >
> >
> > I don't want to put this on you for this patch but while we are on this
> > discussion, I want to bring the issue up.
> > The same thing should apply to x64 and x86 also.
> > binutils dlltool and mingw-w64 does some weird wrapping of the `_` for
> x86
> > to make it appear more like x64 symbols that is not done by msvc lib.exe
> > and the msvc headers.
> > We would ideally update dlltool and mingw-w64 to not do this anymore.
> >
> > In llvm I left room to easily enable and disable this for llvm-dlltool
> > https://github.com/llvm-mirror/llvm/blob/master/include/llvm/Object/
> COFFModuleDefinition.h#L48
> >
> > I talked to Rui a little bit before about adding a flag for llvm-dlltool
> to
> > disable this
> > The same flag should be added to dlltool so that we can share def files
> > between all 4 targets.
> >
> > For the rest, I guess it needs more or less manual labour to sort out the
> >> differences into some sort of template like what I described. The i686
> ones
> >> with stdcall probably aren't mergeable at all, unless we do even more
> >> elaborate macro trickery like FUNC_STDCALL(InitializeCriticalSection,
> @4).
> >
> > If I remember correctly, I will have to reconfirm though we should not
> need
> > the @ for short import libraries but binutils dlltool doesn't use short
> > import libs. :(
> > ld supports them however.. even though it does not support the PE/COFF
> Aux
> > spec 3 for weak externals i.e. the `==` functions in llvm-dlltool
> > So there are 3 issues here at least for sharing i686 with the rest.
>
> Right, and we have to consider backward compatibility about mangled stuff
> ...
>
> > With that in mind it might be a good idea just to share the other 3 for
> now
> > leaving i686 as is?
>
> Yes, I think we should keep x86 separate.  It is pretty painful to
> support all this nasty x86 symbol decoration stuff in a compatible way
> for the other 3 architectures.
>
> Nevertheless llvm-dlltool should learn at least the '==' aliasing.  We
> rely on it in our runtime, so I think it would be pretty helpful.
>
> Regards,
> Kai
>
> >
> >
> >
> > On Wed, Aug 9, 2017 at 1:50 PM, Martin Storsjö  wrote:
> >
> >> On Wed, 9 Aug 2017, Jacek Caban wrote:
> >>
> >> On 08.08.2017 22:32, Martin Storsjö wrote:
> >>>
>  The libarm64 directory is a copy of libarm32 with minimal
> modifications
>  (renamings in the *.mri scripts and in Makefile.am).
> 
> >>>
> >>>
> >>> In that case I don't think we should have actual copies of every single
> >>> .def file. It should be possible to use the same files for both
> >>> platforms by simply modifying Makefile.am. Maybe we should have libarm/
> >>> for common files and then libarm32/ and libarm64/ for things that
> >>> differ? I'm not sure about the exact solution, but I think we should
> >>> share those one way or another.
> >>>
> >>
> >> That'd probably be a good idea - the size of the total amount of def
> files
> >> is staggering. There's >1100 def files in libarm32 weighing in over 7
> MB.
> >> This patch, generated with git format-patch -C, is even 400 KB, just to
> >> describe the copied files... lib64 also has got about as many files,
> while
> >> lib32 only has got a bit over 300 files.
> >>
> >> Just out of curiosity - the 800 def files that only are available for
> >> x86_64 but not for i686, are they something that somebody practically
> care
> >> about? Should we try to add them to i686 as well (given that they
> probably
> >> actually exist there as well)? Do they serve any real purpose?
> >>
> >>
> >> That said, most DLLs probably are mostly identical, but some might have
> >> minor differences. Ideally these should be dumped from real DLL files,
> just
> >> like on previous platforms, but since platform isn't really available
> yet,
> >> it's not really doable, so I started out with the one that is most
> probable
> >> to be similar, and then meant to add other changes on top once we know
> more
> >> details.
> >>
> 

Re: [Mingw-w64-public] [PATCH 03/18] crt: Add an initial libarm64 directory with def files

[Kai Tietz via Mingw-w64-public]

2017-08-09 15:11 GMT+02:00 Martell Malone :
>>
>> Just out of curiosity - the 800 def files that only are available for
>> x86_64 but not for i686, are they something that somebody practically care
>> about? Should we try to add them to i686 as well (given that they probably
>> actually exist there as well)? Do they serve any real purpose?
>
>
> I don't want to put this on you for this patch but while we are on this
> discussion, I want to bring the issue up.
> The same thing should apply to x64 and x86 also.
> binutils dlltool and mingw-w64 does some weird wrapping of the `_` for x86
> to make it appear more like x64 symbols that is not done by msvc lib.exe
> and the msvc headers.
> We would ideally update dlltool and mingw-w64 to not do this anymore.
>
> In llvm I left room to easily enable and disable this for llvm-dlltool
> https://github.com/llvm-mirror/llvm/blob/master/include/llvm/Object/COFFModuleDefinition.h#L48
>
> I talked to Rui a little bit before about adding a flag for llvm-dlltool to
> disable this
> The same flag should be added to dlltool so that we can share def files
> between all 4 targets.
>
> For the rest, I guess it needs more or less manual labour to sort out the
>> differences into some sort of template like what I described. The i686 ones
>> with stdcall probably aren't mergeable at all, unless we do even more
>> elaborate macro trickery like FUNC_STDCALL(InitializeCriticalSection, @4).
>
> If I remember correctly, I will have to reconfirm though we should not need
> the @ for short import libraries but binutils dlltool doesn't use short
> import libs. :(
> ld supports them however.. even though it does not support the PE/COFF Aux
> spec 3 for weak externals i.e. the `==` functions in llvm-dlltool
> So there are 3 issues here at least for sharing i686 with the rest.

Right, and we have to consider backward compatibility about mangled stuff ...

> With that in mind it might be a good idea just to share the other 3 for now
> leaving i686 as is?

Yes, I think we should keep x86 separate.  It is pretty painful to
support all this nasty x86 symbol decoration stuff in a compatible way
for the other 3 architectures.

Nevertheless llvm-dlltool should learn at least the '==' aliasing.  We
rely on it in our runtime, so I think it would be pretty helpful.

Regards,
Kai

>
>
>
> On Wed, Aug 9, 2017 at 1:50 PM, Martin Storsjö  wrote:
>
>> On Wed, 9 Aug 2017, Jacek Caban wrote:
>>
>> On 08.08.2017 22:32, Martin Storsjö wrote:
>>>
 The libarm64 directory is a copy of libarm32 with minimal modifications
 (renamings in the *.mri scripts and in Makefile.am).

>>>
>>>
>>> In that case I don't think we should have actual copies of every single
>>> .def file. It should be possible to use the same files for both
>>> platforms by simply modifying Makefile.am. Maybe we should have libarm/
>>> for common files and then libarm32/ and libarm64/ for things that
>>> differ? I'm not sure about the exact solution, but I think we should
>>> share those one way or another.
>>>
>>
>> That'd probably be a good idea - the size of the total amount of def files
>> is staggering. There's >1100 def files in libarm32 weighing in over 7 MB.
>> This patch, generated with git format-patch -C, is even 400 KB, just to
>> describe the copied files... lib64 also has got about as many files, while
>> lib32 only has got a bit over 300 files.
>>
>> Just out of curiosity - the 800 def files that only are available for
>> x86_64 but not for i686, are they something that somebody practically care
>> about? Should we try to add them to i686 as well (given that they probably
>> actually exist there as well)? Do they serve any real purpose?
>>
>>
>> That said, most DLLs probably are mostly identical, but some might have
>> minor differences. Ideally these should be dumped from real DLL files, just
>> like on previous platforms, but since platform isn't really available yet,
>> it's not really doable, so I started out with the one that is most probable
>> to be similar, and then meant to add other changes on top once we know more
>> details.
>>
>> Ideally we'd do something like wine, with minor arch annotations in the
>> spec files for the few functions that differ. Perhaps something with CPP
>> macros, like we already have for def-include/msvcrt-common.def.in - with
>> macros like FUNC_ARM_ARM64(fabsf) or something such.
>>
>> I guess the first step would be to try to compare what we have and unify
>> those that are easily mergeable (that already are identical). Hopefully
>> that'd be the vast majority of them.
>>
>> For the rest, I guess it needs more or less manual labour to sort out the
>> differences into some sort of template like what I described. The i686 ones
>> with stdcall probably aren't mergeable at all, unless we do even more
>> elaborate macro trickery like FUNC_STDCALL(InitializeCriticalSection, @4).
>>
>> // Martin

Re: [Mingw-w64-public] [PATCH 03/18] crt: Add an initial libarm64 directory with def files

[Martell Malone]

>
> Just out of curiosity - the 800 def files that only are available for
> x86_64 but not for i686, are they something that somebody practically care
> about? Should we try to add them to i686 as well (given that they probably
> actually exist there as well)? Do they serve any real purpose?


I don't want to put this on you for this patch but while we are on this
discussion, I want to bring the issue up.
The same thing should apply to x64 and x86 also.
binutils dlltool and mingw-w64 does some weird wrapping of the `_` for x86
to make it appear more like x64 symbols that is not done by msvc lib.exe
and the msvc headers.
We would ideally update dlltool and mingw-w64 to not do this anymore.

In llvm I left room to easily enable and disable this for llvm-dlltool
https://github.com/llvm-mirror/llvm/blob/master/include/llvm/Object/COFFModuleDefinition.h#L48

I talked to Rui a little bit before about adding a flag for llvm-dlltool to
disable this
The same flag should be added to dlltool so that we can share def files
between all 4 targets.

For the rest, I guess it needs more or less manual labour to sort out the
> differences into some sort of template like what I described. The i686 ones
> with stdcall probably aren't mergeable at all, unless we do even more
> elaborate macro trickery like FUNC_STDCALL(InitializeCriticalSection, @4).

If I remember correctly, I will have to reconfirm though we should not need
the @ for short import libraries but binutils dlltool doesn't use short
import libs. :(
ld supports them however.. even though it does not support the PE/COFF Aux
spec 3 for weak externals i.e. the `==` functions in llvm-dlltool
So there are 3 issues here at least for sharing i686 with the rest.

With that in mind it might be a good idea just to share the other 3 for now
leaving i686 as is?




On Wed, Aug 9, 2017 at 1:50 PM, Martin Storsjö  wrote:

> On Wed, 9 Aug 2017, Jacek Caban wrote:
>
> On 08.08.2017 22:32, Martin Storsjö wrote:
>>
>>> The libarm64 directory is a copy of libarm32 with minimal modifications
>>> (renamings in the *.mri scripts and in Makefile.am).
>>>
>>
>>
>> In that case I don't think we should have actual copies of every single
>> .def file. It should be possible to use the same files for both
>> platforms by simply modifying Makefile.am. Maybe we should have libarm/
>> for common files and then libarm32/ and libarm64/ for things that
>> differ? I'm not sure about the exact solution, but I think we should
>> share those one way or another.
>>
>
> That'd probably be a good idea - the size of the total amount of def files
> is staggering. There's >1100 def files in libarm32 weighing in over 7 MB.
> This patch, generated with git format-patch -C, is even 400 KB, just to
> describe the copied files... lib64 also has got about as many files, while
> lib32 only has got a bit over 300 files.
>
> Just out of curiosity - the 800 def files that only are available for
> x86_64 but not for i686, are they something that somebody practically care
> about? Should we try to add them to i686 as well (given that they probably
> actually exist there as well)? Do they serve any real purpose?
>
>
> That said, most DLLs probably are mostly identical, but some might have
> minor differences. Ideally these should be dumped from real DLL files, just
> like on previous platforms, but since platform isn't really available yet,
> it's not really doable, so I started out with the one that is most probable
> to be similar, and then meant to add other changes on top once we know more
> details.
>
> Ideally we'd do something like wine, with minor arch annotations in the
> spec files for the few functions that differ. Perhaps something with CPP
> macros, like we already have for def-include/msvcrt-common.def.in - with
> macros like FUNC_ARM_ARM64(fabsf) or something such.
>
> I guess the first step would be to try to compare what we have and unify
> those that are easily mergeable (that already are identical). Hopefully
> that'd be the vast majority of them.
>
> For the rest, I guess it needs more or less manual labour to sort out the
> differences into some sort of template like what I described. The i686 ones
> with stdcall probably aren't mergeable at all, unless we do even more
> elaborate macro trickery like FUNC_STDCALL(InitializeCriticalSection, @4).
>
> // Martin
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [Mingw-w64-public] [PATCH 03/18] crt: Add an initial libarm64 directory with def files

[Martin Storsjö]

On Wed, 9 Aug 2017, Jacek Caban wrote:


On 08.08.2017 22:32, Martin Storsjö wrote:

The libarm64 directory is a copy of libarm32 with minimal modifications
(renamings in the *.mri scripts and in Makefile.am).



In that case I don't think we should have actual copies of every single
.def file. It should be possible to use the same files for both
platforms by simply modifying Makefile.am. Maybe we should have libarm/
for common files and then libarm32/ and libarm64/ for things that
differ? I'm not sure about the exact solution, but I think we should
share those one way or another.


That'd probably be a good idea - the size of the total amount of def files 
is staggering. There's >1100 def files in libarm32 weighing in over 7 MB. 
This patch, generated with git format-patch -C, is even 400 KB, just to 
describe the copied files... lib64 also has got about as many files, while 
lib32 only has got a bit over 300 files.


Just out of curiosity - the 800 def files that only are available for 
x86_64 but not for i686, are they something that somebody practically care 
about? Should we try to add them to i686 as well (given that they probably 
actually exist there as well)? Do they serve any real purpose?



That said, most DLLs probably are mostly identical, but some might have 
minor differences. Ideally these should be dumped from real DLL files, 
just like on previous platforms, but since platform isn't really available 
yet, it's not really doable, so I started out with the one that is most 
probable to be similar, and then meant to add other changes on top once we 
know more details.


Ideally we'd do something like wine, with minor arch annotations in the 
spec files for the few functions that differ. Perhaps something with CPP 
macros, like we already have for def-include/msvcrt-common.def.in - with 
macros like FUNC_ARM_ARM64(fabsf) or something such.


I guess the first step would be to try to compare what we have and unify 
those that are easily mergeable (that already are identical). Hopefully 
that'd be the vast majority of them.


For the rest, I guess it needs more or less manual labour to sort out the 
differences into some sort of template like what I described. The i686 
ones with stdcall probably aren't mergeable at all, unless we do even more 
elaborate macro trickery like FUNC_STDCALL(InitializeCriticalSection, @4).


// Martin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 03/18] crt: Add an initial libarm64 directory with def files

[Jacek Caban]

On 09.08.2017 14:41, Kai Tietz via Mingw-w64-public wrote:
> 2017-08-09 14:34 GMT+02:00 Jacek Caban :
>> On 08.08.2017 22:32, Martin Storsjö wrote:
>>> The libarm64 directory is a copy of libarm32 with minimal modifications
>>> (renamings in the *.mri scripts and in Makefile.am).
>>
>> In that case I don't think we should have actual copies of every single
>> .def file. It should be possible to use the same files for both
>> platforms by simply modifying Makefile.am. Maybe we should have libarm/
>> for common files and then libarm32/ and libarm64/ for things that
>> differ? I'm not sure about the exact solution, but I think we should
>> share those one way or another.
> Agreed.  We should try to share those parts.  And just keep those
> files separate, which are different.  We could also think about
> running some sed/preprocess/... on it, and have them within on file.
> I am open for any solution here.

We already have infrastructure for preprocessing with .def.in files like
we do for msvcrt already. We could just use it here (but I'm open to any
solution for differing files as well as long as identical files are not
duplicated).

Jacek

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 03/18] crt: Add an initial libarm64 directory with def files

[Kai Tietz via Mingw-w64-public]

2017-08-09 14:34 GMT+02:00 Jacek Caban :
> On 08.08.2017 22:32, Martin Storsjö wrote:
>> The libarm64 directory is a copy of libarm32 with minimal modifications
>> (renamings in the *.mri scripts and in Makefile.am).
>
>
> In that case I don't think we should have actual copies of every single
> .def file. It should be possible to use the same files for both
> platforms by simply modifying Makefile.am. Maybe we should have libarm/
> for common files and then libarm32/ and libarm64/ for things that
> differ? I'm not sure about the exact solution, but I think we should
> share those one way or another.

Agreed.  We should try to share those parts.  And just keep those
files separate, which are different.  We could also think about
running some sed/preprocess/... on it, and have them within on file.
I am open for any solution here.

Cheers,
Kai

>
> Thanks,
>
> Jacek

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 03/18] crt: Add an initial libarm64 directory with def files

[Jacek Caban]

On 08.08.2017 22:32, Martin Storsjö wrote:
> The libarm64 directory is a copy of libarm32 with minimal modifications
> (renamings in the *.mri scripts and in Makefile.am).


In that case I don't think we should have actual copies of every single
.def file. It should be possible to use the same files for both
platforms by simply modifying Makefile.am. Maybe we should have libarm/
for common files and then libarm32/ and libarm64/ for things that
differ? I'm not sure about the exact solution, but I think we should
share those one way or another.


Thanks,

Jacek


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public