On Saturday 29 June 2024 10:44:13 Martin Storsjö wrote: > On Fri, 28 Jun 2024, Pali Rohár wrote: > > > > However, sticking to using the short import library format, but with the > > > new > > > name type for the few symbols that really need this kind of redirect, > > > feels > > > more consistent though - so I think I'll probably go that way. > > > > Yes, I agree. > > > > I was just trying to come up with the solution which can work now > > without need to modify linker. > > Right... Although, LLD already supports the new short import name type. > Ld.bfd doesn't, but while ld.bfd can link against general short import > libraries, it fails with the mingw-w64 base libraries in that form. IIRC the > issue is that it doesn't handle the redirections with weak aliases in the > form its used there. > > So using the new name type in llvm-dlltool doesn't change where our > libraries built with llvm-dlltool practically can be used (only with LLD).
Ok, I see. > > Anyway, long import object for one symbol can be constructed also via > > assembly without need to use dlltool. > > > > So for supporting LLVM builds we can omit renaming symbols from def file > > (e.g. conditionally when processing by llvm-dlltool) and then for those > > omitted symbols generate objects files via above assembly pattern. > > Objects files can be merged into the final import library (which is > > already mix of short import objects and real object functions). > > Right - although that also feels like a mess I'd prefer to avoid if > possible. I agree. I just wanted to explore possible alternatives. > And I'd like to study the LLD internal behaviour to see how it > really behaves here, because even if things seem to work in a simple case, > I'd like to verify what it does on the inside; there are a couple potential > gotchas there. That is a good idea. Everything I have just tested on very simple example. > > > Anyway, to summarize the situation, I guess we need to fix this situation > > > in > > > llvm-dlltool in one way or another. > > > > > > We already have this issue in msvcrt10.dll and msvcrt20.dll, where I > > > missed > > > to notice the issue. This patch only adds more cases of the same to > > > crtdll.dll, which also isn't used very widely. So we probably don't need > > > to > > > block these patches, waiting on a fix for llvm-dlltool. > > > > Yes, makes sense. > > > > > I'll try to (but can't promise) to have a fix for this in the LLVM 19.x > > > branch, which is branched in a little less than a month. > > > > That would be really great. It would allow me to prepare fixes for C99 > > compatibility of wcstok and swprintf via msvcrt.dll > > Nice - I appreciate if you can wait with submitting those patches that > change msvcrt.dll, until I've fixed llvm-dlltool. > > // Martin Ok. I can wait with them. Anyway, how to handle changes in this series? _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
