MSVC link errors

[gvanem]

Hi folks.

Trying yet again to build FileZilla using MSVC (x64), I get a bunch of link-errors for these symbols:

Code: Select all

__declspec(dllimport) public: void __cdecl fz::rwmutex::lock_write(void)
__declspec(dllimport) public: void __cdecl fz::rwmutex::unlock_write(void)
__declspec(dllimport) public: __cdecl fz::scoped_read_lock::scoped_read_lock(class fz::rwmutex &)
__declspec(dllimport) public: __cdecl fz::scoped_read_lock::~scoped_read_lock(void)
__declspec(dllimport) public: void __cdecl fz::scoped_read_lock::lock(void)

(edited for clarity).

AFAICS since the decoration should be static. All that code is inline; nothing to export.
Thus no class __declspec (dllexport) rwmutex final etc. But the use of BUILDING_LIBFILEZILLA is rather messy IMHO.

So this is what I patched it into to make FileZilla.exe link:

Code: Select all

--- a/libfilezilla/lib/libfilezilla/rwmutex.hpp 2021-08-02 10:02:41
+++ b/libfilezilla/lib/libfilezilla/rwmutex.hpp 2024-02-14 10:11:07
@@ -9,8 +9,10 @@

 #ifdef FZ_WINDOWS
 #include "glue/windows.hpp"
+#define _FZ_PUBLIC_SYMBOL
 #else
 #include <pthread.h>
+#define _FZ_PUBLIC_SYMBOL FZ_PUBLIC_SYMBOL
 #endif

 namespace fz {
@@ -20,7 +22,7 @@
  *
  * This mutex is neither recursive, nor can read locks be upgraded to write locks.
  */
-class FZ_PUBLIC_SYMBOL rwmutex final
+class _FZ_PUBLIC_SYMBOL rwmutex final
 {
 public:
 #ifdef FZ_WINDOWS
@@ -96,7 +98,7 @@
  * There can be multiple readers.
  * If there is a writer there's no readers and no other writer.
  */
-class FZ_PUBLIC_SYMBOL scoped_read_lock final
+class _FZ_PUBLIC_SYMBOL scoped_read_lock final
 {
 public:
        explicit scoped_read_lock(rwmutex& m)
@@ -185,7 +187,7 @@
  * The lock is acquired on construction and, if still locked, released on destruction.
  * You can manually unlock and re-lock if needed.
  */
-class FZ_PUBLIC_SYMBOL scoped_write_lock final
+class _FZ_PUBLIC_SYMBOL scoped_write_lock final
 {
 public:
        explicit scoped_write_lock(rwmutex& m)

Besides, some *.vcxproj files seems out of wack since aio.cpp etc. were moved.

[iam_sysop]

FileZilla is built using the MinGW-GCC toolchain:

The builds are normally produced via this process:

https://wiki.filezilla-project.org/Cros ... _GNU/Linux

and it is also possible to build directly on Windows via: https://wiki.filezilla-project.org/Comp ... er_Windows
(but this is a fragile process - the easiest way to produce stable builds is the first link above).

[gvanem]

> FileZilla is built using the MinGW-GCC toolchain:

So none of the *.vcxproj files are used then? So why are they there?

I must say it's a rather messy experience for me so far to build both client and server-programs on Windows:

• for MSVC, the client-code MUST use -std:c+17 and the server-code MUST use -std:c+20.
  (due to std::'back_inserter() etc.) But fails miserably on several C++20 constructs even with -permissive-.

• Same for clang-cl, but -permissive- is not needed. And both client and some server programs I've built so far works fine.

[boco]

https://wiki.filezilla-project.org/Comp ... er_Windows

From what I know, the *.vcxproj files are only remnants/relics from the past, MSVC isn't really supported anymore, officially.

[oibaf]

> FileZilla is built using the MinGW-GCC toolchain:

So none of the *.vcxproj files are used then? So why are they there?

I must say it's a rather messy experience for me so far to build both client and server-programs on Windows:

• for MSVC, the client-code MUST use -std:c+17 and the server-code MUST use -std:c+20.
  (due to std::'back_inserter() etc.) But fails miserably on several C++20 constructs even with -permissive-.

• Same for clang-cl, but -permissive- is not needed. And both client and some server programs I've built so far works fine.

The server has never been compiled with MSVC, but it's being compiled with gcc and clang successfully. It needs a c++17 (not 20) compliant compiler.