Re: 10.2 deployment issues
Re: 10.2 deployment issues
- Subject: Re: 10.2 deployment issues
- From: Monroe Williams <email@hidden>
- Date: Mon, 27 Oct 2003 22:31:05 -0800
On Oct 27, 2003, at 9:39 PM, Chris Espinosa wrote:
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.
Right. I was pretty sure that was the case.
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.
I was afraid of that. I think it must be due to references to
something in the C or C++ runtime, since all the other libraries we're
linking to are either dylibs or static .a files that were built on
Jaguar.
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.
Just to be clear: I don't need any wchar_t support. If I could turn
it all off and make all references to wchar_t or the wide iostreams
variants into compile-time errors, I'd #ifdef any such references out
of our code and be done with it. The problem is, I don't know where in
a large and complex codebase these things are being referenced, and I
haven't found any way to get the tools to help me figure it out.
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.
That was one of the first things I tried. Presumably, if the
unexpected link error wasn't getting in the way, it would work.
You can't use wchar_t in this context because that's built into the
compiler and its static link libraries.
That's just fine. After this, I don't ever want to see a wchar_t
again. :P
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.