|
|
On 11/25/22 21:02 Bill Spitzak wrote:
This use of local versions is only being done on
Windows, correct?
Bill, this thread is about the CI builds on GitHub, aka GitHub
Actions. We have no choice to select which software is installed on
these systems. Since we need `fluid` to build and run to generate
headers and sources of test apps we must take care that it works
even on these CI systems. But this is *only* the case for CI builds.
Users can do whatever they want, be it Windows or not.
However, there *can* be a reason to force using the bundled libs: if
the system libs *are* not compatible with the code FLTK uses.
I really don't like this as we absolutely should be using
the installed libraries if at all possible, even on Windows.
At minimum something needs to be done so that the local header
files are not used if fltk is built using installed libraries.
That's all done, no problem.
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.
--
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/CAL-8oAjcf1CPuTo7z2_ENC7tCgj8oi2XkCdhsd4UWgohZJN1uw%40mail.gmail.com.
--
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/1b7aef91-fb92-5794-aabe-b0b68221faba%40online.de.
[ Direct Link to Message ] | |
|
| |