From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4583 invoked by alias); 28 Feb 2002 23:55:15 -0000 Mailing-List: contact sourcenav-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sourcenav-owner@sources.redhat.com Received: (qmail 4525 invoked from network); 28 Feb 2002 23:55:15 -0000 Received: from unknown (HELO hammerhead.steptech.com) (207.138.226.2) by sources.redhat.com with SMTP; 28 Feb 2002 23:55:15 -0000 Received: from shasta.pdx.steptech.com (shasta.pdx.steptech.com [172.16.0.135]) by hammerhead.steptech.com (8.9.3/8.9.3) with ESMTP id PAA03729 for ; Thu, 28 Feb 2002 15:55:14 -0800 Received: by shasta.pdx.steptech.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 15:55:14 -0800 Message-ID: <26F9F6EAB586D411850700B0D049E6E4014D2E84@shasta.pdx.steptech.com> From: Bruce Edson To: sourcenav Subject: RE: Trouble building grep portion of Source Navigator Date: Tue, 05 Mar 2002 10:53:00 -0000 X-Mailer: Internet Mail Service (5.5.2653.19) X-SW-Source: 2002-q1/txt/msg00141.txt.bz2 Thanks Mo for looking at this. I've been using export="cl.exe". It's only slightly different than what you suggest. Do you think it would make a difference? Bruce -----Original Message----- From: Mo DeJong [mailto:supermo@bayarea.net] Sent: Thursday, February 28, 2002 2:12 PM To: sourcenav Subject: Re: Trouble building grep portion of Source Navigator On Thu, 28 Feb 2002 08:54:34 -0800 Bruce Edson wrote: > First problem encountered: > > It appeared that a portion of grep compiles. It then runs into a problem > with a missing libintl.h file. When I look into the include directory > ../intl, sure enough the file is there, but, it is a Windows shortcut file > to libgettext.h back in the source tree. I wasn't aware that Make would > work with shortcut files. If I replace the shortcut with a real version of > the file (not libgettext.h), I get past this problem. Why is this shortcut > file being created for me? Also, if I use '--with-included-gettext' for > configure, the problem still exists, even though this would suggest > eliminating the need for libintl.h. Any ideas? Groan! I looked in grep/configure.in and found this: dnl FIXME: this overcomes a flaw in using non-Cygwin tools with symlinks. if test x$ac_cv_prog_CC = xcl ; then AC_MSG_RESULT([copying libgettext.h to intl/libintl.h]) if test -f $nls_cv_header_intl ; then rm $nls_cv_header_intl fi cp $srcdir/$nls_cv_header_libgt $nls_cv_header_intl fi Looks like you need to use export CC=cl to get around that. > Second problem encountered: > > After copying a real libintl.h file into ../grep/intl, the make compiles > the c files okay and then tries to work with a file called libintl.a. I get > the following output. Could anyone give me a clue as to what is going > wrong? Is there an incompatability with VC++ compiler/linker? I tried > adding '--with-included-gettext' to the configure and starting over with a > clean build directory. No change. > > cl.exe -Z7 -Od -o grep.exe grep.obj dfa.obj kwset.obj obstack.obj > getopt.obj > getopt1.obj search.obj btowc.obj regex.obj ../intl/libintl.a > Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for > 80x86 > Copyright (C) Microsoft Corp 1984-1998. All rights reserved. > > Command line warning D4024 : unrecognized source file type > '../intl/libintl.a', This is just a goofy hack in the old grep build system. It should not cause problems linking. > ../intl/libintl.a > regex.obj : error LNK2001: unresolved external symbol _alloca > libintl.a(dcgettext.obj) : error LNK2001: unresolved external symbol > _alloca > libintl.a(localealias.obj) : error LNK2001: unresolved external symbol > _alloca > grep.exe : fatal error LNK1120: 1 unresolved externals > make[3]: *** [grep.exe] Error 2 > make[3]: Leaving directory `/cygdrive/c/snkeck/snbuild/grep/src' This is also caused by the CC=cl thing. >From configure.in: if test x$ac_cv_prog_CC = xcl ; then AC_DEFINE(alloca, _alloca) fi cheers Mo