Opened 2 years ago

Last modified 2 years ago

#57160 new defect

MacPorts base readline support is not compatible with MacPorts readline port

Reported by: lemzwerg (Werner Lemberg) Owned by:
Priority: Normal Milestone:
Component: base Version:
Keywords: Cc:


[macports-base 60483e6e71054bcd741a55901c52117077ec7c43]
[macports-ports a8142c5ae7ce0d22f883033cfb35c00c2bb4c081]


./configure --enable-readline --with-curlprefix=/opt/local

followed by


to update the port program yields a compilation error:

===> making all in src/pextlib1.0
clang -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -std=c99 \
  -Wextra -Wall -pedantic  -I/opt/local/include   -DHAVE_CONFIG_H \
  -I/opt/macports/macports-base/src \
  -I/opt/macports/macports-base/src -I. \
  -I/opt/macports/macports-base/vendor/vendor-destroot/opt/local/libexec/macports/include \
  -I./../compat -fno-common readline.c -o readline.o

readline.c:133:23: error:
  use of undeclared identifier 'username_completion_function';
  did you mean 'rl_username_completion_function'?
readline.c:54:39: note:
  expanded from macro 'USERNAME_COMPLETION_FUNCTION'
  #define USERNAME_COMPLETION_FUNCTION username_completion_function
/opt/local/include/readline/readline.h:465:14: note:
  'rl_username_completion_function' declared here
extern char *rl_username_completion_function
                    PARAMS((const char *, int));
1 error generated.

Reason is a sloppy test checking the existence of function rl_username_completion_function (and other readline functions): It uses different CFLAGS values for configuring and compiling. In particular, compilation of file readline.c uses the value of CURL_CFLAGS: It adds -I/opt/local/include, which enables a newer MacPorts version of readline.h (7.0 GNU, from 2016) that is not compatible with Lion's version (NetBSD, from 2009).

Looking into src/pextlib1.0/ I see


so I suggest to use those flags for checking readline functions also.

BTW, I circumvented the issue by using

./configure ac_cv_have_decl_rl_username_completion_function=yes \
            --enable-readline \

which gives me a port program that successfully supports downloading packages from github.

Change History (4)

comment:1 Changed 2 years ago by ryandesign (Ryan Schmidt)

Summary: macports-base: Options `--enable-readline` and `--with-curlprefix` fail on LionMacPorts base readline support is not compatible with MacPorts readline port

We usually suggest removing the MacPorts prefix from $PATH before configuring MacPorts, since otherwise it will find readline installed by MacPorts, with which it is not compatible, as you've noticed. It is only compatible with readline (actually editline) installed by macOS. I'm sure I've reported that bug before but I can't find it right now.

comment:2 Changed 2 years ago by raimue (Rainer Müller)

MacPorts is intended to be linked with the system libraries of macOS and not with libraries provided by port. Linking MacPorts to itself creates a circular dependency that is not respected in any way during operation and may lead to failures.

While it would not hurt to broaden the compatiblity with other readline/editline implementations as an enhancement, I would say this is not a defect.

comment:3 Changed 2 years ago by lemzwerg (Werner Lemberg)

OK, issue understood. Thanks for the comments. So the bug is that --with-curlprefix accepts /opt/local, which should be rejected or filtered out as is already done with $PATH.

comment:4 Changed 2 years ago by lemzwerg (Werner Lemberg)

BTW, can someone please explain what exactly the incompatibility to other readline implementations is? AFAICS, it's really just a bad setup of that prevents the correct use of the rl_ prefix necessary for more recent readline implementations – the code in readline.c seems already be prepared.

Last edited 2 years ago by lemzwerg (Werner Lemberg) (previous) (diff)
Note: See TracTickets for help on using tickets.