Closed yurivict closed 1 year ago
@yurivict You will need to report issues with hyperdeal on the hyperdeal github https://github.com/hyperdeal/hyperdeal There is really not much we, as deal.II project, can do to help you here. (Short of that the hyperdeal developers and deal.II principal developers have a nonzero overlap).
But I want to respond to your comment in detail.
No, what you are saying is not correct.
For C++ dependencies in particular, as we have many, you really need the full transitive link interface. This is because header files of direct dependencies can and will result in new object code that might link to symbols of a dependent, indirect library. The consensus reached around 15 years ago is that not providing the library for linking on the command line is an error. So, depending on how strict your linker is you will encounter errors like
.../path/to/direct/dependency: error adding symbols: DSO missing from command line
Therefore, in order to link correctly, we really have to provide the full, transitive link interface. This is a decade old problem. You can find informative summaries here: [1,2].
I agree that in an ideal world we would not need to provide the full transitive link interface because we make sure that our user-side included header files do not introduce new symbol (and therefore) object dependencies. But frankly, this is not a concern for any of our many dependencies, and also not for us. And with a code base of about a 0.75 million user visible lines of code this is also not going to happen.
Just have a look at to what length the QT project had to go to make sanitized, API and ABI stable header files a possibility in Qt 4... And such API and ABI stability are goals that are very orthogonal to what scientific projects and libraries typically care about. (We are happy with our 99% API stability we manage to achieve for a given release.)
You can try to compile with -Wl,--as-needed
in order to minimize the number of dependencies the library itself is linked against. But this will not allow you to ignore these library dependencies in the final ports package - in order to actually use deal.II afterwards you will need to install all direct dependencies as "-dev" package (in Debian speak), meaning with full headers and pkgconfig/cmake configuration. In particular:
When packaging deal.II I suggest to
DEAL_II_ALLOW_AUTOCONFIGURATION
to OFF
and explicitly hand select dependencies[1] https://fedoraproject.org/wiki/UnderstandingDSOLinkChange [2] https://flameeyes.blog/2010/11/26/it-s-not-all-gold-that-shines-why-underlinking-is-a-bad-thing/?utm_source=blogdoteu&utm_medium=referral&utm_campaign=permanent [3] https://packages.debian.org/trixie/libdeal.ii-dev, https://packages.debian.org/source/trixie/deal.ii [4] https://salsa.debian.org/science-team/deal.ii/-/blob/master/debian/control (have a look at the "build dependencies" but also the regular dependencies for the "-dev" package. The binary itself only depends on the libraries it explicitly links against).
For example, the "hyperdeal" library.
When it is built as a shared library libhyperdeal.so it is linked with many or all OpenCascade and sundials libraries:
It isn't necessary to link shared libraries with all dependency libraries. This is only necessary for static libraries. In case of shared libraries this only induces unnecessary inter-package dependencies.
hypedreal uses DEAL_II_xx macros like:
which likely cause these redundant dependencies.