Add way to distinguish 32bit vs 64bit mcfgthread-12.dll

[danieledapo]

Hi, we're in the process of migrating some binaries to using mcfgthread, but unfortunately we're hitting a roadblock that we're not able to work around easily.

The binaries we're migrating are both 32bit and 64bit and need to live and coexist all in the same directory.

Here's an example tree structure of the binaries

.
├── bin1-32bit.exe
├── bin2-64bit.exe
└── bin3-32bit.exe
└── lib1-32bit.exe
└── lib1-64bit.exe

Ideally we'd like to ship the dll required by mcfgthread in that directory just like we're doing for all the other libraries, but unfortunately we cannot because the name of dll is the same that is mcfgthread-12.dll. This makes effectively impossible to have two binaries for different architectures live in the same directory.

Do you think it might be feasible to change the name of the dll to include the architecture or any other way to distinguish between 32bit vs 64bit?

I realize this would be a breaking change, but if that's a concern (definitely a valid one) we could maybe setup additional pipelines that create the artifacts with the new names while keeping the old ones around for the foreseeable future.

What do you think?

[lhmouse]

I don't think it is a good idea to mix 32-bit and 64-bit executables in the same directory, and I have heard of nobody use distinct naming schemes for 32-bit and 64-bit DLLs.

A possible workaround is to copy 32-bit and 64-bit DLLs into C:\Windows\SysWow64\ and C:\Windows\System32\ respectively. Both 32 and 64 processes refer them as System32.

[cvtsi2sd]

The problem we are facing is that we are coming from a fully static build environment, where mixing executables of whatever bitness is not a big deal; of course it's not impossible to change the directory structure, but it's inconvenient, especially given that, as we are building our own toolchain, it doesn't look like changing the dll name should be a huge change.

I'd avoid the workaround you proposed both as we'd like to make installation not invasive on the target system to the maximum extent, and because I fear that putting such dll in systemwide paths would mean having to deal with versioning, cross-version/toolchain ABI guarantee, etc—all stuff that is better left alone if not strictly necessary.

[lhmouse]

I understand your emergency. There is a solution for your problem (see below), but I will not accept this unusual feature request.

You may rename a DLL by recreating its import library, as follows:

1. Find your local mcfgthread-12.dll and rename it to mcfgthread_64-12.dll (or _32 for the 32-bit one).
2. Execute gendef mcfgthread_64-12.dll. This creates a DEF file with the name mcfgthread_64-12.def.
3. Open it with a text editor. There is a line LIBRARY "mcfgthread-12.dll" at the very beginning, which informs the Windows DLL loader of the filename. Now replace this line with LIBRARY "mcfgthread_64-12.dll".
4. Create the corresponding import library with dlltool -d mcfgthread_64-12.def -l libmcfgthread.a. Note it is not a static library.
5. Copy it for dynamic linking: cp libmcfgthread.a libmcfgthread.dll.a
6. Replace your local libmcfgthread.a and libmcfgthread.dll.a with the ones generated above.
7. Relink your programs. They should now look for mcfgthread_64-12.dll instead of mcfgthread-12.dll.

[danieledapo]

We will workaround the issue ourselves by changing the directory structure. Thanks for your time.