2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: Problem building ezcaIDL on Windows |
From: | Freddie Akeroyd - STFC UKRI via Core-talk <core-talk at aps.anl.gov> |
To: | "EPICS core-talk (core-talk at aps.anl.gov)" <core-talk at aps.anl.gov> |
Date: | Wed, 23 Jun 2021 22:14:28 +0000 |
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 On Fri, 18 Jun 2021 at 00:45, Mark Rivers <rivers at cars.uchicago.edu> wrote:
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? Cheers, ~Ralph 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. |