'soname' in ncurses-1.9.9e

'soname' in ncurses-1.9.9e

Post by Duncan Snelli » Tue, 03 Dec 1996 04:00:00



As part of my upgrade to kernel-2.0.26, I upgraded binutils to 1.8.5.  The
loader is a bit more particular about the correct soname in the various
libraries, and ldconfig gave errors about /usr/lib/libncurses soname
not agreeing.  I had upgraded ncurses using the ncurses-1.9.9e.bin
distribution.

After a bit of investigation, I located the source distribution of
ncurses, and in the file dist.mk the library versions were set as
  VERSION=1.9.9e
  SHARED_ABI=3.0

This was giving links (in /usr/lib)
    libncurses.so   -> libncurses.so.3
    libncurses.so.3 -> libncurses.so.1.9.9e

Changing to
  SHARED_ABI=1.9 has cured the problem.

Also, the new include files were put in /usr/include, not
/usr/include/ncurses, which on recompling things (notably the
screen driven conifg file generator with the 2.0.x kernels) failed to
match the library. (I can't recall the exact error...).  So I moved
/usr/include/ncurses to /usr/include/ncurses_old.

I hope this is helpful to someone ....

Duncan

--


 
 
 

'soname' in ncurses-1.9.9e

Post by Carl D. Ro » Tue, 03 Dec 1996 04:00:00



> After a bit of investigation, I located the source distribution of
> ncurses, and in the file dist.mk the library versions were set as
>   VERSION=1.9.9e
>   SHARED_ABI=3.0

That brings up an interesting point, that I saw too when I was
installing ncurses.  Why is the ABI version different than the library
version?  the dist.mk describes the ABI version as the differentiation
between incompatible API's, but that's what I thought major version
numbers were for (you know, `library version'.)...  That is, if the
API has changed three times so far, why are we still on version 1.9 of
ncurses?  The fact that the new versions of linux ld.so are more picky
makes this problem more obvious now.

-- Carl

 
 
 

'soname' in ncurses-1.9.9e

Post by T.E.Dicke » Thu, 05 Dec 1996 04:00:00


: As part of my upgrade to kernel-2.0.26, I upgraded binutils to 1.8.5.  The
that's known & will be accommodated in the next release.

: Also, the new include files were put in /usr/include, not
that's a configure option (you installed overwriting the bsd4.4 curses)

: /usr/include/ncurses, which on recompling things (notably the
: screen driven conifg file generator with the 2.0.x kernels) failed to
: match the library. (I can't recall the exact error...).  So I moved
if you don't know, we can't fix it.

--
Thomas E.*ey

 
 
 

'soname' in ncurses-1.9.9e

Post by A. Kunigeli » Thu, 05 Dec 1996 04:00:00



Quote:

> That brings up an interesting point, that I saw too when I was
> installing ncurses.  Why is the ABI version different than the library
> version?  the dist.mk describes the ABI version as the differentiation
> between incompatible API's, but that's what I thought major version
> numbers were for (you know, `library version'.)...  That is, if the
> API has changed three times so far, why are we still on version 1.9 of
> ncurses?  

What about this interpretation: version 1.9.9e of the ABI 3.0 conforming
curses?

Martynas Kunigelis

 
 
 

'soname' in ncurses-1.9.9e

Post by Piercarlo Gran » Thu, 05 Dec 1996 04:00:00



duncs> After a bit of investigation, I located the source distribution
duncs> of ncurses, and in the file dist.mk the library versions were set
duncs> as VERSION=1.9.9e SHARED_ABI=3.0

roth> That brings up an interesting point, that I saw too when I was
roth> installing ncurses.  Why is the ABI version different than the
roth> library version?  the dist.mk describes the ABI version as the
roth> differentiation between incompatible API's, but that's what I
roth> thought major version numbers were for (you know, `library
roth> version'.)...  That is, if the API has changed three times so far,
roth> why are we still on version 1.9 of ncurses?  The fact that the new
roth> versions of linux ld.so are more picky makes this problem more
roth> obvious now.

Very few package authors understand the logic behind version/release
numbers of API and ABI. Expecting them to use systematic version numbers
for either is hopeless (a perfect example is the inanity of ``version''
numbers like '1.9.9e', or '2.7.2.1').

The 'binutils' and 'ld.so' way of dealing with them is broken too. There
is no easy fix.

Besides, the major number of the API can plausibly change even if the
major number of the ABI need not (and even viceversa can happen).

 
 
 

'soname' in ncurses-1.9.9e

Post by Marek Rouch » Fri, 06 Dec 1996 04:00:00


So what to do about it? Does all the stuff posted here previously mean, that
when I upgrade to ld.so-1.8.5 e.g. lynx compiled against libncurses-1.9.9e
(soname 3.0) won't work any more after I've executed ldconfig?
Where is the root of the problem?
a) Should ncurses change its version numbering?
b) Should the changes to ld.so be taken back?
c) ???
Can somebody please enlighten me about the circumstances, under which ld.so
will fail to dynamically link a shared lib? I don't want to break my system
that is running well even with ld.so-1.7.14 and libc-5.4.13.

MTIA

Marek

****************************************************************************

* -----------------------\       http://saftsack.fs.uni-bayreuth.de/~marek *
* Unteres Tor 12          \------------------------------------------------*

* Tel/FAX +49-921-511824          for PGP Public Key                       *
****************************************************************************

 
 
 

'soname' in ncurses-1.9.9e

Post by Ian T Zimmerm » Sat, 07 Dec 1996 04:00:00



Quote:Grandi) writes:
> Very few package authors understand the logic behind version/release
> numbers of API and ABI.

I'm afraid I don't really understand, either.  Is there a document
defining the notions of API and ABI, and explaining when the major
version numbers should (and shouldn't) change?

--

I fully support the President's proposal to test driver's license
applicants for *.  Any plan to reduce driving is worth a try.

 
 
 

'soname' in ncurses-1.9.9e

Post by T.E.Dicke » Mon, 09 Dec 1996 04:00:00


: Very few package authors understand the logic behind version/release
: numbers of API and ABI. Expecting them to use systematic version numbers
: for either is hopeless (a perfect example is the inanity of ``version''
: numbers like '1.9.9e', or '2.7.2.1').
I'm amused: you're criticizing a problem that didn't exist at the time
ncurses 1.9.9e was released.  Moreover, the ld.so at that point didn't
_handle_ the minor revision in the same way that the newest version does.
Finally, this level of incompatibility is not treated the same on other
systems -- so there's more to it than you're addressing.

(The problem is known & will be addressed in the next release).

--
Thomas E.*ey

 
 
 

'soname' in ncurses-1.9.9e

Post by Ian T Zimmerm » Mon, 09 Dec 1996 04:00:00




> As part of my upgrade to kernel-2.0.26, I upgraded binutils to
> 1.8.5.  The loader is a bit more particular about the correct soname
> in the various libraries, and ldconfig gave errors about
> /usr/lib/libncurses soname not agreeing.  I had upgraded ncurses
> using the ncurses-1.9.9e.bin distribution.

> After a bit of investigation, I located the source distribution of
> ncurses, and in the file dist.mk the library versions were set as

>   VERSION=1.9.9e
>   SHARED_ABI=3.0

> This was giving links (in /usr/lib)
>     libncurses.so   -> libncurses.so.3
>     libncurses.so.3 -> libncurses.so.1.9.9e

  vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Quote:> Changing to
>   SHARED_ABI=1.9 has cured the problem.

  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Has it really?  I wonder.  Have you run ncurses linked programs since
you made this change?  I mean, ldconfig is no longer complaining,
that's nice, but all programs still demand to link to libncurses.so.3!
At the very least, I'd expect you must keep the old symlink from
libncurses.so.3 around along with the new one from libncurses.so.1.9.
But if ld.so is as picky as ldconfig, even that won't be enough.

Maybe it's best to put up with the warning until ncurses API reaches
version 3.0 :-)

--

I fully support the President's proposal to test driver's license
applicants for *.  Any plan to reduce driving is worth a try.

 
 
 

'soname' in ncurses-1.9.9e

Post by Ian T Zimmerm » Mon, 09 Dec 1996 04:00:00





> : Very few package authors understand the logic behind version/release
> : numbers of API and ABI. Expecting them to use systematic version numbers
> : for either is hopeless (a perfect example is the inanity of ``version''
> : numbers like '1.9.9e', or '2.7.2.1').

[snip]

Quote:> (The problem is known & will be addressed in the next release).

Next release of what, ncurses or ld.so?  IMHO the only way to fix it
in ncurses is to hitch the API version right up to 3.0.  You can't
change the ABI version without requiring a relink of every program
that uses ncurses.

--

I fully support the President's proposal to test driver's license
applicants for *.  Any plan to reduce driving is worth a try.

 
 
 

'soname' in ncurses-1.9.9e

Post by Brent Corb » Tue, 10 Dec 1996 04:00:00



:   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
: > Changing to
: >   SHARED_ABI=1.9 has cured the problem.
:   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

: Has it really?  I wonder.  Have you run ncurses linked programs since
: you made this change?  I mean, ldconfig is no longer complaining,
: that's nice, but all programs still demand to link to libncurses.so.3!
: At the very least, I'd expect you must keep the old symlink from
: libncurses.so.3 around along with the new one from libncurses.so.1.9.
: But if ld.so is as picky as ldconfig, even that won't be enough.

: Maybe it's best to put up with the warning until ncurses API reaches
: version 3.0 :-)

Well, I don't know what luck the original poster has had, but I have
tried this trick and it's worked fine for me so far - no problems building
or running ncurses based programs (YMMV!!!)

 
 
 

'soname' in ncurses-1.9.9e

Post by Phil DeBecke » Thu, 12 Dec 1996 04:00:00




> :   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> : > Changing to
> : >   SHARED_ABI=1.9 has cured the problem.
> :   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> : Has it really?  I wonder.  Have you run ncurses linked programs since
> : you made this change?  I mean, ldconfig is no longer complaining,
> : that's nice, but all programs still demand to link to libncurses.so.3!
> : At the very least, I'd expect you must keep the old symlink from
> : libncurses.so.3 around along with the new one from libncurses.so.1.9.
> : But if ld.so is as picky as ldconfig, even that won't be enough.

> : Maybe it's best to put up with the warning until ncurses API reaches
> : version 3.0 :-)

> Well, I don't know what luck the original poster has had, but I have
> tried this trick and it's worked fine for me so far - no problems building
> or running ncurses based programs (YMMV!!!)

Well, I'm sure this works great *if* you recompile every single program
that uses ncurses.  With ld.so.1.7.14, the versions of the ncurses
libraries with a soname of 3.0 were linked to your 1.9.9e libs.  This is
no longer possible, since ld.so.1.8.5 ignores symlinks.  But, the
programs you've compiled with ncurses still want libs with a soname of
3.0.

The solution?  Simple: rename your libs from libxxx.so.1.9.9e to
libxxx.so.3.0.0.  This will satisfy ld.so, which will happily link
libncurses.so.3.0 -> libncurses.so.3.0.0.  Your programs will still want
the library with the *soname* of libncurses.so.3.0, and they will get
it: libncurses.so.3.0.0.  The actual name ("version number") of the lib
doesn't matter to the programs that use the lib, only to ld.so.

Works for me; I didn't have to recompile anything at all.

--
========================================================================

------------------------------------------------------------------------
"Murphy's Law is recursive:
you cannot wash your car to make it rain"
========================================================================

 
 
 

'soname' in ncurses-1.9.9e

Post by Brent Corb » Thu, 12 Dec 1996 04:00:00


: >
: > Well, I don't know what luck the original poster has had, but I have
: > tried this trick and it's worked fine for me so far - no problems building
: > or running ncurses based programs (YMMV!!!)

: Well, I'm sure this works great *if* you recompile every single program
: that uses ncurses.  With ld.so.1.7.14, the versions of the ncurses
: libraries with a soname of 3.0 were linked to your 1.9.9e libs.  This is
: no longer possible, since ld.so.1.8.5 ignores symlinks.  But, the
: programs you've compiled with ncurses still want libs with a soname of
: 3.0.

Yeah - I started to suspect that later, after I sent off my post.  
I actually scanned my binaries later and discovered that the only
ones using ncurses at the moment are the ncurses utilities and menuconfig
for the kernel --- all newly rebuilt and functioning fine, suprise suprise 8*)

Your point is well taken, though --- thanks

: The solution?  Simple: rename your libs from libxxx.so.1.9.9e to
: libxxx.so.3.0.0.  This will satisfy ld.so, which will happily link
: libncurses.so.3.0 -> libncurses.so.3.0.0.  Your programs will still want
: the library with the *soname* of libncurses.so.3.0, and they will get
: it: libncurses.so.3.0.0.  The actual name ("version number") of the lib
: doesn't matter to the programs that use the lib, only to ld.so.

: Works for me; I didn't have to recompile anything at all.

Good!  I'll try to keep this in mind, just in case I do wind up picking
up a binary somewhere that does depend on having a libncurses-3.0...

Thanks again!

 
 
 

'soname' in ncurses-1.9.9e

Post by Christopher Linds » Mon, 16 Dec 1996 04:00:00




>: Very few package authors understand the logic behind version/release
>: numbers of API and ABI. Expecting them to use systematic version numbers
>: for either is hopeless (a perfect example is the inanity of ``version''
>: numbers like '1.9.9e', or '2.7.2.1').
>I'm amused: you're criticizing a problem that didn't exist at the time
>ncurses 1.9.9e was released.  Moreover, the ld.so at that point didn't
>_handle_ the minor revision in the same way that the newest version does.
>Finally, this level of incompatibility is not treated the same on other
>systems -- so there's more to it than you're addressing.
>(The problem is known & will be addressed in the next release).

I downloaded ncurses-1.9.9g in early December, and it still has this
problem with ld.so-1.8.5...

Chris

---------------------------------------------------------------------
Christopher Lindsey
Senior UNIX System Administrator
Wolfram Research, Inc.                              Mallorn Computing
http://www.wolfram.com/~lindsey       http://www.mallorn.com/~lindsey

 
 
 

1. ncurses-1.9.9e/terminfo's console/linux files

Hi there,

Just compiled debian's tcsh 6.06-3. It runs fine, but on virtual consoles
(tty[0-9]+) a terminal problem arises; under X all is well.

The new tcsh loads ncurses:

ldd /bin/tcsh
        libncurses.so.3.0 => /lib/libncurses.so.3.0
        libc.so.5 => /lib/libc.so.5.3.12

and, as I found out, ncurses requires the terminfo files. The OLD (1994)
terminfo c/console file we used (generates colors with dialog, setterm and
color-ls) sends wrong codes when scrolling. Result is 0G in the upper-left
corner and wrong cursor position.
I renamed console and re-made the original symlink to ../l/linux.
That solves the problem, but also removes all color handling.

I untic'ed both console entries, and both mension colors#8 as capability.

What on earth am I doing wrong? What sets the 'console' term types (no it's
not /etc/login.defs, /etc/ttys, or /etc/ttytype, neither is it in the binaries
of getty, login, init (2.64) or the kernel.

My system is initially sls 1.03 based, but gradually shifted to slackware.
Now it is ELF, kernel 2.0.19 (yes a new "stable" kernel every day :-(),
libc-5.3.12.

We run an old (a.out based) setterm. The sources have'n changed since 1992. Is
there a replacement somewhere that runs ok under elf and links with ncurses?

And what about dialog 0.6c? Why do distributions still use 4.x?

In short, I'm stunned; guru's, please help.

Thanks!

piet
--
Piet W. Plomp, ICCE, Groningen University         |     ---   __ o    __~o


2. Advice for new NetBSD (i386) user

3. ncurses-1.9.9e

4. Removing virtual screensize - XFree 4.02

5. ld.so-1.7.14 and ncurses-1.9.9e

6. rlp from os5 to 3.2.4.2

7. Ncurses-1.9.9e, Slack-3.1, RedHat-3.0.3, Debian-1.1

8. BOOK: Perl from the Ground Up

9. Problem Compiling ncurses-1.9.9e

10. less file seg faults with TERM=linux-m from ncurses-1.9.9e

11. ncurses-1.9.9e Compilation problems

12. ncurses-1.9.9e bug?

13. ncurses-1.9.9e