A few days ago I asked Pali about msvcrt.def.in in lib-common and why we do not 
use similar approach for all versioned CRTs, such as msvcr120.dll.

My point was that for each CRT we have up to four .def.in files, one in each of 
lib32, lib64, libarm32 and libarm64. Also, there are as many def.in files for 
debug version of CRT, which make up to total of eight def.in files for each 
CRT. This makes it really bothersome to modify so many files when we need to 
replace some function in some or all CRTs.

Another point was that list of symbols exported from such versioned CRTs is not 
going to change anymore, and list of exported symbols should be well-known. 
This should make it relatively easy to perform de-duplication and they will not 
require much maintenance afterwards.

So, I wanted to suggest we do de-duplication of def.in files for versioned 
CRTs, similar to what Pali had suggested here.

- Kirill Makurin
________________________________
From: Martin Storsjö <[email protected]>
Sent: Monday, December 29, 2025 6:50 AM
To: Pali Rohár <[email protected]>
Cc: LIU Hao <[email protected]>; Jacek Caban <[email protected]>; Biswapriyo 
Nath <[email protected]>; Kirill Makurin <[email protected]>; 
[email protected] <[email protected]>
Subject: Re: [Mingw-w64-public] Deduplicate lib32 and lib-common def files

On Sun, 28 Dec 2025, Pali Rohár wrote:

> Hello, I would like to bring this topic back. I think that nobody was
> explicitly against this proposal.

The last time this was discussed, I thought it became quite clear that all
active maintainers are mildly against it. Not to the point that anybody
has said a hard no, but it seems like everybody says that they would
prefer not to do it.

If you want to twist those words into "nobody was explicitly against it",
I guess that's one way of reading it - but it's not the way I would
summarize it.

// Martin

_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to