>>Yes! In fact, when I compile without "-ansi strict",
>>the object file refers _HFSDispatch() instead of
>>PBGETCATINFOSYNC() (I've checked that by DumpObj),
>>as you shown. But when I compile with "-ansi strict",
>>the problem occurs. Did you compiled with "-ansi strict"?
>I probably didn't, but I have now, and I see the "problem".
>This is actually expected behavior. '-ansi strict' disallows
>any Apple extensions to the ANSI standard that are used
>throughout the toolbox interfaces. So, inline constructs
>such as the ones used for the File Manager calls are ignored,
>and you end up with direct function references to functions
>that don't actually exist in the libraries.
Ah, Great Thanks. I've already checked SC manual roughly, but
I was not aware that Apple extended syntax is required to
preprocess ToolBox functions properly. Now I understand as:
some ToolBox API require Apple's extended syntax which "-ansi
strict" disables, so some functions are not properly preprocessed
in "-ansi strict" mode. As a result of insufficient preprocess,
the derived source refers the function which is something like
a macro function and does not exist in Interface.o. So I receive
undefined PBGETCATINFOSYNC() error.
>To allow the Apple extensions to work as you'd expect, but still
>force the compiler to complain about other non-ANSI constructs,
>use '-ansi on' instead of '-ansi strict'.