C++ Dynamic Library, iostream: No such file

Question

Hi, I'm trying to build a dynamic library in Xcode and running into a compilation error finding iostream. The library code is written in C++ and compiles on linux. When compiling in Xcode (2.4.1), I created the project as a C++ Standard Dynamic Library (and later C++ Dynamic Library, same problem) and get the following when building:
Building target “MC_VICommon” of project “MC_VICommon” with configuration “Debug”
Checking Dependencies
ProcessPCH++ /Library/Caches/com.apple.Xcode.501/SharedPrecompiledHeaders/MCVICommon_Prefix-dbtpcuqquksioscuujethfosvirt/MC_VICommonPrefix.pch.gch MCVICommonPrefix.pch normal ppc c++ com.apple.compilers.gcc.4_0
cd /Users/sullivan/Code/Source/VI/MC_VICommon
/usr/bin/gcc-4.0 -x c++-header -arch ppc -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -fmessage-length=0 -mtune=G5 -fvisibility-inlines-hidden -mfix-and-continue -mmacosx-version-min=10.4 -gdwarf-2 -I/Users/sullivan/Code/Builds/Intermediate/MCVICommon.build/Debug/MC_VICommon.build/libMCVICommon.hmap -F/Users/sullivan/Code/Builds/Debug -I/Users/sullivan/Code/Builds/Debug/include -I/Users/sullivan/Code/Builds/Intermediate/MCVICommon.build/Debug/MCVICommon.build/DerivedSources -isysroot /Developer/SDKs/MacOSX10.4u.sdk -c /Users/sullivan/Code/Source/VI/MCVICommon/MC_VICommonPrefix.pch -o /Library/Caches/com.apple.Xcode.501/SharedPrecompiledHeaders/MCVICommon_Prefix-dbtpcuqquksioscuujethfosvirt/MC_VICommonPrefix.pch.gch
ProcessPCH /Library/Caches/com.apple.Xcode.501/SharedPrecompiledHeaders/MCVICommon_Prefix-cdgabvnmevghggbxbomensvfvhzy/MC_VICommonPrefix.pch.gch MCVICommonPrefix.pch normal ppc c com.apple.compilers.gcc.4_0
cd /Users/sullivan/Code/Source/VI/MC_VICommon
/usr/bin/gcc-4.0 -x c-header -arch ppc -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -fmessage-length=0 -mtune=G5 -mfix-and-continue -mmacosx-version-min=10.4 -gdwarf-2 -I/Users/sullivan/Code/Builds/Intermediate/MCVICommon.build/Debug/MC_VICommon.build/libMCVICommon.hmap -F/Users/sullivan/Code/Builds/Debug -I/Users/sullivan/Code/Builds/Debug/include -I/Users/sullivan/Code/Builds/Intermediate/MCVICommon.build/Debug/MCVICommon.build/DerivedSources -isysroot /Developer/SDKs/MacOSX10.4u.sdk -c /Users/sullivan/Code/Source/VI/MCVICommon/MC_VICommonPrefix.pch -o /Library/Caches/com.apple.Xcode.501/SharedPrecompiledHeaders/MCVICommon_Prefix-cdgabvnmevghggbxbomensvfvhzy/MC_VICommonPrefix.pch.gch
/Users/sullivan/Code/Source/VI/MCVICommon/MC_VICommonPrefix.pch:6:20: error: iostream: No such file or directory
Later I tried starting the project as a Carbon dynamic library and it seems to work fine. Now granted, "if it ain't broke don't fix it", but I am curious and worried this will cause problems later.
One obviously relevant difference between the working Carbon and non-working C++ is the project_prefix.pch files:
// Prefix header for all source files of the 'MC_VICommon' target in the 'MC_VICommon' project.
#include <iostream>
vs.
// Prefix header for all source files of the 'CarbonTest' target in the 'CarbonTest' project.
#include <Carbon/Carbon.h>
Should I just accept that the carbon one works? Am I doing something wrong? Is there documentation about linking to Carbon vs. not?
Thanks!

Answer 1

Thanks for the suggestion. With Xcode though, the build and link parameters are determined automatically. I'm under the impression that it will separate out the .c's and .cpp's to compile with their own parameters. I am wondering now why the prefix.pch file, which is compiled with both -x c++-header and -x c-header, includes iostream. Anyway, I found if I just comment out that line in the prefix file, everything works fine. Even if I clean and re-build, the comment is not over-written and everything builds.
99% of the time using Xcode is more convenient than makefiles, but on these occasions when an automatically generated file causes problems, I get curious as to what happens behind the scenes when I build a project template like C++ Dynamic Library. I presume there is a way to change my code such that this won't happen, but if I knew why it happened it would help. Anyway, since this work-around is good enough, I should probably just be happy and move on.