Open eli-schwartz opened 2 months ago
Thanks for the issue report. All the examples above (which one exception for Python) appear to be from the Fortran interface. Cantera using mismatched types for integers in Fortran is something that is known (it may actually be a deliberate hack). Can you confirm that the
build/python/cantera/_onedim.cpp:5467:3: note: a different type is defined in another translation unit
5467 | } __pyx_mstate;
| ^
build/python/cantera/_cantera.cpp:2265:13: note: the first difference of corresponding definitions is field ‘__pyx_n_s_’
2265 | PyObject *__pyx_n_s_;
| ^
build/python/cantera/_onedim.cpp:4614:17: note: a field with different name is defined in another translation unit
4614 | PyTypeObject *__pyx_GeneratorType;
|
block is the only one remaining if you compile without Fortran support? I.e. using the f90_interface=n
option?
All the examples above (which one exception for Python) appear to be from the Fortran interface. Cantera using mismatched types for integers in Fortran is something that is known (it may actually be a deliberate hack).
Yeah, it does seem to show up in a lot of packages. :)
Sometimes they do get fixed after my report though -- in at least one case, that involved adopting the use of Fortran 2003 "BIND(C)". I don't really understand the details very well since I don't know Fortran. :( But e.g. the GCC docs talk about it as "the" facility for ensuring interoperability between C and Fortran interfaces when producing shared libraries. Maybe that's an option here?
$ USE=-fortran emerge -1 cantera
[...]
x86_64-pc-linux-gnu-g++ -o build/python/cantera/_cantera.cpython-312-x86_64-linux-gnu.so -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wl,--defsym=__gentoo_check_ldflags__=0 -pthread -shared -Wl,-rpath=/usr/lib64/cantera -Wl,-rpath=/usr/lib build/temp-py/_cantera.os build/temp-py/_onedim.os build/temp-py/_utils.os build/temp-py/constants.os build/temp-py/delegator.os build/temp-py/func1.os build/temp-py/kinetics.os build/temp-py/mixture.os build/temp-py/preconditioners.os build/temp-py/reaction.os build/temp-py/reactionpath.os build/temp-py/reactor.os build/temp-py/solutionbase.os build/temp-py/speciesthermo.os build/temp-py/thermo.os build/temp-py/transport.os build/temp-py/units.os build/temp-py/yamlwriter.os src/extensions/PythonExtensionManager.os -Lbuild/lib -L/usr/lib64/cantera -lcantera -lfmt -lgomp
build/python/cantera/_cantera.cpp:2340:3: error: type ‘struct __pyx_mstate’ violates the C++ One Definition Rule [-Werror=odr]
2340 | } __pyx_mstate;
| ^
build/python/cantera/_onedim.cpp:5467:3: note: a different type is defined in another translation unit
5467 | } __pyx_mstate;
| ^
build/python/cantera/_cantera.cpp:2265:13: note: the first difference of corresponding definitions is field ‘__pyx_n_s_’
2265 | PyObject *__pyx_n_s_;
| ^
build/python/cantera/_onedim.cpp:4614:17: note: a field with different name is defined in another translation unit
4614 | PyTypeObject *__pyx_GeneratorType;
| ^
lto1: some warnings being treated as errors
lto-wrapper: fatal error: x86_64-pc-linux-gnu-g++ returned 1 exit status
compilation terminated.
/usr/libexec/gcc/x86_64-pc-linux-gnu/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
scons: *** [build/python/cantera/_cantera.cpython-312-x86_64-linux-gnu.so] Error 1
scons: building terminated because of errors.
Can you confirm that the [...] block is the only one remaining if you compile without Fortran support? I.e. using the
f90_interface=n
option?
Yes, as long as the build is without fortran support it is just the one error.
Thanks for confirming!
The warnings about __pyx_mstate
are related to the somewhat unconventional way that we use Cython. To reduce compilation time, we compile multiple separate .pyx
files, which Cython expects will end up as their own separate extension module .so
, but we instead combine everything into a single extension module.
All usage of this struct seems to be guarded by the CYTHON_USE_MODULE_STATE
macro, which is by default defined as 0, and is described in the documentation as an experimental feature. I don't know if this option will perhaps become a default at some point in the future, or what it would take to support our use case. Perhaps that's a question for the Cython devs.
The warnings about
__pyx_mstate
are related to the somewhat unconventional way that we use Cython. To reduce compilation time, we compile multiple separate.pyx
files, which Cython expects will end up as their own separate extension module.so
, but we instead combine everything into a single extension module.
That is a very interesting use case which does seem valuable. Another possibility from the cython side could be if they offered the ability to simply allow producing "_part1.cpp", "_part2.cpp" files when processing pyx files that produce especially large generated outputs. I would probably open a feature request if I were you. :)
Problem description
I tried to build with the following *FLAGS to optimize the build:
-flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing
Link-Time Optimization is a massively global compiler optimization pass which is pretty handy for producing faster executables. It also has the interesting property that because the compiler does whole-program analysis using bytecode, it can save type information and perform error checks that it normally doesn’t have enough insight for. In particular, checking for ODR issues and checking function type signature mismatches.
Note that all the -Werror=* flags are used to help detect cases where the compiler tries to optimize by assuming UB cannot exist in the source code -- if it does exist, ordinarily the code would be miscompiled, and this says to make the miscompilation a fatal error.
I got this error:
Steps to reproduce
Compile with GCC.
Include the following CFLAGS / CXXFLAGS / LDFLAGS:
-flto -Werror=odr -Werror=lto-type-mismatch
System information
Attachments
Full build log of the failure: build.log