On 2026/09/03 03:33, Pali Rohár wrote: > On Thursday 03 September 2026 03:18:58 Zhongteng Gui wrote: >> On 2026/09/03 02:26, Pali Rohár wrote: >>> liblargeint.a is also for MSVC compatibility. Older versions provided >>> static largeint.lib library which applications could statically link. >> >> Do we really need to provide this type of "compatiblity"? > > Probably not. I'm writing it just for the context. > >> Searching GitHub for "-llargeint" [1] matches only 10 code snippet, which I >> think is rare enough for us to no longer provide it. Searching for >> "liblargeint.a" [2] matches 0 real usage. For other potential usage of it >> (e.g. >> largeint.lib), they always have to be patched before use, and there's little >> difference between patching 'largeint.lib' to '-llargeint' or simply >> removing it. > > Zero usage of "liblargeint.a" is not a surprise. gcc/ld needs "-llargeint" > syntax. > >> The similar logic also applies to libdelayimp.a, though this is a little more >> complicated (or confusing), because people may expect this is required if >> they >> want to use "delay import", which is a relatively new feature compared to >> largeint. > > Apparently not. Both largeint.lib and delayimp.lib were introduced in > same version: Visual C++ 6.0. And so it is not a "new feature" but rather > very old feature.
Thanks for pointing out this. I'm not very familiar with the history of these libraries. > >> And indeed there're more usage of `-ldelayimp` on GitHub (~200), >> though many of them seemes to be intended for MSVC (either explicitly >> specifies >> "NOT VCPKG_TARGET_IS_MINGW", or used with "/DELAYLOAD:", or searching from >> Windows Kits explicitly.) >> >> [1]: https://github.com/search?q=-llargeint&type=code >> [2]: https://github.com/search?q=liblargeint.a&type=code > > I'm not opposing the change, I just wanted to write information about it > for completeness. It could be useful to have and to know such thing why > such lib existed there. > > The more important is that the-now-removed mingw-w64 liblargeint.a > is/was broken. This library did not provide required functions symbols > for largeint support and also no other mingw-w64 provides them. Reason > was that all function symbols were commented and also the header file > was missing. > > So from my point of view: It makes sense to remove broken largeint > support if nobody is going to fix it (which is obvious as there is > mostly no user of it). > > The delayimp is different. mingw-w64 provides delayimp symbols, just > they are in other library which is automatically linked to every binary. > So mingw-w64 has delayimp support and I mostly do not see a reason for > removing it (as there is probably zero maintenance for its "empty" > library). Maybe we can declare these compatiable empty libraries as "deprecated", then finally remove them after a few major versions? I don't think it's a good idea to infinitely provide an empty library, even if it doesn't need much maintaince currently. For common used libraries (e.g. libmingwex.a, if it's really merged into other libraries as discussed previously and becomes empty), I agree we should provide them for a long enough time. But for seldom used libraries like libdelayimp.a, maybe it'd be better to finally remove them after 1 or 2 major versions after deprecating, as this also help downstreams to update their usage timely. _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
