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 t
On Saturday 31 May 2025 21:09:27 LIU Hao wrote:
> 在 2025-5-31 20:26, Pali Rohár 写道:
> > Some of them are documented as PRIVATE in MS linker documentation:
> > https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-warning-lnk4104
> > https://learn.microsoft.com/en-us/cpp/erro
在 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.
--
Be
On Friday 30 May 2025 18:43:30 Pali Rohár wrote:
> On Monday 26 May 2025 11:49:04 Martin Storsjö wrote:
> > On Mon, 26 May 2025, LIU Hao wrote:
> >
> > > > Yeah, I agree. That was also the original reason for why we started
> > > > merging them originally; we had lib32, lib64 and libarm32, and
> >
在 2025-5-31 20:26, Pali Rohár 写道:
Some of them are documented as PRIVATE in MS linker documentation:
https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-warning-lnk4104
https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-warning-lnk4222
If both
On Saturday 31 May 2025 20:01:11 LIU Hao wrote:
> 在 2025-5-31 00:43, Pali Rohár 写道:
> > Also these cleanups are important:
> > e0a38b59e92dc7fd568c983a20d71ecf71688aa9
> > 5a28a0560c350f9563e072eb55929b417c86bb53
> >
> > We can teach gendef to "comment" DllRegisterServer, DllUnregisterServer,
> >
在 2025-5-31 00:43, Pali Rohár 写道:
Also these cleanups are important:
e0a38b59e92dc7fd568c983a20d71ecf71688aa9
5a28a0560c350f9563e072eb55929b417c86bb53
We can teach gendef to "comment" DllRegisterServer, DllUnregisterServer,
DllCanUnloadNow, DllGetClassObject, DllEntryPoint and DllMain symbols.
On Sunday 25 May 2025 11:47:10 Pali Rohár wrote:
> On Sunday 25 May 2025 12:41:08 Martin Storsjö wrote:
> > On Sun, 18 May 2025, Pali Rohár wrote:
> >
> > > Hello, what do you think about doing one-time automatic deduplication of
> > > lib32 and lib-common def files?
> > >
> > > Since commit cf21
On Monday 26 May 2025 11:49:04 Martin Storsjö wrote:
> On Mon, 26 May 2025, LIU Hao wrote:
>
> > > Yeah, I agree. That was also the original reason for why we started
> > > merging them originally; we had lib32, lib64 and libarm32, and
> > > wanted to add libarm64. (Also, at the time I didn't have
On 26.05.2025 06:54, LIU Hao wrote:
在 2025-5-26 02:58, Martin Storsjö 写道:
On Sun, 25 May 2025, Jacek Caban wrote:
I think that kind of massive duplication just doesn't scale. For
example, when adding a new target like ARM64EC, are you suggesting
we duplicate all the .def files for a fifth tim
On Mon, 26 May 2025, LIU Hao wrote:
Yeah, I agree. That was also the original reason for why we started merging
them originally; we had lib32, lib64 and libarm32, and wanted to add
libarm64. (Also, at the time I didn't have the real OS yet to even dump the
DLLs, so it would have been a copy of
在 2025-5-26 02:58, Martin Storsjö 写道:
On Sun, 25 May 2025, Jacek Caban wrote:
I think that kind of massive duplication just doesn't scale. For example, when adding a new target like
ARM64EC, are you suggesting we duplicate all the .def files for a fifth time, rather than just
adjusting a few a
On Sun, 25 May 2025, Jacek Caban wrote:
On 24.05.2025 12:25, LIU Hao wrote:
在 2025-5-24 18:12, Pali Rohár 写道:
And it deduplicated 496 def files. What do you think about it? Just a
robotic change and can decrease number of def files which needs to be
maintained.
I don't have a specific opinio
On 24.05.2025 12:25, LIU Hao wrote:
在 2025-5-24 18:12, Pali Rohár 写道:
And it deduplicated 496 def files. What do you think about it? Just a
robotic change and can decrease number of def files which needs to be
maintained.
I don't have a specific opinion on this change.
Frankly speaking, I am
On Sunday 25 May 2025 12:41:08 Martin Storsjö wrote:
> On Sun, 18 May 2025, Pali Rohár wrote:
>
> > Hello, what do you think about doing one-time automatic deduplication of
> > lib32 and lib-common def files?
> >
> > Since commit cf211ae90565ff02e78c93d93a913501d100f30f ("crt: Remove
> > @ stdcal
On Sun, 18 May 2025, Pali Rohár wrote:
Hello, what do you think about doing one-time automatic deduplication of
lib32 and lib-common def files?
Since commit cf211ae90565ff02e78c93d93a913501d100f30f ("crt: Remove
@ stdcall mangling when processing lib-common/*.def.in files for
non-I386 builds")
On Saturday 24 May 2025 19:32:31 LIU Hao wrote:
> 在 2025-5-24 18:29, Pali Rohár 写道:
> > On Saturday 24 May 2025 18:25:35 LIU Hao wrote:
> > > 在 2025-5-24 18:12, Pali Rohár 写道:
> > > > > And it deduplicated 496 def files. What do you think about it? Just a
> > > > > robotic change and can decrease n
在 2025-5-24 18:29, Pali Rohár 写道:
On Saturday 24 May 2025 18:25:35 LIU Hao wrote:
在 2025-5-24 18:12, Pali Rohár 写道:
And it deduplicated 496 def files. What do you think about it? Just a
robotic change and can decrease number of def files which needs to be
maintained.
I don't have a specific o
On Saturday 24 May 2025 18:25:35 LIU Hao wrote:
> 在 2025-5-24 18:12, Pali Rohár 写道:
> > > And it deduplicated 496 def files. What do you think about it? Just a
> > > robotic change and can decrease number of def files which needs to be
> > > maintained.
>
> I don't have a specific opinion on this
Any opinion?
On Sunday 18 May 2025 14:21:40 Pali Rohár wrote:
> Hello, what do you think about doing one-time automatic deduplication of
> lib32 and lib-common def files?
>
> Since commit cf211ae90565ff02e78c93d93a913501d100f30f ("crt: Remove
> @ stdcall mangling when processing lib-common/*.def.
在 2025-5-24 18:12, Pali Rohár 写道:
And it deduplicated 496 def files. What do you think about it? Just a
robotic change and can decrease number of def files which needs to be
maintained.
I don't have a specific opinion on this change.
Frankly speaking, I am not too happy about the characteristi
21 matches
Mail list logo
