Ø
Just be aware of and careful about the dynamic and static variants of Windows builds additionally setting other compiler flags differently. Mixing object code that has been produced with different flags may create unwanted bad
side effects. I.e., you shouldn't put object code from a dynamic build into a static library and vice versa.
That is an interesting point. It is actually how that DLL has been built for many years. It is convenient, because Com, ca, ezca, and EzcaScan are statically built into ezcaIDL.dll. That DLL thus stands alone, and one does not need all
the other DLLs. Depending on other DLLs can lead to a real mess with PATH. With applications (.exe files) I believe that Windows will look first for DLLs in the same folder as the .exe. But for a run-time loadable DLL like ezcIDL.dll that does not seem
to be the case.
The mixed-mode has worked fine for many years. What are the types of problems people have seen when doing that?
Mark
From: Core-talk <core-talk-bounces at aps.anl.gov>
On Behalf Of Ralph Lange via Core-talk
Sent: Saturday, June 12, 2021 2:55 AM
To: EPICS Core Talk <core-talk at aps.anl.gov>
Subject: Re: Problem building ezcaIDL on Windows
The names are already decorated with epicsShareFunc and epicsShareAPI.
It exports the symbols OK for these cases:
-
windows-x64 architecture
-
windows-x64-static architecture if the Makefile contains SHARED_LIBRARIES=YES, whether I use LIBRARY_HOST or LOADABLE_LIBRARY_HOST.
Just be aware of and careful about the dynamic and static variants of Windows builds additionally setting other compiler flags differently. Mixing object code that has been produced with different flags may create unwanted bad side effects.
I.e., you shouldn't put object code from a dynamic build into a static library and vice versa.
(Disclaimer: I did not follow the thread closely, so this specific use case may be doing things right.)