BUG: devel/ncurses does not provide libcurses and <curses.h>

[master@…]

As of now, if an applications is trying to use curses "by the book", #include <curses.h> and -lcurses, then system (not macports) library is used, since libcurses symlink is not created in /opt/local/lib and curses.h is not in /opt/local/include.

But IMHO the whole idea of having both wide and not-wide ncurses is BAD. The bug report #6602 was complaining about incorrect _naming_ of libraries, but the fix brought us two sets of headers (wide being compatible extension of normal) and two sets of libraries (they are binary incompatible, but appications using non-wide API can be linked against wide libraries without modification). I think the better approach is that of Apple (as can be seen at ​http://www.opensource.apple.com/darwinsource/10.4.9.ppc/ncurses-15/Makefile )

• install wide version of ncurses as libncurses (without w suffix).

The approach in the attached Portfile-new is even better

• install libncursesw and create symlinks libcurses and libncurses.

In this way we do not create a new portability obstacle, the canonical -lcurses works, and avoid extra work configuring/patching programs that for some reason want -lncurses or -lncursesw.

As a second-best solution I attach patches for two now existing Portfiles (ncurses and ncursesw), to put headers into /opt/local/include and make the libcurses symlink to libncurses. But in this case an application linking -lcurses and wishing to use wide API won't be happy.

The termcap-related additions are there to mimic how Apple configures system ncurses.

[master@…]

Proposed new port to replace ncurse and ncursesw

[master@…]

do not install headers and make libcurses symlink

[master@…]

install headers to /opt/local/include

[master@…]

Anybody there?

[ryandesign (Ryan Carsten Schmidt)]

This sounds fine in theory, I'd like to see an actual port that demonstrates the problem. A port which, with the *curses* ports the way they are, visibly links against the system's libraries (visible with otool -L I suppose) but links with MacPorts libraries using your new port, or your patches. Preferably your example port would be small and not have many other dependencies. I don't mean you need to create an example port; I mean, presumably you were originally trying to install some other software and you noticed it linked against the wrong curses libraries. What was that other software?

[master@…]

Dear Ryan,

here is the test port you wanted,
but really in boils down to
a program with

 #include <curses.h> /* as per ncurses(3) */

and compiled as

cc -o progname -I/opt/local/include -L/opt/local/lib -lcurses progname.c

uses system header files and libraries.

Comment:
(Although ncurses(3) says one must link with -lncurses,

in personal communication author of ncurses states that

====

How would the ideal world without workarounds for other workarounds for ancient bugs look like?

#include <curses.h>

-lcurses

(but the non-ideal world has different implementations and versions of curses)

=====

Also "The Single UNIX ® Specification" says -lcurses ;)

[master@…]

Portfile for a test port for Ryan

[master@…]

test program for Ryan

[master@…]

Ryan wrote

you were originally trying to install some other software and you noticed it linked against the wrong curses libraries. What was that other software?

Irrelevant, since 1) I have not ported it yet (waiting for the ncurses problem to be sorted out and TeXLive to become base TeX port) 2) Sent a patch to the developer to look for ncurses before curses and it was accepted.

[(none)]

Milestone Port Bugs deleted

[nox@…]

No updates for 2 years, virtually not even a problem.

[cssdev]

I wonder if this could be what's causing my trouble getting CMake to use the correct ncurses library. see #25614. It looks like it's finding a mix of system and MacPorts libraries, but the final binary links only with the system lib.

[master@…]

Replying to css@…:

I wonder if this could be what's causing my trouble getting CMake to use the correct ncurses library. see #25614.

Exactly. And in this case CMake behavior is correct, while ugly workarounds described in #25614 result from unwillingness of macports people to fix ncurses port (my guess - they are afraid to provoke a recompilation of ports depending on ncurses).

No updates for 2 years, virtually not even a problem.

There is a problem, but since it is common most software has workarounds, searches for ncurses before curses.

But CMake does it the opposite order and can not be blamed since standard says "curses", see above.

Since CMake is a big fish it looks reasonable to reopen the ticket.

[jmroot (Joshua Root)]

I didn't see this before because it was assigned to the old maintainer (and didn't have the Port field set due to age).

[jmroot (Joshua Root)]

r76622