Opened 13 years ago

Closed 10 years ago

#12605 closed defect (fixed)

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

Reported by: master@… Owned by: jmroot (Joshua Root)
Priority: Normal Milestone:
Component: ports Version: 1.5.0
Keywords: Cc: mww@…, nox@…
Port: ncurses ncursesw

Description

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.

Attachments (5)

Portfile-new (2.0 KB) - added by master@… 13 years ago.
Proposed new port to replace ncurse and ncursesw
patch-ncurses-Portfile (928 bytes) - added by master@… 13 years ago.
do not install headers and make libcurses symlink
patch-ncursesw-Portfile (434 bytes) - added by master@… 13 years ago.
install headers to /opt/local/include
Portfile (456 bytes) - added by master@… 13 years ago.
Portfile for a test port for Ryan
tclock-1.tar.gz (2.4 KB) - added by master@… 13 years ago.
test program for Ryan

Download all attachments as: .zip

Change History (17)

Changed 13 years ago by master@…

Attachment: Portfile-new added

Proposed new port to replace ncurse and ncursesw

Changed 13 years ago by master@…

Attachment: patch-ncurses-Portfile added

do not install headers and make libcurses symlink

Changed 13 years ago by master@…

Attachment: patch-ncursesw-Portfile added

install headers to /opt/local/include

comment:1 Changed 13 years ago by master@…

Anybody there?

comment:2 Changed 13 years ago by nox@…

Cc: imajes@… nox@… added

comment:3 Changed 13 years ago by ryandesign (Ryan 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?

comment:4 Changed 13 years ago by 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 ;)

Changed 13 years ago by master@…

Attachment: Portfile added

Portfile for a test port for Ryan

Changed 13 years ago by master@…

Attachment: tclock-1.tar.gz added

test program for Ryan

comment:5 Changed 13 years ago by 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.

comment:6 Changed 12 years ago by (none)

Milestone: Port Bugs

Milestone Port Bugs deleted

comment:7 Changed 11 years ago by nox@…

Resolution: fixed
Status: newclosed

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

comment:8 Changed 11 years ago by 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.

comment:9 in reply to:  8 Changed 10 years ago by master@…

Resolution: fixed
Status: closedreopened

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.

comment:10 Changed 10 years ago by jmroot (Joshua Root)

Cc: imajes@… removed
Owner: changed from imajes@… to jmr@…
Port: ncurses ncursesw added
Status: reopenednew

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).

comment:11 Changed 10 years ago by pipping@…

Cc: pipping@… removed

comment:12 Changed 10 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.