[Scons-users] Versioned Shared Library Issues

[Russell, J.J.]

I am using the version shared libraries in 2.3.1 and having two problems; 
  i) the library getting rebuilt when it shouldn’t
 ii) improper 'clean’’ when not building the library in a ’standard’ directory. 

I did some investigative work on the second issue and see the origins of the problem, but was unable to trace the first.


I) LIBRARY UNNECESSARILY GETTING REBUILT

— Here’s the build file
SharedLibrary ("hello_msg.c",  SHLIBVERSION = ‘1.2.3')


—- Here’s original shareable build

> scons-2.3.1 -Q

gcc -o hello_msg.os -c -fPIC hello_msg.c
gcc -o libhello_msg.so.1.2.3 -shared -Wl,-Bsymbolic -Wl,-soname=libhello_msg.so.1 hello_msg.os


— And the build immediately after 

> scons-2.3.1 -Q —debug=explain

scons: rebuilding `libhello_msg.so.1.2.3' because the contents of the build action changed
              action: SharedFlagChecker(target, source, env)
                      VersionedSharedLibrary(target, source, env)
gcc -o libhello_msg.so.1.2.3 -shared -Wl,-Bsymbolic -Wl,-soname=libhello_msg.so.1 hello_msg.os

(The MD5 checksum did not match.)
As aside: Why is there a difference between the use of -Bsymbolic on versioned shared libraries and shared versioned libraries?



II)  FILES NOT PROPERLY GETTING CLEANED UP

When the library gets built in a ’non-standard’ directory, where ‘non-standard’ means not the same directory as the source or the variant directory,  various
files and symbolic links do not get removed.  

A detailed account follows, but in investigating I learned

i) The generation of the targets follows different paths in constructing the names of symbolic links for the library and the ‘clean’ targets, resulting in the clean targets not having the proper ’non-standard’ directory.  The happens in ‘Environment.py’ when the method ‘Clean’ invokes ‘arg2nodes’.

ii) The situation is somewhat confused by the reporting of what’s being deleted.  When the message reads
           ‘Removed /tmp/libhello_msg.so.1.2.3’
it is really removing the symbolic link ‘/tmp/libhello_msg.so'.   When doing things in the ‘standard’ way, everything does get properly removed, its just that the         messages reporting what gets removed do not match what is actually being removed.  This isn’t really wrong, but it did add some confusion when I was investigating.


— Here’s the build file

> less SConstruct    

SharedLibrary (“hello_msg.c”,  SHLIBPREFIX = '/tmp/lib',  SHLIBVERSION = ‘1.2.3')
(There are other ways to generate ’non-standard’ output directories, but this is the simplest and maybe not really an approved SCons method, I could concoct.)

— Here’s the build

> scons-2.3.1 -Q 

gcc -o hello_msg.os -c -fPIC hello_msg.c
gcc -o /tmp/libhello_msg.so.1.2.3 -shared -Wl,-Bsymbolic -Wl,-soname=libhello_msg.so.1 hello_msg.os

— and the results (which are as anticipated)

> ls /tmp/lib*

/tmp/libhello_msg.so@  /tmp/libhello_msg.so.1@	/tmp/libhello_msg.so.1.2.3*

— and the subsequent clean

> scons-2.3.1 -Q --clean

Removed hello_msg.os
Removed /tmp/libhello_msg.so.1.2.3

Note that only ‘/tmp/libhello_msg.so.1.2.3’ appears to be deleted, but looking at what’s left 


> ls /tmp/lib*

/tmp/libhello_msg.so.1@  /tmp/libhello_msg.so.1.2.3*

indicates the message is not saying what actually happened. Following the code, what really happened here was 
a) The symbolic link ‘/tmp/libhello_msg.so’ was actually what was deleted
b) In Script/Main the call to 'SCons.Environment.CleanTargets[target]’ in ‘def remove’ method fails because of the incorrect file names.


Sorry about this being long-winded. I tried to cut this down as much as possible.

JJRussell