[lmi] Mystic fix for so-attributes linker error

[Greg Chicares]

[Vadim--The mysticity is my only problem; maybe you can explain it?]

I run this test less often than I should, and today it failed when I
ran an extended series of tests in preparation for declaring a release
candidate:

/opt/lmi/src/lmi[0]$make $coefficiency all build_type=so_test 
USE_SO_ATTRIBUTES=1
...
skeleton.o: In function `~ce_skin_name':
/opt/lmi/src/lmi/ce_skin_name.hpp:46: undefined reference to `vtable for 
ce_skin_name'
skeleton.o: In function `~datum_string':
/opt/lmi/src/lmi/datum_string.hpp:44: undefined reference to `vtable for 
datum_string'
/opt/lmi/src/lmi/datum_string.hpp:44: undefined reference to `vtable for 
datum_string'
collect2: error: ld returned 1 exit status
/opt/lmi/src/lmi/workhorse.make:794: recipe for target 'skeleton.dll' failed

I tried some quick experimental changes to the headers mentioned in
those error messages and their corresponding '.cpp' files, but didn't
get lucky fast enough, so I looked here:
  https://gcc.gnu.org/faq.html#vtables
But that didn't seem to help, so I instructed my machine to solve the
problem by brute force[0]. (It took less than five minutes to decide
that 84cd25c was the problem.)

The headers cited in the error messages weren't implicated in that
"first bad commit", but 'ce_skin_name' isn't used in many places:

/opt/lmi/src/lmi[0]$grep --files-with-matches ce_skin_name *.?pp      
ce_skin_name.cpp
ce_skin_name.hpp
preferences_model.hpp

and of those three files, only the last one was changed in the bad
commit, so, there being no git command to revert selected files...

http://git.661346.n2.nabble.com/Revert-a-single-commit-in-a-single-file-td6064050.html
| I am afraid that it would lead to encouraging people to record a
| horribly broken history

...I found a command to do it anyway:

/opt/lmi/src/lmi[0]$for z in preferences_model.?pp; do git show 84cd25c:$z > 
$z; done

and with that change everything "worked"--now the test:

/opt/lmi/src/lmi[0]$make $coefficiency all build_type=so_test 
USE_SO_ATTRIBUTES=1 2>&1 |less -S

is clean.

Vadim--do you have any idea what's going on here, and how I might
possibly avoid such problems in the future? (Running this 'so_test'
more often would catch problems sooner, but I'm looking for a way to
forestall them.) All I can guess is that the vtable doesn't get laid
down in the same way for an explicitly-defaulted dtor. Referring back
to the gcc link above:

  https://gcc.gnu.org/faq.html#vtables
| The solution is to ensure that all virtual methods that are not pure
| are defined. Note that a destructor must be defined even if it is
| declared pure-virtual.

the (explicitly-defaulted) dtor was defined; what "fixed" the problem
was moving it out of line.

---------

[0] "solve the problem by brute force":

git bisect start
git bisect bad

I'm certain that this worked on the first commit of 2017, so I
tested that and, seeing success, declared it "good":

git checkout 76fc872f5c76b2212c2a22b4570782c771fbb443
make $coefficiency all build_type=so_test USE_SO_ATTRIBUTES=1 >/dev/null 2>&1
git bisect good

time git bisect run make $coefficiency all build_type=so_test 
USE_SO_ATTRIBUTES=1 >/dev/null 2>&1

/opt/lmi/src/lmi[0]$git bisect log                                   
git bisect start
# bad: [220b420c9be1658262e0ebc613dff2855bdfd942] Suggest ideas for future 
development
git bisect bad 220b420c9be1658262e0ebc613dff2855bdfd942
# good: [76fc872f5c76b2212c2a22b4570782c771fbb443] Update copyright notices
git bisect good 76fc872f5c76b2212c2a22b4570782c771fbb443
# good: [b860e42705dae7a8054f55071576a52d4123732d] Rearrange member-function 
implementations in header order
git bisect good b860e42705dae7a8054f55071576a52d4123732d
# good: [633f286dd0a150861a17009c764716811ebd35d3] Refactor to prepare for 
improvements
git bisect good 633f286dd0a150861a17009c764716811ebd35d3
# good: [a682d11d629486b86e469cd7b70e8842a51b06d9] Improve concinnity
git bisect good a682d11d629486b86e469cd7b70e8842a51b06d9
# good: [cd5f84c6b51d9286f2ce1b300789cddff3908024] Do not specify default map 
comparator explicitly
git bisect good cd5f84c6b51d9286f2ce1b300789cddff3908024
# bad: [b05b68201a064b22cec6ec159e7372337a5fa1f8] Write explicitly-defaulted 
dtor outside class defn where necessary
git bisect bad b05b68201a064b22cec6ec159e7372337a5fa1f8
# bad: [9b3d0f1134744e6fe7e4bba8ffa5e8a655f7648b] Write explicitly-defaulted 
[cd]tors inline, in class defn
git bisect bad 9b3d0f1134744e6fe7e4bba8ffa5e8a655f7648b
# good: [83b3c835300d5bc515a99db447bdefdacf615dca] Rename fatal_error()
git bisect good 83b3c835300d5bc515a99db447bdefdacf615dca
# bad: [ca6e663c7c4f7450d717e6a6298a006caed71450] Write explicitly-defaulted 
dtors inline, in class defn
git bisect bad ca6e663c7c4f7450d717e6a6298a006caed71450
# good: [fd2c4e65d8172637b37a4dc8fb7edcf01a0b1b58] Replace lmi::uncopyable with 
"=delete" special member functions
git bisect good fd2c4e65d8172637b37a4dc8fb7edcf01a0b1b58
# first bad commit: [ca6e663c7c4f7450d717e6a6298a006caed71450] Write 
explicitly-defaulted dtors inline, in class defn

[It bothered me to think that it took eleven steps to search 326
commits when it should have taken no more than nine...but the
first two are simply the good and bad commits I identified,
so all is well.]