Re: SCons fails to create symlinks (SHLIBVERSION)

Thanks for the explanations and all solutions. The problem is solved!

From: Scons-users <[email protected]> On Behalf Of Bill Deegan
Sent: Friday, February 23, 2024 9:59 PM
To: SCons users mailing list <[email protected]>
Subject: Re: [Scons-users] SCons fails to create symlinks (SHLIBVERSION)

AddPreAction() to the Libraries you're adding versioning to that removes the target file?
That should address your immediate issue.

On Fri, Feb 23, 2024 at 7:58 AM Mats Wichmann <[email protected]<mailto:[email protected]>> wrote:
On 2/22/24 23:01, Cristian Farcas via Scons-users wrote:
> It works after I cleaned the old lib, built without SHLIBVERSION. Thanks!
>
> It’s really ugly to switch from normal to versioned lib. I cannot
> request the whole team to do a clean everytime they checkout over my
> commit. So I have to ensure at each build that libabc.so is deleted if
> it’s not a symlink. Also, when increasing the version, untracked old
> version libs remain on the disk. These require special deletion as well...

This situation arises due to the design of SCons, for better or for
worse: when it starts up, it reads the build configuration from the
sconscripts, constructs the dependency graph, and then makes decisions
from that.  At this point it doesn't know anything about what that graph
may have looked like before.  There may be saved information in the
signature database from the previous run, but (a) it's not consulted for
nodes not in the current tree (and will simply be lost next time the
database is updated - that is, when *this* run finishes) and (b) there's
no filetype information, so it can't detect changes (like "used to be a
dir, now a file"; "used to be a file, now a symlink", etc.).

Case (a) applies if you change the version:  if the library name
previously was libfoo.so.3 and now it's libfoo.so.4 then the former will
be unknown this time, and won't even be picked up by a "clean". But at
least the fresh build should work, you'll just be left with that
dangling build artifact from earlier.

Case (b) is the one from your original posting: libfoo.so was the target
library before, now it's libfoo.3, because the "base" library always
includes the version if it's defined. This goes wrong because the shared
library logic sees it should make a symbolic link (or two if you had a
dot in the version specifier), but because the existing file by that
name isn't a symlink it just leaves it alone - this is commented as a
safety measure in the code, whether or not that's well considered - and
then the actual link operation fails.  At least in this case since the
symlink will be a tracked target, it will be removed on a clean and you
can then recover by rebuilding.

This is the aforementioned safety rail in the code:

         # Delete the (previously created) symlink if exists. Let only
symlinks
         # to be deleted to prevent accidental deletion of source
files...
         if env.fs.islink(link):

             env.fs.unlink(link)


Don't know what to tell you about mitigations... you've pretty much
listed the obvious ones, which is to provide some cleanup code (perhaps
in site_scons?) when you know you've made a structural change. Maybe
someone else listening here has some better suggestions - I know there
are some experts particularly on the shared libs topics.
_______________________________________________
Scons-users mailing list
[email protected]<mailto:[email protected]>
https://pairlist4.pair.net/mailman/listinfo/scons-users<https://urldefense.com/v3/__https:/pairlist4.pair.net/mailman/listinfo/scons-users__;!!A4F2R9G_pg!bq0-FsCN-FoCdfcg5JcG8IRnHsmkNrs2zhgeMKpPNgFnQDFgOeUoUp7Bwh9e2Ua4--gAwmSRVPve_Y6Le_qtlO-M_D0$>

_______________________________________________
Scons-users mailing list
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users