Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#1597 closed defect (wontfix)

Python NG bindings do not inherit global compiler settings

Reported by: dron Owned by: hobu
Priority: normal Milestone: 1.5.0
Component: PythonBindings Version: unspecified
Severity: normal Keywords:
Cc: warmerdam

Description

Python bindings should inherit compiler settings from the main configuration file (GDALmake.opt on Unix). When I am changing compiler via standard configure options Python modules should be built with the same compiler, e.g., if I do

$ CC=gcc-2.95 CXX=gcc-2.95 ./configure
$ make

GDAL library will be built using specified gcc-2.95 compiler, but Python bindings will be built with gcc, which can be a different one resulting in binary incompatibility.

Change History (4)

comment:1 by warmerdam, 17 years ago

Cc: warmerdam added
Owner: changed from warmerdam to hobu

Andrey,

I think this is contrary to how python building with setuptools works, but I'll turn this over to Howard to discuss with you.

comment:2 by hobu, 17 years ago

Andrey,

Yes, this is contrary to how distutils/setuptools works. These Python build mechanisms bend over backwards to build extensions with the version of the compiler that built Python itself. Distutils has some private classes that monkey with the compiler, and could maybe be made to use the compiler given from a user instead of what it thinks Python's compiler was. I imagine this kind of monkey patching would be brittle though.

I have recently fixed GDALColorTable to use the C API (#1578), and I don't think there are any more SWIG stuff that use C++ linkage. I don't know if that is related to your issue, but I think it would clear up any linkage issues between GDAL built with 2.95 and Python built with 3.4.3, for example. Unless I'm totally wrong, of course :)

Howard

comment:3 by hobu, 17 years ago

Resolution: wontfix
Status: newclosed

comment:4 by dron, 17 years ago

It there are no more C++ linkage in the bindings it is fine with me. C++ incompatibility was the actual problem here.

Best regards, Andrey

Note: See TracTickets for help on using tickets.