For nPTH, libgpg-error, and libassuan, patch rEca46b9a7bccb: Add hack to have different names for 64 bit Windows DLLs. was applied.
Why not for other libraries?
Description
Description
Revisions and Commits
Revisions and Commits
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T6508 Port GnuPG to 64-bit Windows | ||
| Resolved | • gniibe | T6484 dll: 64-bit different name for libgcrypt, libksba, ntbtls, and gpgme | ||
| Resolved | • gniibe | T6619 How to maintain our local libtool patch |
Event Timeline
Comment Actions
We need the 64 bit version for the GpgOL because there are 32 and 64 bit versions of outlook. Thus we also need a 64 bit gpgme and in turn a 64 bit libassuan and libgpg-error. I can't remember why we don't append the 6 to the gpgme dll, though.
I see no problems to add the 6 to all DLLs - it will eventually help out support team even if it is not technically required because we use a bin64 subdir.
Comment Actions
My use case is using Wine, like this:
- having different bindir (/usr/local/i686-w64-mingw32 and /usr/local/x86_64-w64-mingw32)
- but I was too lazy to have different configurations for 32-bit and 64-bit, but to have shared configuration with
- PATH adding both of /usr/local/i686-w64-mingw32 and /usr/local/x86_64-w64-mingw32
When a user wants running both of 32-bit applications and 64-bit applications, having different DLL name helps.
In my opinion, adding the "6" to all DLLs is good now (including gpgme), when we are going to support 64-bit version.
Comment Actions
This issue can be resolved in my opinion, as I have tested the 64 bit installer and tested a 64 bit pg4win. The current status of this is that we don't want to have different library names depending on the architecture since it is installed in the same way as linux in different directories. So there is nothing left to do here.