"Cannot open termcap database file"
kj
The Emacs port provided by MacPorts (Emacs 23.2.1) won't start on
OS X Snow Leopard.
The error message is:
emacs: "Cannot open termcap database file"
This error has already been reported to MacPorts, but there's no
activity on fixing the problem, so I want to try fix it myself.
The first thing to figure out is where is Emacs looking for this
termcap file? I want to determine whether it is missing altogether,
or is there but is inaccessible to Emacs for some reason.
Can someone tell me what filenames and directories to search for
this file?
Second, supposing it is missing, where can I find a suitable termcap
database file? Alternative, is there a way to circumvent this
requirement?
Thanks!
~kj
P.S. The Emacs that comes with OS X starts up, but it is version
22, but I installed the MacPorts port of Emacs because I needed
version 23.
des...@verizon.net
> The Emacs port provided by MacPorts (Emacs 23.2.1) won't start on
> OS X Snow Leopard.
>
> The error message is:
>
> emacs: "Cannot open termcap database file"
My guess is that emacs is really looking for a terminfo
file. When it didn't find that, it then tried the older termcap.
Anyway, not an OS X user, but check this first:
http://discussions.apple.com/thread.jspa?messageID=10589416&tstart=0
If that doesn't help, look around for a terminfo file, it will probably
be part of the libncurses package.
Peter Dyballa
> kj writes:
>
>> The Emacs port provided by MacPorts (Emacs 23.2.1) won't start on
>> OS X Snow Leopard.
>>
>> The error message is:
>>
>> emacs: "Cannot open termcap database file"
You better report this problem as a MacPorts bug (https://trac.macports.org/
) – besides: does the problem also exist when you launch GNU Emacs
with -Q?
--
Greetings
~ O
Pete ~~_\\_/%
~ O o
Nevo
kj
In <icr5deq...@verizon.net> des...@verizon.net writes:
>If that doesn't help, look around for a terminfo file, it will probably
>be part of the libncurses package.
Thanks for the pointer! Once I find a terminfo file (assuming I
do), where should I put it so that Emacs finds it?
BTW, and FWIW, I get the same error message I posted earlier if I
include -Q in the Emacs invocation.
~kj
kj
>--0016e659fd08de96010497c3df39
>Content-Type: text/plain; charset=ISO-8859-1
>Try to install libncurse-dev first via MacPort, then rebuild the Emacs23,
>then probably you should go without this problem.
I can't find that port in MacPorts:
% port search libncurse-dev
No match for libncurse-dev found
...but that idea was on the right track.
I figured out and solved the problem (thanks to the clues I got
from your responses). I post the fix here for anyone else who may
have this problem.
The following excerpt from the config.log file shows the root of
the problem:
configure:20977: checking for tparm in -lncurses
configure:21012: /usr/bin/gcc-4.2 -I/sw/include -L/sw/lib -o conftest -pipe -O2 -arch x86_64 -D_REENTRANT -I /opt/local/include/librsvg-2.0 -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -I/opt/local/include/gdk-pixbuf-2.0 -I/opt/local/include/cairo -I/opt/local/include/libpng12 -I/opt/local/include/pixman-1 -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include -I/opt/local/include/freetype2 -L/opt/local/lib -arch x86_64 conftest.c -lncurses -lm -lXrender -L/opt/local/lib -lXft -lXrender -lfontconfig -lexpat -liconv -lfreetype -lz -lX11 -lxcb -lXau -lXdmcp -lXext -lXmu -lXt -lSM -lICE -L/opt/local/lib -lrsvg-2 -lgio-2.0 -lgdk_pixbuf-2.0 -lm -lcairo -lgmodule-2.0 -lgobject-2.0 -lpixman-1 -lfontconfig -lexpat -lfreetype -lpng12 -lz -lXrender -lgthread-2.0 -lglib-2.0 -lintl -liconv -lX11 -lxcb -lXau -lXdmcp -lX11 -L/opt/local/lib -ldbus-1 -lpthread >&5
ld: warning: in /sw/lib/libncurses.dylib, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in /sw/lib/libiconv.dylib, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in /sw/lib/libintl.dylib, file was built for i386 which is not the architecture being linked (x86_64)
Undefined symbols:
"_tparm", referenced from:
_main in ccaYZh71.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
configure:21019: $? = 1
You see the paths /sw/lib and /sw/include ? Those refer to old
packages installed long ago using a different packaging system,
Fink.
The fundamental issue is that the MacPort checks for the MacPorts
ncurses when computing the dependencies for Emacs, and downloads
the necessary versions, but then, at the time of building Emacs,
it does not ensure that it is actually using this version!
I don't know how those /sw/* paths made it among the paths that
the configure program examines. The full configure command does
not mention them at all:
CPATH='/opt/local/include' CFLAGS='-pipe -O2 -arch x86_64' CPPFLAGS='-I/opt/local/include' CXXFLAGS='-pipe -O2 -arch x86_64' LIBRARY_PATH='/opt/local/lib' MACOSX_DEPLOYMENT_TARGET='10.6' CXX='/usr/bin/g++-4.2' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_editors_emacs/work/.CC_PRINT_OPTIONS' F90FLAGS='-pipe -O2 -m64' LDFLAGS='-L/opt/local/lib -arch x86_64' OBJC='/usr/bin/gcc-4.2' FCFLAGS='-pipe -O2 -m64' INSTALL='/usr/bin/install -c' OBJCFLAGS='-pipe -O2 -arch x86_64' FFLAGS='-pipe -O2 -m64' CC_PRINT_OPTIONS='YES' CC='/usr/bin/gcc-4.2' ./configure --prefix=/opt/local --with-dbus --without-gconf --without-libotf --without-m17n-flt --without-gpm --infodir /opt/local/share/info/emacs --with-x-toolkit=lucid --without-xaw3d --with-xpm --with-jpeg --with-tiff --with-gif --with-png --with-rsvg --with-xft
...and the environment of the user during the installation does not
mention /sw/{lib,include} at all:
% (sudo printenv | grep -e /sw/lib -e /sw/include) || echo "no match"
Password:
no match
Neither are they mentioned at all in the macports.conf configuration
file...
So it looks like some sort of leak in MacPorts, but I can't locate
it.
Be that as it may, once the problem was identified, the fix was
easy:
% sudo mv /sw /sw_DISABLE
% sudo port -u uninstall emacs@23.2_3+x11
% sudo port clean --all emacs@23.2_3+x11
% sudo port -d install emacs@23.2+x11
From the output of the re-install's configure step, I can see that
the renaming of /sw had the desired effect:
checking for tparm in -lncurses... yes
Yes!
And, most importantly, the new Emacs starts without a hiccup!
Of course, I expect that in the near future, something that has a
dependency under the now non-existent /sw will complain (that's
why I did not obliterate /sw outright).
But I'll cross that bridge when I get to it. Now, I'm getting
myself a beer...
Cheers!
~kj
Peter Dyballa
Am 19.12.2010 um 19:23 schrieb kj:
> % (sudo printenv | grep -e /sw/lib -e /sw/include) || echo "no match"
> Password:
> no match
PATH and PKG_CONFIG_PATH could be a cause.
--
Greetings
Pete
The light at the end of the tunnel has been turned off due to budget
cuts.