help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "Cannot open termcap database file"


From: kj
Subject: Re: "Cannot open termcap database file"
Date: Sun, 19 Dec 2010 18:23:37 +0000 (UTC)
User-agent: nn/6.7.3

In <mailman.0.1292767444.12385.help-gnu-emacs@gnu.org> Nevo 
<sakur.deagod@gmail.com> writes:

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]