Windows build won't load

[hbeni]

The windows build DLL cannot be loaded.
Mumble says Non-plugin found in plugin directory: "<dir>Mumble/Plugins/fgcom-mumble.dll"

---

• No-SSL DLL could not be loaded
• SSL DLL could not be loaded
  Probably a build time problem including openssl dlls
• RadioGUI can't connect
  • the plugin immediately recognizes an incoming connection from 0.0.0.0 when loading. This may be blocking the port.

[Krzmbrzl]

@hbeni did you try natively compiling on Windows using MSVC?
I assume you #include Mumble's plugin-header? If not, you have to make sure that the functions are actually exported (this is not an issue on Linux as there functions are visible to the outside by default but on Windows, you'll have to explicitly export the functions).

If you have verified that the issue is not that the symbols are not visible, you can send me a copy of your plugin and I can try loading it in my Windows VM (where I can use some debug output to figure out what's going on) :)

---

Btw.: I think in the future it's easier if you just ping me here in the issue instead of commenting on the Mumble-PR (that thing is huge already - no need to further populate it with discussions that are not directly related to the PR itself xD) ☝️

[hbeni]

@Krzmbrzl

@hbeni did you try natively compiling on Windows using MSVC?

No, no compile availability ion windows so far...

I assume you #include Mumble's plugin-header? If not, you have to make sure that the functions are actually exported (this is not an issue on Linux as there functions are visible to the outside by default but on Windows, you'll have to explicitly export the functions).

How do i export the functions ecplicitely? The header is included, but just with the "include" statement. Nothing more.
At linux the plugin loads fine...

[Krzmbrzl]

The header is included, but just with the "include" statement.

Then that should be enough. The header actually takes care of exporting the symbols

How do i export the functions ecplicitely?

This is done via the dllexport stuff in the code ☝️

[hbeni]

Do i need exports for my own functions as well?

[Krzmbrzl]

No only the plugin functions need to be exported because these are the only ones that Mumble is looking for.

Ah wait I actually have an idea, what could be the issue: When was the last time that you updated the plugin header files? I recently fixed something in a few API functions that changed their signature. Thus the API struct is a different now meaning that mumble_registerAPIFunctions also has a different signature. Maybe this is causing the loading to fail 🤔

Speaking of that though I notice that I forgot to mention this change to the API in the PR... 👀

[hbeni]

Ah wait I actually have an idea, what could be the issue: When was the last time that you updated the plugin header files?

I compiled my plugin against the latest state of the branch, and i did notice the change. I hope i integrated it correctly: 24b9c39
For my tests i used todays snapshot from the azure artifact from build 3210 (https://dev.azure.com/Mumble-VoIP/Mumble/_build/results?buildId=3210&view=artifacts&pathAsName=false&type=publishedArtifacts).

As a test, i switched the mingw command from -static to -shared but that makes no difference unfortunately.
I assume i do something wrong when building the dll. But what, i have no clue.

Thank you very much, Robert, for your ongoing help. I'm a bit lost here :(

[hbeni]

I also tried to not bake openssl into the plugin (it's needed fopr the update checker).
Same result.

[Krzmbrzl]

Hm yeah seems correct. The plugin works on Linux, right?

Just send me your dll and I'll try to see if I can find out what's going on 🤔

[hbeni]

Thank you very much!
Here is a fresh dll compile from the current master branch @ 24b9c39:

fgcom-mumble.dll.zip

[hbeni]

Ah and yes, at linux all is fine!

you can find the makefile here: https://github.com/hbeni/fgcom-mumble/blob/master/client/mumble-plugin/makefile

build it with make plugin-win64
(Further details here: https://github.com/hbeni/fgcom-mumble#compiling-the-plugin)

[Krzmbrzl]

Okay so it seems that the library is not readable or the symbols are indeed not exported. I don't get any output regarding it in the debug console...

Unless proven otherwise I'd assume that the issue is to be searched in the cross-compilation. Thus I'd stronlgy suggest natively compiling it on Windows (using MSVC) 🤔

[hbeni]

Unless proven otherwise I'd assume that the issue is to be searched in the cross-compilation. Thus I'd stronlgy suggest natively compiling it on Windows (using MSVC)

Thank you very much for looking at it!
I too suspect something wrong with the cross compile, because the Linux version runs fine.

Maybe someone capable could try the compile. Meanwhile i try to read into using msvc and how to get it compiled.

[Krzmbrzl]

@hbeni why aren't you using cmake? I think that'd greatly facilitate compilation on other platforms.

And if you are using cmake, you could also consider refactoring your plugin to use the C++ wrapper for the plugin interface available at https://github.com/mumble-voip/mumble-plugin-cpp. I think that'd also make it easier to maintain and extend in the future :)

[hbeni]

The reason is that i have no clue about cmake at all, I’m completely new to the c/c++ world.
Can you recommend a tutorial?

[Krzmbrzl]

A really good resource is https://cliutils.gitlab.io/modern-cmake/

I’m completely new to the c/c++ world.

In that case I recommend getting to know cmake even more. It has become the de facto standard in this area (for newer projects anyways) and it makes it comparatively easy to support multiple OS.

[hbeni]

Cool i will check it out!
My final goal would be cross compiling on Linux for Windows, because then i can easily create packages without switching the platform.

[hbeni]

Using dependency walker i found out that the DLL has some unmet dependencies.
I wonder where they are supposed top be coming from - i would have assumed that they are dynamically fetched from the running windows?
Dies this indicate a problem in my source files?

Error: At least one required implicit or forwarded dependency was not found.
Warning: At least one delay-load dependency module was not found.

[hbeni]

btw, even tough the other plugins are displayed, i cannot load them! ☝️

[Krzmbrzl]

Ah it seems like there is an issue with the CRT. That's always super annoying and I twnd to just try and fail until it is working. Thus I am not really an expert here xD

[hbeni]

The https://github.com/lucasg/Dependencies shows pthreads missing:

I was of the impression that i statically included it, because i gave: -Wl,-Bstatic -lpthread to mingw....

But at least i'm on track of the error now.

[hbeni]

@Krzmbrzl
-Wl,-Bstatic -lstdc++ -lpthread -lws2_32 does the trick :)
The plugin is now visible, loadable and it even seems to start internal stuff.

However, i cannot get an UDP connection to work - now it would be very helpful to be able to see mumble's console output so i can see whats going on internally and which data is received etc.
However, even when i call mumble.exe -m from a CMD window, the command immediately returns and opening an detached window version. How can i make mumble.exe to stay attached on my cmd window, or at least log into a file?

[Krzmbrzl]

btw, even tough the other plugins are displayed, i cannot load them!

Something's odd in your setup anyways. Why do you have every plugin listed twice? That's not how it should be 🤔

How can i make mumble.exe to stay attached on my cmd window, or at least log into a file?

Inside Mumble you can open the so-called "Developer console" that contains the terminal's output. In order to access it, go into the settings and under user interface, enable the developer menu. This will give you a new entry in Mumble's toolbar from which you can open the console ☝️

[hbeni]

Something's odd in your setup anyways. Why do you have every plugin listed twice? That's not how it should be 🤔

I have no idea - i just invoked the installer if this snapshot.

Inside Mumble you can open the so-called "Developer console"

very good, thank you, will try that!

[hbeni]

@Krzmbrzl Hi Robert, i played around and still have two problems.

1. I tried the developer console but i cant find any of my plugins log or debug output. But there should at least be the initialization lines there, because the first init steps are run trough definitely (the plugin logs also some important stuff to the chat window, and that works)

2. OpenSSL: I try to compile in openssl statically, but i fail to do so. The DLLs are not included in the generated plugin-dll (but compiling suceeds...). Do you, by chance, have an idea whats going on?
   ❓ Specifically, in the developer console i can see that mumble itself has an openSSL included - couldn't my plugin leverage it instead of including my own (i need it just for support of HTTPs in the updater check)?
   

[Krzmbrzl]

1. I assume that the Developer console only shows logs written with Qt's functions then. After some googling it seems that Windows is just incredibly stupid (once again) since you can either create a console application for which you see stdout, or a GUI application (which Mumble seems to be) for which you don't see it. And there doesn't seem to be an easy way of chaning that. I guess the best thing would probably be if you wrote your logs to a file instead.
2. The fact that you are creating OpenSSL dll files means that you are not compiling it statically (dll is a shared library). And to my knowledge it is not possible to link statically to a shared library. Using Mumble's version of OpenSSL is probably not possible either. I'm not 100% sure of this one though.

[hbeni]

Writing to a log is a very good idea! Thank you for that!

Re the DLL: i revisit that, but i was pretty sure that i linked statically. It does also change my plugins size drastically, so there is more code included.
I Link against the libssl.dll.a and that should be the static lib?

[Krzmbrzl]

If it's a .a then it should be static. Given that you still have a dependency on the shared libs it seems 🤔

[hbeni]

ldd Says, it’s not linked dynamically. Nonetheless the static lib is not placed into my dll... weird.

[Krzmbrzl]

🤷
I guess you'll have to use the good old trial & error approach here xD

[hbeni]

SSL: Seems i got it working. I added the -static flag to OpenSSLs mingw build.
That seemed to do the trick.... Only god knows why the "other" statically build libs didn't work.

On to the next thing on the bucket list :)

[hbeni]

@Krzmbrzl Robert, what’s the intended way to log stuff, so it shows up in the developer window?
Just curious

[Krzmbrzl]

I added the -shared flag to OpenSSLs mingw build.

So -shared actually caused it to properly link static?! 🤦

what’s the intended way to log stuff, so it shows up in the developer window?

I don't think there's a way to do that from a plugin. Inside Mumble's code I assume that everything logged via qDebug. qWarning and qFatal will show up there.
From a plugin you can only log to Mumble's console using the log API function 🤷

[hbeni]

So -shared actually caused it to properly link static?! 🤦

Oops, meant -static. The important bot is the dash, because just static breaks the build.

From a plugin you can only log to Mumble's console using the log API function

Wouldnt it be cool if that would redirect to the proper place?

[Krzmbrzl]

Wouldnt it be cool if that would redirect to the proper place?

Well I think a way to log to a log-file is more useful than heing able to hack into the Developer console 🤔

[hbeni]

The logfile produced helpful information.
The Threadsa re running fine, but the UDP server is not functioning properly.
As soon as the UDP listen port opens, it receives lots of garbage and is swarmed with a loop, never actually fetching real data. The data received is always binary garbage and randomly switching.

FGCom [2021-01-07 .519]: [LOG] Logfile opening: C:\Users\Beni\Documents\fgcom-mumble.log; result=success
FGCom [2021-01-07 .519]: [DBG] [CFG] Parsing token: udpServerHost=*
FGCom [2021-01-07 .519]: [DBG] [CFG] Parsing token: udpServerPort=16665
FGCom [2021-01-07 .519]: performing offline initialization
FGCom [2021-01-07 .519]: [DBG] starting local UDP server
FGCom [2021-01-07 .519]: [DBG] udp server started
FGCom [2021-01-07 .519]: [UDP-server] server starting
FGCom [2021-01-07 .519]: [DBG] starting garbage collector
FGCom [2021-01-07 .519]: [DBG] garbage collector started
FGCom [2021-01-07 .519]: fgcom_initPlugin(): not connected, so no online init possible (will try later)
FGCom [2021-01-07 .519]: Initialized plugin
FGCom [2021-01-07 .519]: [DBG] [GC] thread starting
FGCom [2021-01-07 .519]: [UDP-server] udp socket bind succeeded
FGCom [2021-01-07 .519]: [UDP-server] server up and waiting for data at *:16665
FGCom [2021-01-07 .519]: [DBG] [UDP-server] received message (client=0.0.0.0:0): ÿ�
FGCom [2021-01-07 .519]: [DBG] [UDP-server] Segment='ÿ�'
FGCom [2021-01-07 .519]: [DBG] [UDP-server] segment invalid (is no key=value format): ÿ�
FGCom [2021-01-07 .519]: [DBG] [UDP-server] packet fully processed
FGCom [2021-01-07 .519]: [DBG] [UDP-server] received message (client=0.0.0.0:0): ÿ�
FGCom [2021-01-07 .519]: [DBG] [UDP-server] Segment='ÿ�'
FGCom [2021-01-07 .519]: [DBG] [UDP-server] segment invalid (is no key=value format): ÿ�
FGCom [2021-01-07 .519]: [DBG] [UDP-server] packet fully processed
[... more to follow until i shut down the plugin...]
FGCom [2021-01-07 .253]: Shutdown plugin
FGCom [2021-01-07 .253]: [DBG] stopping threads
FGCom [2021-01-07 .253]: [DBG] sending UDP shutdown request to port 16665
FGCom [2021-01-07 .253]: [DBG] waiting for threads to finish
FGCom [2021-01-07 .253]: [DBG] [UDP-server] Segment='ÿ�'
FGCom [2021-01-07 .253]: [DBG] [UDP-server] segment invalid (is no key=value format): ÿ�
FGCom [2021-01-07 .253]: [DBG] [UDP-server] packet fully processed
FGCom [2021-01-07 .253]: [DBG] [UDP-server] thread finished.
FGCom [2021-01-07 .683]: [DBG] [GC] thread finished
FGCom [2021-01-07 .724]: [DBG] mumble_shutdown() complete.

Maybe this is a memory allocation thingy that works different on windows, or the receiving function is in an endless loop, never actually fetching network data. Have to investigate.

• Some other things i see: the timestamp is not in the full format, it's only showing the fraction, not the hour/second etc. I must check if thats also the case on linux, but i think i checked that when i implemented that feature.
  EDIT: it's using %T which resolves to %H:%M:%S on linux, on windows obviously not :/

[hbeni]

Maybe this is a memory allocation thingy that works different on windows, or the receiving function is in an endless loop, never actually fetching network data. Have to investigate.

With more debug code and the logging-to-file facility, i now have found the exact cause:

Why that happens is still unclear to me, but i at least can go searching the interwebz now.

(btw. if someone is asking himself why I'm so verbosely: Its so i (or others) can pick the work up when i have to leave quickly to attend to childs/wife/life 😁 )

[hbeni]

YES 🚀 🎆 i got it working!
The problem was, the socket API under windows was not initialized. You have to call WSAStartup() before using the sockets...

Just did the first successful test at windows10 with two mumble instances and it worked like expected :) 👍

[Krzmbrzl]

A tip that I would have: It would probably be easier if you were to search for a cross-platform library that handles the OS-specific stuff for you. That usually proofs easier in maintenance :)

[hbeni]

Thanks Robert!
I tought about that, but currently there are really small parts: i have some small stuff in the UDP code and some other in the "find my homedir" part, both just a few lines of code.

[Krzmbrzl]

That's how it always starts but stuff like that tends to grow over time :P

[hbeni]

true!