[ET Trac] [Einstein Toolkit] #1717: hwloc: lnuma & lltdl *really* required?

[Einstein Toolkit]

#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.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1717#comment:12>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit