Eric N. Vander Weele <eri...@gmail.com> added the comment:
> This is horrible and completely wrong. I'm not an expert in AIX and xlc, by any means. I would greatly appreciate your help to better understand so I can see the problem in the way you are to figure the best approach I can take. My primary motivation was to simplify/homogenize the mechanism by which Python C/C++ extensions are built. For background, I have Python applications and libraries that need to run on Linux, Solaris, and AIX. One of the challenges we ran into was how and when symbol resolution occurs, which is fundamentally different in AIX. > Python does not require dynamic linking. I understand Python does not require dynamic linking. However, the problem I am running into is how this should work/behave for Python C/C++ extensions, which are imported (loaded) at runtime of a Python application. Maybe this is where I have a fundamental misunderstanding, but it led me to believe that in AIX this should behave similarly to SVR4/Linux. When scouring how Python interplays with AIX for building Python C/C++ extensions, this problem piqued my interest. When conducting my self-research, I came across http://download.boulder.ibm.com/ibmdl/pub/software/dw/aix/es-aix_ll.pdf, which helped me in understanding the differences between dynamic loading run-time linking. Thus, I went down the path of run-time linking with the '-G' flag, which appeared similar to what was done in Python for other operating systems. > This simply is masking a symptom in a naive and incorrect manner. This is leading up to my misunderstanding of what I was observing during my initial investigation of what was going on. I'll need to revisit the symptom being observed, but I vaguely recall missing symbols when building Python C/C++ extensions when the interpreter is configured with '--enable-shared'. Let me go back, undo the patch I have, and recreate the symptom/issue that was observed. > Use of runtime linking causes many internal changes to the behavior of AIX > applications, severely affecting performance and potentially causing overflow > of data structures. I'm really curious about this one. What internal changes, performance concerns, and overflow of data structures could occur? Luckily, I have observed nor experienced anything egregiously negative, thus far. Understanding these concerns will help bolster my understanding. > I absolutely will not allow Python to go down this path and introduce this > type of mistake. No worries. I'm trying to solve a problem and appeared to have gone down an incorrect path. Being able to better understand what the desired expectation is for Python and associated C/C++ extensions, will help guide me to focus where the misunderstanding is and to redirect focus on where the problem is that needs to be addressed. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37690> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
