Mr. Verveer wrote: "I recently installed this version and it unfortunately broke my own extension C code. I found that my code did not link properly anymore because of the addition of the static declaration tot the API pointer (as noted in changes.txt). Since my extensions consist of several source files, this led to problems when importing my extensions. If I understand correctly, the addition of the static keyword means that the import_array() function can now only be used by extensions that are defined in a single C source file. I can easily work around this problem, by defining my own api pointer, and using a modified import_array() in my code, but I thought I should draw your attention to this problem in any case. Maybe another solution can be found that does not need this pointer to be declared static?" -- I tried this change to see whether it had any bad consequences. It did not appear to have bad consequences in that Numpy itself and all its packages built ok, and we were formerly not following the instructions in the Python documentation and now we are. And, OS-X now worked. So far so good. If I understand you correctly, this does not work properly if the extension is built in pieces. I think I see why. (Frankly, linking and dynamic loading are not something I know much about; as a user I just flounder around.) This all started because of the need to have access to the C API of one dynamic extension from another. Is there a way of institutionalizing your work-around so that others can use it? Frankly, I'm out of ideas. The community is going to have to rescue me on this one. Paul P.S. Wait. I have an idea. Konrad was the one who put all this in. He should be punished for his good deed...(:->