Update libtagarray to 0.0.7#34
Conversation
|
I got errors on my Intel Mac. (gcc@12, python3.10) cheolhochoi@Home:~/clone/openqp$ openqp --run_tests other PyOQP: dftd4 is not available PyOQP: dftd4 is not available PyOQP: dftd4 is not available PyOQP: dftd4 is not available |
|
@karmachoi, did you see this error before this patch? It looks like a fail of OpenMPI |
I just recompiled this branch. I keep getting this issue. |
|
Do you see this error with main branch? |
No. It only occurs in the updated branch. |
|
I also get error of /opt/soft/install/binutils/2.37-GCCcore-11.2.0/bin/ld.gold: error: /bighome/cheolho.choi/clone/openqp/build/external/libtagarray/src/libtagarray-build-GNU/libtagarray.a(Utils.cpp.o): requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC from intel linux. |
- Build libtagarray static archives with PIC for Python extension linking - Copy only active tagarray dimensions when returning record shapes
|
Superseded. libtagarray has been promoted to a first-class project at Open-Quantum-Platform/tagarray and released as v1.0.0 (https://github.com/Open-Quantum-Platform/tagarray/releases/tag/v1.0.0). OpenQP is being re-pointed at that package (and migrated to the new |
* Migrate to Open-Quantum-Platform/tagarray v1.0.0 Re-point libtagarray at OQP/tagarray v1.0.0 and migrate all call sites off the removed 0.0.x API (reserve_data/remove_records/has_records/get_record_info/ get_status) to create/erase/contains/get + recordinfo count/ndims/dims and the TA_CONTAINER_GET_* macros. - external/CMakeLists.txt: URL -> OQP/tagarray v1.0.0 (+SHA), drop obsolete default-integer-shapes patch, add CMAKE_POSITION_INDEPENDENT_CODE. - tagarray_driver.F90 + c_interop.F90: wrapper/C-interop ported to v1.0.0. - 23 modules: one-call c%alloc_or_die; hf_energy create() for C-filled Fock; int2e int64-shape create() for nbf**4 ERI. Supersedes stale PR #34. Verified: liboqp links and H2 MRSF-CIS reproduces S0 = -1.1150793163 Ha exactly. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Address review: preserve input orbitals + ILP64 integer kind for libtagarray Codex review fixes (data erased by over-eager migration): - basis_projection: OQP::DM_A/E_MO_A/VEC_MO_A (and beta) are the converged initial-basis orbitals READ by corresponding_orbital_projection; the old reserve_data (no remove_records) preserved them. alloc_or_die overrides, so it erased the projection source. Revert those 6 tags to data_has_tags + tagarray_get_data (read, not reallocate). The *_tmp outputs stay alloc_or_die. - guess_json: the beta OQP::DM_B/E_MO_B/VEC_MO_B are loaded from the JSON guess and read by get_ab_initio_density for ROHF/UHF; read them, do not reallocate. ILP64 build fix (CI failure on -fdefault-integer-8 builds): - tagarray's c%alloc/alloc_or_die take default-INTEGER shapes and create takes a default-LOGICAL override; OpenQP promotes those to 8 bytes via add_compile_options(-fdefault-integer-8/-i8), which ExternalProject does not inherit, so libtagarray was built int4 -> alloc_or_die/override failed to resolve. Forward the same integer-8 flag to the libtagarray Fortran build so the kinds match (verified: the library builds cleanly under -fdefault-integer-8). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Migrate population_analysis + resp to tagarray v1.0.0 alloc_or_die These two modules came in from the main merge still using the removed reserve_data API (they store Mulliken/Lowdin/RESP atomic charges). Convert their single output-tag reserve_data + tagarray_get_data to the one-call alloc_or_die, matching the rest of the migration. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Fix wheel link: resolve dftd4->LAPACK static link order (undefined ssytri_) dftd4/multicharge/mctc-lib reference BLAS/LAPACK symbols (e.g. ssytri_) but are linked after the static liblapack/libblas archives. With a static NetLib build the linker has already passed those archives, so the objects are never pulled in and liboqp.so gets an undefined symbol that only fails at load time (import oqp in the wheel smoke). The gcc-build jobs miss it because they never load the library, and main slips through on its warm externals cache; a fresh rebuild (forced here by the tagarray version bump) exposes it. Wrap the dispersion libs together with LAPACK/BLAS in a RESCAN link group so the cross-references resolve regardless of order (NetLib static only; shared BLAS/LAPACK such as macOS Accelerate is unaffected). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Fix: don't use RESCAN link group on Apple (ld64 lacks --start-group) $<LINK_GROUP:RESCAN> emits --start-group/--end-group, which is a GNU ld feature; Apple's ld64 rejects it. A macOS + from-source-NetLib-static build (LIBLAPACK set on Apple) would therefore fail to link -- and Linux-only CI never catches it. ld64 resolves cross-archive references by a global symbol scan anyway, so Apple just needs the plain link. Gate the RESCAN group on NOT APPLE. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
3 participants
Closes #30
Most of changes are related to procedures renaming