Experimental Physics and Industrial Control System
|
Hi,
Ok, maybe an example might help. If you were using a library that exported an allocateSomeMemory() function then you would probably
not be surprised if you called free() on some memory returned from this and got a crash, you are not guaranteed allocateSomeMemory() (or any pointers/objects returned from the library) used malloc() and you need to call the appropriate freeSomeMemory() function
(hopefully) provided by that library to deallocate safely.
On windows when you compile static/dll/debug/release this can lead to a different choice of malloc/free/new/delete (and also allocation
of file descriptor functions) being embedded in the library. To be absolutely safe on windows you need to assume that any pointers to objects or resources returned from a third party library have been allocated by an unknown allocateSomeMemory() like function
and you need to use the appropriate freeSomeMemory() or similar to deallocate it. If you compile all objects that share resources the same way, then they will all be using the same underlying C library functions and you do not get an issue. If you mix objects
compiled with different CRTL flags within a library, then it might potentially work depending on which objects shared resources with each other, or you may instead get a link time error about multiply defined symbols as it tries to bring in two different versions
of the C library each defining the same functions (you can sometimes work around this with the /NODEFAULTLIB linker flag)
So in the example below if Com, ca, ezca, and EzcaScan and all built the same statically (/MT compiler flag) and linked together to
form ezcaIDL.dll that will all work fine with the following proviso. If ezcaIDL.dll exports functions that return pointers to objects allocated within the library, then these objects will have used malloc etc. appropriate for the static /MT flag. If ezcaIDL.dll
was linked/loaded into an application that had been compiled /MD (i.e. to use the dynamic CRTL) then it could happily use these objects/pointers returned by the ezcaIDL library, but it must not call free() etc on these pointers as it would call the wrong (/MD)
version of the free function. If you needed a /MD compiled application to be able to able to call free() directly on such pointers, you would need to change /MT to /MD in the static compile for the components of ezcaIDL.dll Note that in times gone by mixing
code all compiled /MD but with different versions of visual studio also caused similar issues …
Regards,
Freddie
From: Core-talk <core-talk-bounces at aps.anl.gov>
On Behalf Of Ralph Lange via Core-talk
Sent: 18 June 2021 10:04
To: EPICS Core Talk <core-talk at aps.anl.gov>
Subject: Re: Problem building ezcaIDL on Windows
Ø
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?
Well, tbh I'm not using EPICS on Windows a lot...
@Freddie: you were suggesting that when you helped me get the gtest module work correctly on Windows. What were those side effects?
This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI.
|
- Replies:
- Re: Problem building ezcaIDL on Windows Mark Rivers via Core-talk
- References:
- Problem building ezcaIDL on Windows Mark Rivers via Core-talk
- RE: Problem building ezcaIDL on Windows Mark Rivers via Core-talk
- RE: Problem building ezcaIDL on Windows Mark Rivers via Core-talk
- Re: Problem building ezcaIDL on Windows Michael Davidsaver via Core-talk
- RE: Problem building ezcaIDL on Windows Mark Rivers via Core-talk
- Re: Problem building ezcaIDL on Windows Johnson, Andrew N. via Core-talk
- RE: Problem building ezcaIDL on Windows Mark Rivers via Core-talk
- Re: Problem building ezcaIDL on Windows Johnson, Andrew N. via Core-talk
- RE: Problem building ezcaIDL on Windows Mark Rivers via Core-talk
- Re: Problem building ezcaIDL on Windows Ralph Lange via Core-talk
- RE: Problem building ezcaIDL on Windows Mark Rivers via Core-talk
- Re: Problem building ezcaIDL on Windows Ralph Lange via Core-talk
- Navigate by Date:
- Prev:
Build failed in Jenkins: EPICS-3.14 #1073 Jenkins EPICS PSI via Core-talk
- Next:
Build failed: EPICS Base 7 base-7.0-346 AppVeyor via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Problem building ezcaIDL on Windows Ralph Lange via Core-talk
- Next:
Re: Problem building ezcaIDL on Windows Mark Rivers via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
|
ANJ, 24 Jun 2021 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|