Name collisions with libjuice statically linked

[fborges22]

Describe the bug
In a C++ project, when you statically link everyone with libjuice too. There are name collisions in the codebase that can lead to build issues and/or unexpected behavior depending on the compiler and environment. These collisions stem from conflicting symbol names that are not properly namespaced or isolated.

This issue has been addressed and resolved in the following pull request:
LibVNCServer PR #699 — #699

---

To Reproduce

1. Build the project in an environment with stricter compiler checks or symbol resolution with libjuice statically linked.
2. Observe warnings or errors related to duplicate or conflicting symbol names.
3. In some cases, run-time issues may occur due to incorrect symbol resolution.

---

Expected Behavior
The project should compile cleanly without symbol/name collision warnings or errors, and all symbols should be uniquely and correctly resolved.

---

Logs/Backtraces
If applicable, users may encounter compiler warnings/errors indicating duplicate definitions or ambiguous symbol references. These are resolved after applying the changes from PR #699.

hash_md5 already defined in Kernel.lib(crypto_openssl.obj)
hash_sha1 already defined in Kernel.lib(crypto_openssl.obj)

---

Your environment (please complete the following information):

• OS and version: [e.g., Windows 11.]
• Compiler and version: [e.g., Visual Studio 2026]

---

Additional context
The fix introduces proper handling of symbol naming to avoid collisions across different compilation units and environments.

If you'd like to incentivize further improvements or related fixes, you can support this issue via IssueHunt:
https://issuehunt.io/r/LibVNC/libvncserver

---

[bk138]

@fborges22 please tell us about libjuice and whether you're using libvncclient or -server :-)

[fborges22]

It is happening on both libvncclient and libvncserver 😀 and I am using both of them.