* John E. Davis <[EMAIL PROTECTED]> [2007-06-03 13:51]:
> On Sun, 3 Jun 2007 18:42:40 +0200, Jörg Sommer <[EMAIL PROTECTED]> 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
