Error with latest version of docker file when linking a deal.II executable

dealii / docker-files

Docker files to automatically build docker-images

10 stars 14 forks source link

Error with latest version of docker file when linking a deal.II executable #35

Closed blaisb closed 2 years ago

blaisb commented 2 years ago

Dear all, There seems to be an issue with the latest version of the docker image for deal.II master. Whenever it links an executable, the following error is thrown:

/usr/local/lib/libdeal_II.so.10.0.0-pre: error: undefined reference to 'setupterm'
/usr/local/lib/libdeal_II.so.10.0.0-pre: error: undefined reference to 'tigetnum'
/usr/local/lib/libdeal_II.so.10.0.0-pre: error: undefined reference to 'set_curterm'
/usr/local/lib/libdeal_II.so.10.0.0-pre: error: undefined reference to 'del_curterm'

This just appeared out of the blue in the last 2-3 days, so something recent with the image must have brought this. Any clues? Thanks :)!

jppelteret commented 2 years ago

Seems related:

It seems that some dependency doesn't link against -ltinfo or -lcurses, so we might have to do this ourselves?

peterrum commented 2 years ago

This affects all out projects as well (CC @mschreter, @nfehn, @kronbichler, @slfuchs).

luca-heltai commented 2 years ago

I have been using the latest docker image, with no issues. :| This seems very strange to me.

Are you using clang to compile, or gcc?

luca-heltai commented 2 years ago

Ok I could reproduce this with the latest merge. I reverted the dependencies to use symengine without llvm support (for the moment). @jppelteret, do you know how to workaround this? #34 is the issue. We might need to add some additional compile flags to fix the issues.

jppelteret commented 2 years ago

@luca-heltai I've never encountered this issue, so other than the extra linker flags -ltinfo or -lcurses I don't have any further suggestions. LLVM pops up frequently in a search for error: undefined reference to 'setupterm', but since ncurses is transitively included by spack, and I then get spack to set up my environment, I think that I've avoided any potential issues here. Can you simply export those extra linker flags in Docker, or add them to the SymEngine build?

luca-heltai commented 2 years ago

Adding LDFLAGS="-ltinfo -lcurse" to the env fixed this. I'm trying the option of adding the flags to symengine build now (this seems a bit cleaner), and recompiling master image with the new version. If this works, I'll open a PR.

luca-heltai commented 2 years ago

A little more investigation produced the following result:

building symengine with shared libs instead of static libs seems to have fixed the issue (no linking with tinfo and curses seems to be required by the shared version of the libraries)
I've just re-built the dependencies and the latest master, and pushed them to dockerhub. Could you check that these images work for you? @blaisb, @peterrum? If they do, I'll merge

bangerth commented 2 years ago

The most significant semantic difference between static and shared libs is that a static library is really just something like a tar file of the different .o files. It does not store any semantic information such as other libraries it depends on, and so it is not a mistake that the static lib doesn't say that you need to link against tinfo and curses: There is simply no way to say that. You have to remember that and specify it on the command line by hand whenever you link with that static library.

Shared libraries, on the other hand, can carry this kind of information and if they don't, then that's a bug.

peterrum commented 2 years ago

If they do, I'll merge

I'll report tomorrow the results of the nightly tests.

peterrum commented 2 years ago

Looks good :+1: