1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 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: building EPICSR3.14.8.1 on MacOSX 10.3/10.4 |
From: | Noboru Yamamoto <[email protected]> |
To: | Noboru Yamamoto <[email protected]> |
Cc: | Eric Norum <[email protected]>, Marty Kraimer <[email protected]>, Janet Anderson <[email protected]>, "'[email protected]'" <[email protected]> |
Date: | Tue, 27 Dec 2005 23:03:25 +0900 |
Eric Norum wrote:It appears that this mixup occurred when epicsStdlib.c was added. What about making the following change?
Index: epicsStdlib.c
===================================================================
RCS file: /net/phoebus/epicsmgr/cvsroot/epics/base/src/libCom/misc/epicsStdlib.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 epicsStdlib.c
--- epicsStdlib.c 12 Dec 2005 19:54:46 -0000 1.1.2.1
+++ epicsStdlib.c 26 Dec 2005 18:22:40 -0000
@@ -43,6 +43,9 @@
return 1;
}
+#ifdef epicsStrtod
+# undef epicsStrtod
+#endif
epicsShareFunc double epicsStrtod(
const char *str, char **endp)
{
I'm quite surprised that this problem didn't show up during pre-release testing. I suspect that it will cause the same infinite recursion on all POSIX targets.
In the distribution, there are several place where I can find osdStrtod.h:
[noboru-g4:libCom/osi/os] noboru% find ./ -name osdStrtod.h -print .//RTEMS/osdStrtod.h .//WIN32/osdStrtod.h .//cygwin32/osdStrtod.h .//hpux/osdStrtod.h .//posix/osdStrtod.h .//vxWorks/osdStrtod.h
These files other than posix/osdStrtod.h include lines:
/*
* epicsStrtod() for systems with broken strtod() routine
*/
epicsShareFunc double epicsShareAPI epicsStrtod(const char *str, char **endp);
However, the origiral distribution does not have this type of osdStrtod.h in the osi/os/Darwin directory and cases the infinite recursion.
Regards,
Noboru
On Dec 26, 2005, at 12:14 AM, Noboru Yamamoto wrote:
Hi,
I encountered a problem to run EPICS CA clients build with EPICSR3.14.8.1 under MacOSX 10.3/10.4.
In the osdStrtod.h under base-3.14.8.1/src/libCom/osi/posix, macro epicsStrtod is defined as:
#define epicsStrtod strtod
On the otherhand , the file epicsStdlib.c in base-3.14.8.1/src/libCom/ includes the definition of epicsStrtod. Because <epicsStrtod.h> is included before the definition of epicsStrtod function, this definition
acually defines strtod as a external funtion.
The epicsStrtod calls a strtod function inside it. It ends up the
infinite calling sequence. For example, a simple "caget fred" command will never end in this environment.
I'm not quite sure if this problem is related to my development environment( MacOSX 10.3/10.4 with gcc3, distributed by Apple . I don't use any fink command.)
1) Is there any other who encounter the same or similar problem with EPICS3.14.8.1?
2) there may be severay ways to avoid this phenomena, but which one do you like to take. For example, just remove the sentence
#define epicsStrtod strtod
or define a new macro like
#define HAS_WORKING_STRTOD_IN_SYSTEM 0
and skip the definition of epicsStrtod.
Or better otherway?
Thank you very much for your attension.
Regards,
Noboru Yamamoto EPICS group/JPARC control group KEK, JAPAN
--
Eric Norum <[email protected] <mailto:[email protected]>>
Advanced Photon Source Argonne National Laboratory
(630) 252-4793