EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  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  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Problem building asyn R4-25 on Mac OSX Yosemite
From: Mark Rivers <[email protected]>
To: "'J. Lewis Muir'" <[email protected]>
Cc: "[email protected] Talk" <[email protected]>
Date: Wed, 7 Jan 2015 19:38:26 +0000
Hi Lewis,

Thanks, that makes sense.  The bug was indeed in asynPortClient.h.

Mark


-----Original Message-----
From: J. Lewis Muir [mailto:[email protected]] 
Sent: Wednesday, January 07, 2015 1:37 PM
To: Mark Rivers
Cc: Henrique Almeida; [email protected] Talk
Subject: Re: Problem building asyn R4-25 on Mac OSX Yosemite

On 1/7/15 7:18 AM, Mark Rivers wrote:
> Why is it necessary to include string only on OSX Yosemite, and not on
> Linux, Windows, vxWorks, or earlier versions of OSX?

Hi, Mark.

I think it's because of a difference between Clang and GCC (or another
compiler) or the C++ standard library that comes with the compiler.
On OS X Yosemite, asyn is being compiled with Clang, but on those
other systems, GCC or some other compiler is probably being used.  The
difference could also be between the version of Clang on OS X Yosemite
and an older version of Clang which might explain why it worked on a
previous version of OS X (assuming nothing else has changed; I haven't
tried compiling asyn R4-25 on a previous version of OS X).

Looking at line 75 of asyn/asynPortClient/asynPortClient.h from R4-25,
it is creating a new string instance via the std::string constructor,
but the string header is not included in asynPortClient.h.  The only C++
standard include at the top of asynPortClient.h is the stdexcept header:

  #include <stdexcept>

My guess is that including stdexcept using some compilers will cause
the string header to be included while on others, like Clang on OS X
Yosemite, it won't, hence the compile failure.

I created the following simple C++ program:

=== main.cc ===
1    #include <stdexcept>
2
3    int main(int argc, char *argv[])
4    {
5      return (argc >= 2) ? std::string(argv[1]).length() : 0;
6    }
===============

On an OS X Yosemite machine, it fails to compile as follows:

=== console ===
$ /usr/bin/clang++ -Wall -ansi -pedantic -o main main.cc
main.cc:5:24: error: implicit instantiation of undefined template
      'std::__1::basic_string<char, std::__1::char_traits<char>,
      std::__1::allocator<char> >'
  return (argc >= 2) ? std::string(argv[1]).length() : 0;
                       ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iosfwd:188:33: note: 
      template is declared here
    class _LIBCPP_TYPE_VIS_ONLY basic_string;
                                ^
1 error generated.
===============

If I comment out the stdexcept header include on line 1 of main.cc, it
also fails to compile, but with a different error message:

=== console ===
$ /usr/bin/clang++ -Wall -ansi -pedantic -o main main.cc
main.cc:5:24: error: use of undeclared identifier 'std'
  return (argc >= 2) ? std::string(argv[1]).length() : 0;
                       ^
1 error generated.
===============

Finally, if I replace line 1 of main.cc with the string header include
("#include <string>"), it compiles cleanly:

=== console ===
$ /usr/bin/clang++ -Wall -ansi -pedantic -o main main.cc
===============

Repeating the same three tests on a RHEL 5 machine using GCC produces a
different result for the first test but the same result for the other
two.

For the original main.cc, it compiles cleanly (unlike Clang):

=== console ===
$ /usr/bin/g++ -Wall -ansi -pedantic -o main main.cc
===============

When I comment out the stdexcept header include in line 1, it fails
(like Clang):

=== console ===
$ /usr/bin/g++ -Wall -ansi -pedantic -o main main.cc
main.cc: In function ‘int main(int, char**)’:
main.cc:5: error: ‘string’ is not a member of ‘std’
===============

And finally, replacing line 1 with the string header include, it
compiles cleanly (like Clang):

=== console ===
$ /usr/bin/g++ -Wall -ansi -pedantic -o main main.cc
===============

The OS X Yosemite machine is x86_64 hardware running OS X Yosemite
(10.10.1) with Xcode 6.1.1 and clang++ reporting the following version:

=== console ===
$ /usr/bin/clang++ --version
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
===============

The RHEL 5 machine is x86_64 hardware running Red Hat Enterprise Linux
Client 5.11 and GCC reporting the following version:

=== console ===
$ /usr/bin/g++ --version | head -1
g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
===============

Regards,

Lewis


References:
Problem building asyn R4-25 on Mac OSX Yosemite Mark Rivers
Re: Problem building asyn R4-25 on Mac OSX Yosemite Henrique Almeida
Re: Problem building asyn R4-25 on Mac OSX Yosemite Henrique Almeida
RE: Problem building asyn R4-25 on Mac OSX Yosemite Mark Rivers
Re: Problem building asyn R4-25 on Mac OSX Yosemite J. Lewis Muir

Navigate by Date:
Prev: Re: Problem building asyn R4-25 on Mac OSX Yosemite J. Lewis Muir
Next: RE: Is it possible for an Asyn output record to be, also, an (I/O Intr - driven) input? Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Problem building asyn R4-25 on Mac OSX Yosemite J. Lewis Muir
Next: Problems building EPICS base3.14.12.4 for i386 and armhf Florian Feldbauer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024