Re: Help wanted with bkgd() rookie mistake

[Thomas Dickey]

On Sun, Jan 05, 2025 at 01:30:03PM -0600, G. Branden Robinson wrote:
> At 2025-01-05T14:08:43-0500, Thomas Dickey wrote:
> > > $ make
> > > cc -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 bkgd.c -o bkgd -lncurses -ltinfo
> > > cc -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 
> > > -I/home/branden/ncurses-HEAD/include/ncursesw 
> > > -I/home/branden/ncurses-HEAD/include bkgrnd.c -o bkgrnd 
> > > -L/home/branden/ncurses-HEAD/lib -lncursesw -ltinfow -ldb
> > 
> > The -L option isn't doing much, because the system is picking the
> > library.
> 
> Yes--I forgot, if I ever knew, that my ncurses builds don't create an
> "ncurses6-config" program...just "ncurses6w-config".  The former is

fwiw, Debian used to provide a different name, and I used to use that name.
They changed, so I added a "td" to the name.  Works for the moment.
I have these "ncurses" files in /usr/bin:

/usr/bin/i686-w64-mingw32-ncursesw6td-config
/usr/bin/ncurses-examples
/usr/bin/ncurses5-config
/usr/bin/ncurses6
/usr/bin/ncurses6-config
/usr/bin/ncursest-examples
/usr/bin/ncursest6
/usr/bin/ncursestw6td-config
/usr/bin/ncursesw5-config
/usr/bin/ncursesw6-config
/usr/bin/ncursesw6td-config
/usr/bin/x86_64-w64-mingw32-ncursesw6td-config

> found in /usr/bin, and the latter both in /usr/bin and
> $HOME/ncurses-HEAD/bin, with the latter winning because $PATH.
> 
> So when I test "narrow" ncurses, I've only ever been testing Debian's
> ncurses5 packages.  Oh great.  Well, I know now.
> 
> > That last LD_LIBRARY_PATH shows a different library.  It'll satisfy
> > ldd either way, but the program linked (compile-time/link) against the
> > libncurses.so.5 won't behave as expected because the offsets to the
> > video-attribute changed between ABI 5 and 6.
> 
> I wonder if that's why neomutt cores.

that could do it
 
> It doesn't explain why bkgd() has a problem, but it could well be a 4+
> year old bug that you fixed ages ago, and which happens to linger in
> Debian's oldstable release.  I don't think an ABI mismatch explains
> _this_ bug because I've been building my "narrow" test programs, as it
> turns out, only against Debian's old libraries, and mostly I test
> API-level stuff that hasn't changed in decades.
> 
> > (you could force it to ignore the default library path using the rpath
> > feature, but that's a nuisance for one-offs).
> 
> I've never had to mess with rpath and I'm not anxious to start.

:-)

I do that, or set $LD_LIBRARY_PATH on BSDs where the linker is less friendly
 
> I'm thinking what I probably want to do is use the same compiler flags
> for all of my test scripts, and distinguish them only by the API they
> elect to use.  It's not like libncursesw.so.6 is missing the narrow
> entry points.

They're pretty close - the narrow entry points know more about how to
coexist with wide-characters than in the narrow library.  But it's
mostly transparent...

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

signature.asc
Description: PGP signature