[Scons-users] SCons fails to create symlinks (SHLIBVERSION)

[Bill Deegan]

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 <mats at wichmann.us> 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
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20240223/f90af208/attachment.htm>