From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: kj Newsgroups: gmane.emacs.help Subject: Re: "Cannot open termcap database file" Date: Sun, 19 Dec 2010 18:23:37 +0000 (UTC) Organization: none Message-ID: References: NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1292785523 22728 80.91.229.12 (19 Dec 2010 19:05:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 19 Dec 2010 19:05:23 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Dec 19 20:05:19 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PUOZF-000750-Of for geh-help-gnu-emacs@m.gmane.org; Sun, 19 Dec 2010 20:05:18 +0100 Original-Received: from localhost ([127.0.0.1]:35864 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PUOYn-0001Vw-CL for geh-help-gnu-emacs@m.gmane.org; Sun, 19 Dec 2010 14:04:45 -0500 Original-Path: usenet.stanford.edu!panix!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 92 Original-NNTP-Posting-Host: panix2.panix.com Original-X-Trace: reader1.panix.com 1292783017 1104 166.84.1.2 (19 Dec 2010 18:23:37 GMT) Original-X-Complaints-To: abuse@panix.com Original-NNTP-Posting-Date: Sun, 19 Dec 2010 18:23:37 +0000 (UTC) X-No-Confirm: yes User-Agent: nn/6.7.3 Original-Xref: usenet.stanford.edu gnu.emacs.help:183432 X-Mailman-Approved-At: Sun, 19 Dec 2010 14:03:25 -0500 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:77680 Archived-At: In Nevo 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