4

I am trying to get some older third-party software to compile on OS X 10.9. I've managed to get rid of most compilation problems by adjusting settings in the Makefiles, which were originally written for gcc probably around 2005. However, I currently don't know how to overcome this error for a C++ source file:

/utility.h:42:10: fatal error: 'ext/slist' file not found

I understand that ext/slist belongs to some version of STL. Has that version been superseded or does it have to be activated in any special way for Apple's version of Clang/LLVM (5.0 for OS X 10.9)?

If at all possible, I would prefer to compile this software with the pre-installed tools and not go through such steps as installing gcc via MacPorts.

BTW, these warnings also persist:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/ext/hash_set:202:2: warning: Use of the header is deprecated. Migrate to [-W#warnings] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/ext/hash_map:209:2: warning: Use of the header is deprecated. Migrate to [-W#warnings]

Community
  • 1
  • 1
Drux
  • 11,992
  • 13
  • 66
  • 116

1 Answers1

5

Slist is a singly linked list and was an extention included in libstdc++. Mac OS X has been moving away from libstdc++ toward libc++, which provides a C++11 standard library. C++11 provides a singly linked list under the name std::forward_list in the header <forward_list>.

I believe libstdc++ is still included in the developer tools, so you may also be able to switch your project back to that. If you're using an Xcode project you can select the library in the build settings, or ensure that the program is getting built with -stdlib=libstdc++

bames53
  • 86,085
  • 15
  • 179
  • 244
  • 1
    Thanks, `-stdlib=libstdc++` solved the problem. I am now getting other errors such as this: `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1/memory:222:7: note: candidate function not viable: no known conversion from 'tree *'(aka 'tree_node<> *') to 'std::auto_ptr ..."`. Could it be that I have to adjust the include path to reflect the older library as well? – Drux Nov 03 '13 at 23:39
  • 1
    No, that error is referring to the older library. That error seems to be a result of differences between the new compiler and the old one. – bames53 Nov 04 '13 at 00:22
  • So it looks as if the newer, [stricter](http://stackoverflow.com/questions/12779630/conversion-to-const-y-not-applicable-for-r-on-clang) compiler no longer accepts header files from the older library and without installing (MacPorts | brew) & gcc I am stuck ... – Drux Nov 04 '13 at 07:56
  • Clang is still often used with libstdc++, so the problem isn't that it doesn't work with the headers so much as that your program is using the library in an unsupported way. You're going to have to either modify the program's code itself or use an older toolchain. If you have an older version of OS X and Xcode lying around you can give that a try. Xcode 4 still has llvm-gcc which will probably compile the program successfully as-is. – bames53 Nov 04 '13 at 16:22
  • @bemes53 Yes, I plan to employ an older version of OS X with Xcode (or gcc) as you say. Just out of curiosity: why is it the program's problem when the error messages point to standard header files (these are not owned by the program)? – Drux Nov 04 '13 at 20:55
  • The standard library provides components that work correctly only when used properly. The library is written assuming that it will be used properly and isn't tested or verified to work under other circumstances. The conditions for proper use are often too complicated for the compiler to understand and check. So when the component is misused the compiler can't understand and point out where the program messed up, it just sees deep within the standard library machinery that something went wrong. – bames53 Nov 04 '13 at 21:56
  • That sounds like a lawyer speaking on behalf of the compiler but you are probably right :) Anyway, trying an older version seems the right way to go. – Drux Nov 05 '13 at 12:27