You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by James Berry <jb...@criticalpath.com> on 2000/09/20 22:51:30 UTC
Re: Can't get Mac port working [Mac OS 8.x]
Hi Eric,
Thanks for posting these changes [to allow Xerces to work on some
pre-Mac OS 9.0 systems]. I'll work to incorporate into the source that
which looks applicable. But in looking over your suggested changes, I
must confess I'm a little confused. You seem to have attacked two or
three problems, rather than the one that (I) think is really necessary.
Most of your changes seem to have more to do with the version of
compiler and system headers you are using rather than with which OS
environment you're trying to run on.
Your changes fall into three categories:
(1) Allow code to work with fewer OS services (URLAccess, Unicode
Collation). I don't include HFS+ in this list because the code is
already sensitive to whether or not that is present in the system.
(2) Adapt to earlier compiler versions (static_cast).
(3) Compile with earlier headers and/or stub libraries (HFS+, CopyCStringToPascal).
The first of these is obviously a problem, and one that must be fixed
if this code is to live on certain pre-9.0 systems. The second looks
pretty easy to fix. The third (which seems to result in a good number
of the changes below) seems pointless (why not just install newer headers/libraries).
I've commented below. Will you let me know if there's something I'm
missing in all of this? I'll then take the time to make changes as
appropriate. Thanks again for your input, and I'm glad you've managed
to get this going. Your feedback is welcome and appreciated.
-jdb
Eric Singer wrote:
>
> Thanks to all who replied to my initial post. I now have the Mac
> port working under MacOS 8.5 (non-Carbon). For the benefit of others
> who need to do this, it required the following steps:
>
> Getting rid of URL Access
> - in XercesLibCommonPrefix.h, commented out #define
> XML_USE_NETACCESSOR_URLACCESS to disable URLAcess code
> - removed MacOSURLAccess.cpp and URLAccessBinInputStream.cpp from the
> project file
Yes, this will disable URL Access. I might also just try to make
URLAccess gracefully back out if it's not present, in order to prevent
you from having to remove the files from the project--you'd have to
weak link against URLAccess.
> Getting Unicode collation to work
> - in MacOSUnicodeConverter.cpp, changed #include <cwctype> to
> #include <ctype.h> due to std namespace conventions
This must be a compiler version issue? Which compiler are you using?
> - in MacOSUnicodeConverter.cpp, changed #if 0 to #if 1 in all
> relevant places to use C library based Unicode comparisions
Yes, this will eliminate reliance on Unicode converter. Again, I'll
try to make this work as a fall back if the Unicode collation routines
are not available.
> Getting rid of HFS+ references
> - in MacOSPlatformUtils.cpp, commented out static bool gHasHFSPlusAPIs = false
> - in MacOSPlatformUtils.cpp and MacOSPlatformUtils.hpp, removed all
> code from which references FSRef or uses file routines added in OS9
I miss the point of this. The code checks for the existance of HFS+
and backs away from using it. You just need to weak link against the
proper library?
> Missing CopyCStringToPascal() function
> - copied this function from CGlue.c into a new .c file and added this
> to the project
You should be able to link in the static library "CarbonAccessors" in
order to provide this routine.
> Misc
> - in MacOSPlatformUtils.cpp, removed the static_cast from void*
> XMLPlatformUtils::makeMutex() (due to compiler complaint about use of
> incomplete struct definition)
Okay, this is a compiler version issue.
> - in MacOSPlatformUtils.cpp, changed FSVolumeRefNum to equivalant
> type short in bool XMLParsePathToFSSpec(const XMLCh* const pathName,
> FSSpec& spec)
Once again, you shouldn't have a change this...you just need to have
the proper headers.
> Linking
> - linked with the following libraries when creating projects which
> use the Xerxes library:
> MSL C.PPC.Lib
> MSL SIOUX.PPC.Lib
> MSL RuntimePPC.Lib
> InterfaceLib
> MathLib
> MSL C++.PPC.Lib
> Multiprocessing API Library
> UnicodeConverter
> TextEncodingConverter
> UnicodeUtilitiesLib
> TextCommon
> Xerces.Classic.Lib
I'll verify and make sure this gets in the documentation.
--
/**********************************
James D. Berry
mailto:jberry@criticalpath.com
vox:503.265.1213 fax:503.222.3020
**********************************/
Re: Can't get Mac port working [Mac OS 8.x]
Posted by Mickael Gasrel <Mi...@europe.tgs.com>.
Hi,
Do you use a file.dtd in your file.xml ?
I have a crash in the parser when I include a file.dtd.
Mike.
----- Original Message -----
From: "James Berry" <jb...@criticalpath.com>
To: <xe...@xml.apache.org>
Sent: Wednesday, September 20, 2000 10:51 PM
Subject: Re: Can't get Mac port working [Mac OS 8.x]
> Hi Eric,
>
> Thanks for posting these changes [to allow Xerces to work on some
> pre-Mac OS 9.0 systems]. I'll work to incorporate into the source that
> which looks applicable. But in looking over your suggested changes, I
> must confess I'm a little confused. You seem to have attacked two or
> three problems, rather than the one that (I) think is really necessary.
>
> Most of your changes seem to have more to do with the version of
> compiler and system headers you are using rather than with which OS
> environment you're trying to run on.
>
> Your changes fall into three categories:
>
> (1) Allow code to work with fewer OS services (URLAccess, Unicode
> Collation). I don't include HFS+ in this list because the code is
> already sensitive to whether or not that is present in the system.
>
> (2) Adapt to earlier compiler versions (static_cast).
>
> (3) Compile with earlier headers and/or stub libraries (HFS+,
CopyCStringToPascal).
>
> The first of these is obviously a problem, and one that must be fixed
> if this code is to live on certain pre-9.0 systems. The second looks
> pretty easy to fix. The third (which seems to result in a good number
> of the changes below) seems pointless (why not just install newer
headers/libraries).
>
> I've commented below. Will you let me know if there's something I'm
> missing in all of this? I'll then take the time to make changes as
> appropriate. Thanks again for your input, and I'm glad you've managed
> to get this going. Your feedback is welcome and appreciated.
>
> -jdb
>
> Eric Singer wrote:
> >
> > Thanks to all who replied to my initial post. I now have the Mac
> > port working under MacOS 8.5 (non-Carbon). For the benefit of others
> > who need to do this, it required the following steps:
> >
> > Getting rid of URL Access
> > - in XercesLibCommonPrefix.h, commented out #define
> > XML_USE_NETACCESSOR_URLACCESS to disable URLAcess code
> > - removed MacOSURLAccess.cpp and URLAccessBinInputStream.cpp from the
> > project file
>
> Yes, this will disable URL Access. I might also just try to make
> URLAccess gracefully back out if it's not present, in order to prevent
> you from having to remove the files from the project--you'd have to
> weak link against URLAccess.
>
> > Getting Unicode collation to work
> > - in MacOSUnicodeConverter.cpp, changed #include <cwctype> to
> > #include <ctype.h> due to std namespace conventions
>
> This must be a compiler version issue? Which compiler are you using?
>
> > - in MacOSUnicodeConverter.cpp, changed #if 0 to #if 1 in all
> > relevant places to use C library based Unicode comparisions
>
> Yes, this will eliminate reliance on Unicode converter. Again, I'll
> try to make this work as a fall back if the Unicode collation routines
> are not available.
>
> > Getting rid of HFS+ references
> > - in MacOSPlatformUtils.cpp, commented out static bool gHasHFSPlusAPIs =
false
> > - in MacOSPlatformUtils.cpp and MacOSPlatformUtils.hpp, removed all
> > code from which references FSRef or uses file routines added in OS9
>
> I miss the point of this. The code checks for the existance of HFS+
> and backs away from using it. You just need to weak link against the
> proper library?
>
> > Missing CopyCStringToPascal() function
> > - copied this function from CGlue.c into a new .c file and added this
> > to the project
>
> You should be able to link in the static library "CarbonAccessors" in
> order to provide this routine.
>
> > Misc
> > - in MacOSPlatformUtils.cpp, removed the static_cast from void*
> > XMLPlatformUtils::makeMutex() (due to compiler complaint about use of
> > incomplete struct definition)
>
> Okay, this is a compiler version issue.
>
> > - in MacOSPlatformUtils.cpp, changed FSVolumeRefNum to equivalant
> > type short in bool XMLParsePathToFSSpec(const XMLCh* const pathName,
> > FSSpec& spec)
>
> Once again, you shouldn't have a change this...you just need to have
> the proper headers.
>
> > Linking
> > - linked with the following libraries when creating projects which
> > use the Xerxes library:
> > MSL C.PPC.Lib
> > MSL SIOUX.PPC.Lib
> > MSL RuntimePPC.Lib
> > InterfaceLib
> > MathLib
> > MSL C++.PPC.Lib
> > Multiprocessing API Library
> > UnicodeConverter
> > TextEncodingConverter
> > UnicodeUtilitiesLib
> > TextCommon
> > Xerces.Classic.Lib
>
> I'll verify and make sure this gets in the documentation.
>
>
> --
> /**********************************
> James D. Berry
> mailto:jberry@criticalpath.com
> vox:503.265.1213 fax:503.222.3020
> **********************************/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
Re: Can't get Mac port working [Mac OS 8.x]
Posted by James Berry <jb...@criticalpath.com>.
Eric Singer wrote:
> Interspersed comments follow:
>
> At 1:51 PM -0700 9/20/00, James Berry wrote:
> > > Getting Unicode collation to work
> > > - in MacOSUnicodeConverter.cpp, changed #include <cwctype> to
> >> #include <ctype.h> due to std namespace conventions
> >
> >This must be a compiler version issue? Which compiler are you using?
>
> CodeWarrior 5.3 (the latest), with Universal Headers 3.2.
>
> In MacOSUnicodeConverter.cpp, there is a mix of std:: qualified and
> non-qualified names from the standard library. In CW's (recent?)
> convention, standard libraries named <libname> use std:: qualified
> names; those named <libname.h> use unqualified.
>
> I think the only names which need to be qualified are wint_t and towupper.
Oh, I see. Some of the code you un-ifdef'd was not using proper
qualification. I'll fix those instances.
> >> Getting rid of HFS+ references
> >> - in MacOSPlatformUtils.cpp, commented out static bool
> >>gHasHFSPlusAPIs = false
> >> - in MacOSPlatformUtils.cpp and MacOSPlatformUtils.hpp, removed all
> >> code from which references FSRef or uses file routines added in OS9
> >
> >I miss the point of this. The code checks for the existance of HFS+
> >and backs away from using it. You just need to weak link against the
> >proper library?
>
> With the headers I'm using, it wouldn't compile. Agreed, might have
> been solved by me updating headers, but might be nice if the FSRef
> code was wrapped in a conditional compile flag.
I'd like to ask that you update your headers. CW Pro 6 is now out, and
shipping with Universal Header 3.3.2. Carbon 1.1 has Universal Headers 3.4.
The headers have had HFS+ stuff in them since Mac OS 8.1.
> > > Misc
> >> - in MacOSPlatformUtils.cpp, removed the static_cast from void*
> >> XMLPlatformUtils::makeMutex() (due to compiler complaint about use of
> >> incomplete struct definition)
> >
> >Okay, this is a compiler version issue.
>
> I thought this was a strange one. It didn't want to static_cast to
> void* with an incomplete class declaration, but it had no problem
> doing a C-style implicit cast to same.
I'll just change the cast.
>
Thanks for the feedback, Eric. I'll try to get these changes in soon.
-jdb
Re: Can't get Mac port working [Mac OS 8.x]
Posted by Eric Singer <er...@ericsinger.com>.
Interspersed comments follow:
At 1:51 PM -0700 9/20/00, James Berry wrote:
>Your changes fall into three categories:
>
> (1) Allow code to work with fewer OS services (URLAccess, Unicode
>Collation). I don't include HFS+ in this list because the code is
>already sensitive to whether or not that is present in the system.
>
> (2) Adapt to earlier compiler versions (static_cast).
>
> (3) Compile with earlier headers and/or stub libraries (HFS+,
>CopyCStringToPascal).
> > Getting rid of URL Access
>> - in XercesLibCommonPrefix.h, commented out #define
>> XML_USE_NETACCESSOR_URLACCESS to disable URLAcess code
>> - removed MacOSURLAccess.cpp and URLAccessBinInputStream.cpp from the
>> project file
>
>Yes, this will disable URL Access. I might also just try to make
>URLAccess gracefully back out if it's not present, in order to prevent
>you from having to remove the files from the project--you'd have to
>weak link against URLAccess.
Agreed - that would be helpful.
> > Getting Unicode collation to work
> > - in MacOSUnicodeConverter.cpp, changed #include <cwctype> to
>> #include <ctype.h> due to std namespace conventions
>
>This must be a compiler version issue? Which compiler are you using?
CodeWarrior 5.3 (the latest), with Universal Headers 3.2.
In MacOSUnicodeConverter.cpp, there is a mix of std:: qualified and
non-qualified names from the standard library. In CW's (recent?)
convention, standard libraries named <libname> use std:: qualified
names; those named <libname.h> use unqualified.
I think the only names which need to be qualified are wint_t and towupper.
> > - in MacOSUnicodeConverter.cpp, changed #if 0 to #if 1 in all
>> relevant places to use C library based Unicode comparisions
>
>Yes, this will eliminate reliance on Unicode converter. Again, I'll
>try to make this work as a fall back if the Unicode collation routines
>are not available.
>
>> Getting rid of HFS+ references
>> - in MacOSPlatformUtils.cpp, commented out static bool
>>gHasHFSPlusAPIs = false
>> - in MacOSPlatformUtils.cpp and MacOSPlatformUtils.hpp, removed all
>> code from which references FSRef or uses file routines added in OS9
>
>I miss the point of this. The code checks for the existance of HFS+
>and backs away from using it. You just need to weak link against the
>proper library?
With the headers I'm using, it wouldn't compile. Agreed, might have
been solved by me updating headers, but might be nice if the FSRef
code was wrapped in a conditional compile flag.
> > Missing CopyCStringToPascal() function
>> - copied this function from CGlue.c into a new .c file and added this
>> to the project
>
>You should be able to link in the static library "CarbonAccessors" in
>order to provide this routine.
OK, will try.
> > Misc
>> - in MacOSPlatformUtils.cpp, removed the static_cast from void*
>> XMLPlatformUtils::makeMutex() (due to compiler complaint about use of
>> incomplete struct definition)
>
>Okay, this is a compiler version issue.
I thought this was a strange one. It didn't want to static_cast to
void* with an incomplete class declaration, but it had no problem
doing a C-style implicit cast to same.
> > - in MacOSPlatformUtils.cpp, changed FSVolumeRefNum to equivalant
>> type short in bool XMLParsePathToFSSpec(const XMLCh* const pathName,
>> FSSpec& spec)
>
>Once again, you shouldn't have a change this...you just need to have
>the proper headers.
Again, probably true.
Thanks for looking into this, James.
Eric