Re: 10.2 deployment issues
Re: 10.2 deployment issues
- Subject: Re: 10.2 deployment issues
- From: Chris Espinosa <email@hidden>
- Date: Mon, 27 Oct 2003 21:39:21 -0800
On Monday, October 27, 2003, at 09:15 PM, Monroe Williams wrote:
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):
That's because the underlying wchar_t support is not in the system
dylibs on any existing Jaguar builds, including 10.2.7 and 10.2.8.
Wide character support is only available on Panther systems.
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.
You are linking to a static library on Panther that expects Panther
dylibs that aren't present on a Jaguar system. The references are
coming from the static library you're linking with, not from your code.
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.
It's mostly implemented in Carbon frameworks, somewhat implemented in
Cocoa, and occasionally implemented in Darwin (/usr/include) headers.
Some frameworks like OpenGL have their own versioning and dynamic
loading mechanism that is framework-specific and common to all
platforms but is different from the AvailabilityMacros mechanism.
And wchar_t is a special case, because it requires specific compiler
support and coordination. You can't really build one set of sources
that uses wchar_t on Panther, but still loads and runs on Jaguar
without using wchar_t, because the support for that is deeply ingrained
in the compiler codegen and the static link libraries -- not just in
the C runtime.
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)
That's unexpected and I'll look into this.
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.
You should set both the DEPLOYMENT_TARGET to 10.2 and the SDK to 10.2.7
in order to build C++ for deployment on 10.2.x. You can't use wchar_t
in this context because that's built into the compiler and its static
link libraries.
Chris
_______________________________________________
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.