Bug#427166: jed: compiled against S-Lang 20007 but linked to 20006

Rafael Laboissiere rafael at debian.org
Sun Jun 3 19:00:01 UTC 2007


* John E. Davis <davis at space.mit.edu> [2007-06-03 13:51]:

> On Sun, 3 Jun 2007 18:42:40 +0200, Jörg Sommer <joerg at alea.gnuu.de> said:
> >> jed works properly, except it starts with the warning
> >>=20
> >> ***Warning: Executable compiled against S-Lang 20007 but linked to 20006
> >
> >Why did you add this check to main? Do you have any reason to recommend
> >an update? Because it adds a sleep of two seconds I tend to remove it
> >=66rom the Debian package. Do you think this causes any problems? I think
> >such a reverts the advantage of shared libraries to upgrade the library
> >without recompiling the program.
> 
> But that is not what the message indicates.  It says that it was
> compiled against a newer version of the library (20007) but actually
> using an older version (20006).  So something is wrong with the linker
> configuration.

I think that the linker configuration is actually okay.  In Debian, both
versions 2.0.6 and 2.07 of the S-Lang library have the same soname, namely
libslang.so.2.  This means that the linker will happily links a jed program
having:

$ ldd $(which jed) | grep slang
        libslang.so.2 => /lib/libslang.so.2 (0xb7e87000)

against the library from the slang2 2.0.6 package.

In order to circumvent this problem, we could force jed in Debian to depend
on libslang2 (>= 2.0.7).  For now, the jed package depends on libslang2 (>=
2.0.6-3).  This happens because we use ${shlibs:Depends} in debian/control
and we have:

$ cat /var/lib/dpkg/info/libslang2.shlibs
libslang 2 libslang2 (>= 2.0.6-3)

Should we ask the slang2 maintainer to bump the version number of the shlibs
file?

> Also suppose that 20007 contains a bug fix that was not in 20006 and
> that jed included a work-around if compiled against older versions of
> the library:
> 
>    /* Some jed code */
>    #if SLANG_VERSION < 20007
>      /* work around a bug to avoid a SEGV */
>         .
> 	.
>    #else
>      /* no need to work around the bug */
>    #endif
> 
> As you can see, when compiled against 20007, the "bug-fixing" code
> will not get included.  However, since the user is actually using
> 20006, the bug is present but the code to work-around it is not.

This strategy is problematic due to the soname-based behavior of the linker
as I described above.  You could replace the conditional compilation above
by some run-time test on the library version.  That would be less efficient,
though.

-- 
Rafael




More information about the Pkg-jed-devel mailing list