FPC can't link screen_demo using supplied ncurses

[mccfrank]

I am running OpenSuse Tumbleweed  using Free Pascal Compiler version 3.2.2 [2025/01/10] for x86_64.

I was planning to use the crt replacement ncrt for a project, but my version of the ncurses.ppu does not like
the ncurses library supplied by OpenSuse.

I get these linking errors:

Compiling screen_demo.pp
Linking screen_demo
/usr/bin/ld: ocrt.o: in function `OCRT_$$_SETACTIVEWN$PWINDOW':
ocrt.pp:(.text.n_ocrt_$$_setactivewn$pwindow+0x4c): undefined reference to `stdscr'
/usr/bin/ld: ocrt.o: in function `OCRT_$$_STARTCURSES$PWINDOW$$BOOLEAN':
ocrt.pp:(.text.n_ocrt_$$_startcurses$pwindow$$boolean+0x74): undefined reference to `stdscr'
/usr/bin/ld: ocrt.pp:(.text.n_ocrt_$$_startcurses$pwindow$$boolean+0x86): undefined reference to `stdscr'
/usr/bin/ld: ocrt.pp:(.text.n_ocrt_$$_startcurses$pwindow$$boolean+0x98): undefined reference to `stdscr'
/usr/bin/ld: ocrt.pp:(.text.n_ocrt_$$_startcurses$pwindow$$boolean+0xac): undefined reference to `stdscr'
/usr/bin/ld: ocrt.o:ocrt.pp:(.text.n_ocrt_$$_startcurses$pwindow$$boolean+0xc9): more undefined references to `stdscr' follow
/usr/bin/ld: ocrt.o: in function `OCRT_$$_NDELWINDOW$PWINDOW':
ocrt.pp:(.text.n_ocrt_$$_ndelwindow$pwindow+0x2b): undefined reference to `curscr'

Apparently the ABI has changed for ncurses.

I filed a bug with FPC but as far as I can see nothing has been done.

I am told by someone on the OpenSuse mailing list that ensuring different include files are included in the linking avoids the problem.  The next
line apparently tells FPC to refer to the OLD ncurses library.

fpc -I/usr/include/ncurses5/ncurses -k"-L/usr/lib64/ncurses5 -lncurses -ltinfo" menu_demo.pp

menu_demo and other demo programs do compile and link with that command line.

[marcov]

This is normal in many Redhat derived linuxes.  NCurses can be compiled in multiple ways, one of which puts some symbols in a separate "tinfo" library. So the solution is to also link tinfo on such distros.  The reasons for this are in the realm of compatibility with certain curses libraries on commercial Unixes, which are all pretty much dead nowadays.

No action is needed, because this is not a change on all distros, just a quirk of some. In the past when this caused problems I used to suggest to put 

-XLAncurses=ncurses,tinfo

in the fpc.cfg, but I don't know if that still works.

Or put {$linklib terminfo} in the relevant programs, when compiling for such distros.

[mccfrank]

Well I think it's much more complicated than that.
Neither of your suggestions works 9 I guess you meant {$LINKLIB tinfo} .

Some are saying the whole abi was changed when ncurses was upgraded so
none of the existing calls in the FPC unit ncurses work on this system.

This problem has existed for quite a while. Four years ago someone was trying to
compile Midnight Commander from source and a similar problem arose.

This was one suggestion:

There are two different flavors of ncurses - libncurses5 and libncurses6. They are built from the same source but with different ABI (and library major version). libncurses6 is built with --enable-reentrant which changes some variable names, so stdscr becomes __nc_stdscr. You have two options
    Fix MC autoconfig checks. You will need to make sure proper includes are detected before and used in code looking for stdscr (so compiled program is using correct name). This is upstream issue and needs to be reported and fixed upstream.
    Use libncurses5 (and ncurses5-devel) to build your package as short term workaround.

It is unfortunate that OpenSuse still has this problem..although it seems to me the FPC people
should deal with it.
I run Debian Trixie on another partition and there fpc and ncurses work flawlessly.
So I will just move all my code there

Thanks

[TRon]

It is unfortunate that OpenSuse still has this problem..although it seems to me the FPC people should deal with it.

Sure, FPC team must be held accountable for each and every version of whatever library.

Is it truly that difficult to write your own headers and use the appropriate ones for the target ?

[dsiders]

It is unfortunate that OpenSuse still has this problem..although it seems to me the FPC people should deal with it.

Sure, FPC team must be held accountable for each and every version of whatever library.

Is it truly that difficult to write your own headers and use the appropriate ones for the target ?

Or to install libncurses5 from the OpenSUSE repos?

[TRon]

Or to install libncurses5 from the OpenSUSE repos?

I dunno suse and OP made it sound that was not even an option but yes that would be even easier to accomplish 

[marcov]

Well I think it's much more complicated than that.
Neither of your suggestions works 9 I guess you meant {$LINKLIB tinfo} .

Yes.

Some are saying the whole abi was changed when ncurses was upgraded so
none of the existing calls in the FPC unit ncurses work on this system.

This problem has existed for quite a while. Four years ago someone was trying to
compile Midnight Commander from source and a similar problem arose.

If the ncurses ABI changed, why do debian/ubuntu likes don't suffer from this?

So unless -6 is an experimental version, and debian is not packaging, it is not a general movement of the library, but a RH/Suse specific one. And then it is the RH/Suse package that must deal with it, that is how distros work.

Distros take general packages and adapt them to their distros' peculiarities.

There are two different flavors of ncurses - libncurses5 and libncurses6. They are built from the same source but with different ABI (and library major version). libncurses6 is built with --enable-reentrant which changes some variable names, so stdscr becomes __nc_stdscr. You have two options
    Fix MC autoconfig checks. You will need to make sure proper includes are detected before and used in code looking for stdscr (so compiled program is using correct name). This is upstream issue and needs to be reported and fixed upstream.
    Use libncurses5 (and ncurses5-devel) to build your package as short term workaround.

It is unfortunate that OpenSuse still has this problem..although it seems to me the FPC people
should deal with it.

According to your description above, just use ncurses5 and not 6, as that is some experimental thingy.