Christopher James Huff <chr### [at] maccom> wrote:

> Do you have in-depth experience 
> with C, C++, and Carbon? It is unlikely someone unfamiliar with the 
> language, API, or source code will be able to fix anything before the
> maintainer of the software does.

Talking about that, and although it is hard to tell if it is the source
of POV-Ray's current problem, there was a significant change with
CarbonLib verion 1.6 in the way CarbonLib handles re-exporting imported
System APIs. From "CarbonLib 1.6 Tech Note":

" Previous versions of CarbonLib weak-linked against all of the system
libraries that provided APIs which were re-exported from CarbonLib.
CarbonLib 1.6 uses a new lazy loading system for many of these
libraries; instead of weak-linking the library, CarbonLib provides a
glue function that loads the library when an API from the library is
first called. This provides a significant reduction in memory usage in
applications that do not use all of the lazily loaded libraries, and
also a significant improvement in application launch time, especially on
older hardware.

NOTE: the lazy loading feature causes a significant change in how
applications should test for the availability of APIs. Because CarbonLib
is now providing glue for APIs that were previously weak-linked, the
t-vectors exported from CarbonLib for these APIs will be non-NULL even
on system software that does not have the library in question. As
always, we recommend using Gestalt to check for the presence of a system
software library. Some libraries do not have a Gestalt selector; in
these cases, you may need to use GetSharedLibrary to check for the
presence of the library."


Stephane.

Post a reply to this message