-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows shared library build problem under both VS2019 and MSYS2 #954
Comments
Config log for VS2019.
Failed build log. Click for full build log
|
The avrdude code is not designed to build a Windows DLL. Is there a specific reason why you are trying to build a DLL? |
I still think this must somehow be a CMake issue. MacOS shows the same error messages when trying to build a shared library using CMake as the Windows build shows (missing global symbols). However, autoconf has no issues building libavrdude.1.dylib in the same environment. There must be something they're handling differently … so regardless of whether there is anyone using the shared libs right now, I think we'd better analyze the reason. After all, building a shared lib is not supposed to cause any additional effort at all (and it has never been additional effort with autoconf/automake). |
I can only speak for Windows, but looking at the log, there seems to be a couple of things one could fix, such as the missing usleep that is compiled outside the DLL. However, there are other external symbols, that are to be implemented by the host application, for instance |
Seems a little strange to me that a DLL cannot access the global namespace of the target application … anyway, would it help to turn "progname" into a library-internal (not really entirely) global symbol? We could then have something like |
Sure. IMHO, that is the way to go. A library should never expose global data, let alone data structures, and the dependencies should only point one way. But, again I ask, is it worth the trouble if nobody is using it? If there is ever a need, one could make the changes then. |
The biggest problem would be For reference, here's the dylib linker command lines.
CMake:
|
It's not about exposing global data, it's about using global data (from the application).
Because the entire idea of separating the library backend is fairly useless if it is not usable in the end. We once started to separate the backend code, so I think we should walk that way to the end (and it's my feeling that we already managed 95 % of the way, so it's not that we were just at the beginning). |
Hmm... would a function pointer work? I mean, the application defines the function |
Yes, that's the idea if directly accessing global namespace (of the application) doesn't work. |
VS2019 configure log is good with #962 for the shared library option.
|
I agree to close this issue as it can be tracked in #952 or #819
#952 is still relevant as it is not possible to build the shared library under Windows even with #962. Fail log under Windows using MSYS2 mingw64.
|
I am not able to build the shared library under either VS2019 or MSYS2. Static build is okay.
Ref: #952 (comment)
Ref: #951 (comment)
The text was updated successfully, but these errors were encountered: