10.2 deployment issues
10.2 deployment issues
- Subject: 10.2 deployment issues
- From: Monroe Williams <email@hidden>
- Date: Mon, 27 Oct 2003 21:15:42 -0800
It appears that some of the wchar support available when building under
XCode with MACOSX_DEPLOYMENT_TARGET set to 10.2 is missing from
libSystem under 10.2. More specifically, after moving a rather large
project to XCode, I got the following when trying to run a build on
10.2.8 (the build runs fine on 10.3):
dyld: /path/to/the/executable symbols:
/path/to/the/executable undefined reference to _btowc expected to be
defined in /usr/lib/libSystem.B.dylib
/path/to/the/executable undefined reference to _iswctype expected to be
defined in /usr/lib/libSystem.B.dylib
/path/to/the/executable undefined reference to _mbsrtowcs expected to
be defined in /usr/lib/libSystem.B.dylib
/path/to/the/executable undefined reference to _towlower expected to be
defined in /usr/lib/libSystem.B.dylib
/path/to/the/executable undefined reference to _towupper expected to be
defined in /usr/lib/libSystem.B.dylib
/path/to/the/executable undefined reference to _wcscoll expected to be
defined in /usr/lib/libSystem.B.dylib
I haven't yet located any references to these symbols in our code.
None of the .o files generated during the build seem to contain the
symbols in question, and the indexer chokes on one of our source files
(a problem we're chasing through other channels), so XCode is no help
in finding the references. I'm hoping they're coming from our code,
where I can possibly do something about it, and not from a library or
framework. The code builds fine under ProjectBuilder on 10.2, or at
least it did last week, but it may do conditional compilation based on
the apparent availability of wchar support.
A simple test project created from the XCode "C++ tool" stationery has
a similar problem (although it only complains about _btowc) if I
reference std::wcout. i.e.:
int main (int argc, const char * argv[])
{
std::wcout << "Hello, World!\n";
return 0;
}
If I understand the semantics of MACOSX_DEPLOYMENT_TARGET correctly, it
SHOULD cause anything unavailable on the target OS to generate compile
and/or link errors, instead of runtime/late binding errors like these.
If this only works for symbols in frameworks, and not for things in
/usr/include, it's going to be a lot less useful.
The other obvious alternative, using the "10.2.7 SDK" setting, gets me
a link failure:
ld: Undefined symbols:
std::basic_streambuf<char, std::char_traits<char>
>::seekpos(std::fpos<__mbstate_t>, std::_Ios_Openmode)
Digging through the maze of iostreams templates to try and figure this
one out is more than I can take right now. Something very similar can
be reproduced by taking the "C++ Tool" stationery, changing the SDK
setting to 10.2.7, and replacing the contents of main.cpp with:
-----
#include <iostream>
#include <fstream>
int main (int argc, const char * argv[])
{
std::fstream file;
file.seekp(0);
return 0;
}
-----
(I know this code wouldn't run in any useful way, but it should compile
and link...)
Setting MACOSX_DEPLOYMENT_TARGET doesn't seem to have any effect on
this.
Any ideas for getting around this would be much appreciated.
Thanks,
-- monroe
------------------------------------------------------------------------
Monroe Williams email@hidden
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.