![](https://secure.gravatar.com/avatar/56475d2e8acb48b4308f609982f94440.jpg?s=120&d=mm&r=g)
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...(:->
![](https://secure.gravatar.com/avatar/a53ea657e812241a1162060860f698c4.jpg?s=120&d=mm&r=g)
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
True. That's exactly what I pointed out in a previous message in this list.
defining my own api pointer, and using a modified import_array() in my code,
That seems to me the preferred solution.
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
And those instructions mention the static keyword for a good reason: without it there are problems not only with portability, but also with static linking of extension modules.
Is there a way of institutionalizing your work-around so that others can use it?
I thought about providing a general solution right in the header files. The problem is the generation of a unique symbol by preprocessor tricks, perhaps somehow based on the module name. I don't see how this can be done. On the other hand, if we accept that the extension module programmer has to supply a unique symbol, then it is even easy. This would only be necessary for multi-file extension modules. Does that seem like a good solution?
Wait. I have an idea. Konrad was the one who put all this in. He should be punished for his good deed...(:->
I am even thinking of punishing myself by imposing extra work on me! ;-) Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
![](https://secure.gravatar.com/avatar/a2df05e4328935f78d98a922d1cf9af6.jpg?s=120&d=mm&r=g)
On Wednesday 02 May 2001 19:39, Konrad Hinsen wrote:
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
True. That's exactly what I pointed out in a previous message in this list.
defining my own api pointer, and using a modified import_array() in my code,
That seems to me the preferred solution.
But this will still fail on OSX, I guess.
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
And those instructions mention the static keyword for a good reason: without it there are problems not only with portability, but also with static linking of extension modules.
Is there a way of institutionalizing your work-around so that others can use it?
I thought about providing a general solution right in the header files. The problem is the generation of a unique symbol by preprocessor tricks, perhaps somehow based on the module name. I don't see how this can be done.
On the other hand, if we accept that the extension module programmer has to supply a unique symbol, then it is even easy. This would only be necessary for multi-file extension modules. Does that seem like a good solution?
That sounds very good. I don't mind providing a symbol name for the pointer myself.
Wait. I have an idea. Konrad was the one who put all this in. He should be punished for his good deed...(:->
I am even thinking of punishing myself by imposing extra work on me! ;-)
Konrad.
-- Dr. Peter J. Verveer Bastiaens Group Cell Biology and Cell Biophysics Programme EMBL Meyerhofstrasse 1 D-69117 Heidelberg Germany Tel. : +49 6221 387245 Fax : +49 6221 387242 Email: Peter.Verveer@embl-heidelberg.de
![](https://secure.gravatar.com/avatar/a53ea657e812241a1162060860f698c4.jpg?s=120&d=mm&r=g)
That seems to me the preferred solution.
But this will still fail on OSX, I guess.
Not necessarily. The API pointer just has to be passed between the source code modules in a global variable whose name is highly unlikely to be used somewhere else.
That sounds very good. I don't mind providing a symbol name for the pointer myself.
Good to hear. Is there anyone who would oppose this? Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
participants (3)
-
Konrad Hinsen
-
Paul F. Dubois
-
Peter Verveer