Python 2.4.2 gcc 3.4.4 Solaris 8 build issues

["Martin v. Löwis"]

Holger Joukl wrote:
> Now, I am still not 100 % sure about what I need to do. I need 
> C++-extensions, but I do not want to link anything statically with 
> Python, i.e. everything will be dynamically imported extension 
> modules. I *think* I can build Python C-only, avoiding possible 
> runtime problems with C++-extensions that might have been built with 
> different C++ compilers.
> 
> Can anyony clear that up?

On Solaris 8, yes you don't need to link Python with a C++ compiler.
This is thanks the ELF's .init section.


> 2. We have some stuff in non-standard locations here. To build
> properly, I need to tell this to configure (using CXX, CPPFLAGS,
> LD_LIBRARY_PATH). Unfortunately, none of this > gets communicated to
> the setup.py step with its find_library_file() stuff, so it is also
> necessary to either modify setup.py or add a setup.cfg file.

Why do you say that? If you set CC before invoking configure,
it will get into Makefile, and from there into setup.py.
More generally: setup.py will take everything from Makefile,
so just check whether Makefile looks right.

As for LD_LIBRARY_PATH: If it is set when setup.py is running,
it will certainly apply. However, I really recommend to use
crle(8) instead:

  crle -u -l /opt/sfw/lib

Then, your users will never have to set LD_LIBRARY_PATH
for /opt/sfw/lib.

Alternatively, set LD_RUN_PATH or pass -Wl,-R/opt/sfw/lib to
the linking compiler: this will encode the path into the
binary, so you still don't need to set LD_LIBRARY_PATH at
runtime.

> ?? Is this a known problem on Solaris?

It's known to me :-) I had not time to investigate it further.

> Der Inhalt dieser E-Mail ist vertraulich.

So ein Quatsch. Selbst Google hat jetzt eine Kopie dieser Mail:

http://tinyurl.com/8qghw

Regards,
Martin