Alan W. Irwin writes: > >From later e-mail you appear to have solved this by dropping linking of > python libraries, but that may just hide the problem until later when > you actually try and execute the code.
Possibly. I haven't gotten as far as testing it yet. But, btw, if you study how the dynlloadable modules are built during the python build process, they don't link to libpython. > Just out of curiosity, what happens if you follow the above instructions > (or at least my interpretation of them), that is, build your private > (static library version) of python with the -fPIC compiler option? If you configure python --enable-shared, then everything gets compiled with -fPIC. But the python build seems to lack adequate rpath rigor, which is why the resulting executable doesn't seem to get the right sys.path. It winds up linking in at run time, the libpython from /usr/lib64, and I think that explains the bizarre sys.path. Presumably I could avoid this with an appropriate LD_LIBRARY_PATH setting, but I didn't think to try that at the time, and I've kinda moved past that point now. If you don't configure python with --enable-shared, then the main code body is compiled sans -fPIC, but the dynloadable modules are compiled with -fPIC (and then not linked to libpython.a). So, yes, there are more questions to ask/answer here. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
