| |
| |
On 11/25/22 17:49 'melcher....@googlemail.com' via fltk.coredev wrote:
Wow, great work in finding this.
If we are using the host's libraries, do we also use the host's
include files? If yes, why would there incompatibilities?
Basically there is a possibility that there are incompatibilities
because our code might expect some features that are not (or no longer)
in the respective headers. If the host has another (older or newer)
version - most obvious a new major version - then this can happen.
However, then it would be very likely that it doesn't compile or can't
be linked. Neither of these possibilities was the case here.
Meanwhile I believe that my wording "incompatible" was not correct. I
came to the conclusion that we can compile and link but - unfortunately
- we link against DLL's and then - I assume! - one or more of these
DLL's is not found at runtime, hence the error message. Or maybe
*another* incompatible system DLL is found, or whatever. Unfortunately
Windows doesn't tell us which DLL can't be loaded.
Thus I decided to fix it by disabling system (image + z) libraries which
has the additional advantage that our bundled libs are built as well in
this CI run (as it was before).
I think that the fact that we can compile and link against some DLL's
(which are in non-system locations, BTW) is "normal" but then these
DLL's have to be somewhere in the PATH or the directory of the
executable. This seems to be the most plausible explanation.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/da1245fe-3ed3-6f4a-203d-80586aeb7a68%40online.de.
[ Direct Link to Message ] | |
|
| |
