On Friday 01 August 2025 20:56:51 Pali Rohár wrote: > On Thursday 31 July 2025 15:55:25 Martin Storsjö wrote: > > On Sun, 20 Jul 2025, Pali Rohár wrote: > > > > > On Saturday 28 June 2025 16:20:46 LIU Hao wrote: > > > > 在 2025-6-28 05:12, Pali Rohár 写道: > > > > > > > > > > So is the idea of deduplicating lib32 and lib-common def files > > > > > abandoned? Or is there still any interest to do it? > > > > > > > > I'm rather neutral about this change; as explained earlier I'd prefer > > > > keeping them separate. However I don't mind such a change either. > > > > > > Ok, I will let it for Martin, once is back. > > > > I also don't have a very strong opinion here. Having the lib32 versions > > separate is clearer in one way - but duplication is bad of course. It's > > mostly a question whether this really makes maintainance easier, or more > > work (needing to source all def file changes through a 32 bit version, even > > if only working/looking a 64 bit version). Due to the latter, I mildly think > > it may end up causing extra effort in the end. > > Currently the "lib-common" file is used also for 32-bit arm. So it is not > 64-bit only definition how people could think. > > I understand that libraries with very different set of symbols could or > should be split into lib32, lib64, etc... > > But if we have a library which has exactly same list of exports in all > versions, I still think that for these libraries it makes sense to > deduplicate them into one "lib-common" file. > > And my proposal in the first email was to locate these libraries with > same set of symbols and deduplicate them to one def file. > > The point is to not deduplicate everything where 32-bit and 64-bit lib > have different set of symbols. > > > What do Biswapriyo think about it, who has spent a lot of work on updates > > for these files? > > > > // Martin
Hello, I would like to bring this topic back. I think that nobody was explicitly against this proposal. In my opinion it is a big benefit to have one def files for all architectures. So when adding a newly introduced symbol/function, it needs to be done only at one place. And needed to figure out where else it needs to be done. I understood that there is a point/question if working with 64-bit-only library could makes maintenance harder as it would need to think about the 32-bit stdcall decoration. I think that this is not a problem because there are two easy options which should be already followed in this situation. 1 - if library is 64-bit only, it should not be in lib-common, but in lib64 where no 32-bit decorations are required 2 - if adding a new symbol to lib-common which is 64-bit only, it should be wrapped by appropriate macro, like F64(...) or F_X64(...). I can prepare new deduplicate change just for files which have exactly same list of functions, so something which does not differ between architectures. I can generate it by machine script, so it should prevent any human error. I can limit change just to some libraries, maybe those which was not modified too much in history, so should not affect maintenance in near future, just to see how it behaves. _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
