#1717: hwloc: lnuma & lltdl *really* required? ------------------------------------+--------------------------------------- Reporter: zachetie@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by eschnett):
As a general rule, we don't want to have work-arounds for particular systems in Cactus since this is very fragile. Over time, these work- arounds accumulate, and in the end no one remembers why somethings are done in a particular and very complex way. Sometimes we find comments about systems that no one even knows any more. For example, do you know why the C++ compiler on OSF systems requires the option "-noimplicit_include"? Does anybody even know what OSF is, without resorting to Google? (Hint: It is a version of Unix.) Apparently this option was introduced in 1999... I'm quite sure that the respective logic can be deleted and no one will ever notice, but no one has time to deal with these kinds of clean-ups because, sometimes, these work-arounds have subtle side-effects that break things when they are removed.
As I mentioned before, it is very easy (a one-line addition) to update the option list for your machine to avoid this problem. Also, since your system seems broken, you'd have to explain why you cannot correct your install, and why you think that modifying Cactus instead is a better idea.
However, you raise the questions whether Cactus should be linked statically or dynamically by default. These days, we tend to like static linking because (a) disk space usage is not really a concern, and (b) this means that executables are more independent once created. If you have a dynamically linked executable and then uninstall a certain library, it may break. This is an issue on supercomputers where production runs may take weeks or months, and where someone may have installed a library into his/her home directory and others are then using it. Once an executable is broken this way, it is very difficult (if impossible) to repair it. Static linking avoids this issue.
As a bonus, static linking also uncovers errors (duplicate symbols) that may go undetected with dynamic linking.