#566 Update python-steps to latest release (4.1.1)
Opened 9 months ago by gui1ty. Modified 6 months ago

It seems I'm tripping with every step I take (pun intended) trying to update python-steps to the latest release.

The latest issue, which is beyond my knowledge of compiler flags and linking and the reason for opening this ticket, is:

Linking CXX executable cmTC_e7825

/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_e7825.dir/link.txt
--verbose=1

/usr/bin/g++ -DGTEST_HAS_PTHREAD=1 -lgtest_main -lgtest
-I/usr/include/sundials2 -Wl,-z,relro -Wl,--as-needed -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1
-specs=/usr/lib/rpm/redhat/redhat-package-notes
CMakeFiles/cmTC_e7825.dir/sundials_get_version.cpp.o -o cmTC_e7825

/usr/bin/ld: CMakeFiles/cmTC_e7825.dir/sundials_get_version.cpp.o:
relocation R_X86_64_32 against `.rodata' can not be used when making a PIE
object; recompile with -fPIE

/usr/bin/ld: failed to set dynamic section sizes: bad value

collect2: error: ld returned 1 exit status

gmake[1]: *** [CMakeFiles/cmTC_e7825.dir/build.make:99: cmTC_e7825] Error 1

I pushed my progress thus far to my fork.

Since sandi-omega-h is not yet available in Fedora (package is in review), you can do the following to reproduce:

  1. fedpkg clone python-steps && cd python-steps
  2. git remote add gui1ty https://src.fedoraproject.org/forks/gui1ty/rpms/python-steps.git
  3. git fetch gui1ty
  4. git checkout update
  5. copr mock-config gui1ty/neuro-sig fedora-rawhide-x86_64 > ~/.config/mock/neuro-sig-fedora-rawhide.cfg
  6. fedpkg --release rawhide mockbuild --root neuro-sig-fedora-rawhide --no-cleanup-after

Even though we are several releases further, the upstream issue raised during a previous attempt of unbundling SUNDIALS remains open. Maybe we just have to use the bundled version. I attempted to use the system version to a) see if this is working now and b) because upstream now tries to download SUNDIALS directly, which is not gonna work in our build environment.


/usr/bin/ld: CMakeFiles/cmTC_e7825.dir/sundials_get_version.cpp.o:
relocation R_X86_64_32 against `.rodata' can not be used when making a PIE
object; recompile with -fPIE

still feels like rpath related issues. I'll take a look and work off your branch

Looks like the sources weren’t uploaded to the lookaside cache yet:

Downloading STEPS-4.1.1.tar.gz
######################################################################## 100.0%
Remove downloaded invalid file /home/ben/fedora/neuro-sig/python-steps/STEPS-4.1.1.tar.gz
Could not execute mockbuild: ('Could not download sources: %s', DownloadError('Server returned status code 404'))

spectool -g works, so I went ahead and ran fedpkg new-sources STEPS-4.1.1.tar.gz hpc-coding-conventions-e008ccc716f1bd15a20a2f43b8b3211fa47cb7bc.tar.gz.

However, I got a different hash for hpc-coding-conventions-e008ccc716f1bd15a20a2f43b8b3211fa47cb7bc.tar.gz than the one already in sources, so you’ll still have to look into that yourself and run fedpkg new-sources again.

Maybe I’m doing something wrong. I see:

-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:18 (message):
  Submodules do not seem to be initialized.  Please run 'git submodule update
  --init --recursive'


-- Configuring incomplete, errors occurred!

However, I got a different hash for hpc-coding-conventions-e008ccc716f1bd15a20a2f43b8b3211fa47cb7bc.tar.gz than the one already in sources, so you’ll still have to look into that yourself and run fedpkg new-sources again.

Ah, I remember getting the hpc tarball and playing around with it since I wanted to avoid packaging it. I figured out the URL later and added it to the spec file. It turns out my version also had the .git/ directory in it and was unpacking into hpc-coding-conventions/ (no git hash in the directory name). I may have created that archive myself.

I have uploaded the tarball the URL refers to now and made a change to the spec file, so it works with that tarball as well. Both, fedpkg sources and spectool -g will now download the same file. Re-running the steps (I fixed the mistakes in the instructions) now gets me to the error I have described. Apologies for all the fuzz. I should probably train myself to take notes, so I can retrace my steps (no pun intended this time) more easily.

I'm on the verge of giving up on STEPS. It does my head in. Let me summarize the state of affairs.

All of above no longer applies. In my fork I attempted to unbundle sundials and use the system provided sundials2 compat package. That package is now retired in rawhide and f40. Thus, my attempt of unbundling can no longer succeed.

The system provided sundials is at version 6.x (rawhide and f40), which is not supported by STEPS. They support versions 2.6...3.9.9, but it appears to be no longer bundled in the source tarball. Instead they attempt to download version 3.2.1 during cmake configuration.

I tried with the system provided sundials anyway to see how far I would get. But before even running into issues regarding sundials all sorts of other issues kept popping up. The most annoying, for which I haven't found a solution or workaround, is the unit tests requiring <mpi.h> in the serial build. That is USE_MPI bools is set too false, but some test still wants to #include <mpi.h>.

I believe that issue won't go away even when switching back to bundling sundials. I may still attempt that. But for the moment I need to step away from STEPS (pun intended) for the sake of my own well-being.

https://github.com/CNS-OIST/STEPS/issues/23#issuecomment-1978113492

Upstream says they now support sundials 6.7 in the 5.x releases. I'll test that branch out and see how it goes. Thanks for all your work on this @gui1ty .

Metadata Update from @ankursinha:
- Issue assigned to ankursinha (was: gui1ty)

6 months ago

I wasn't even aware of that discussion. Or I did stumble on it and fell down a rabbit hole on the next step. These puns are just like a shooting alley. All lined up, waiting to be hit. :laughing:

You should be able to carry on from my fork, if you like. You just need to adjust the package name for sundials and you will still need sandia-omega-h, I believe. That's available in Copr pending review.

Log in to comment on this ticket.

Metadata