From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Building Emacs with GnuTLS on Windows Date: Fri, 29 Apr 2011 12:09:41 +0300 Message-ID: <83k4ed77ai.fsf@gnu.org> References: <8362pz84nu.fsf@gnu.org> <83y62u6s9i.fsf@gnu.org> <83vcxy6rn2.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1304068195 26242 80.91.229.12 (29 Apr 2011 09:09:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 29 Apr 2011 09:09:55 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Apr 29 11:09:51 2011 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QFjhv-0007EW-5l for geh-help-gnu-emacs@m.gmane.org; Fri, 29 Apr 2011 11:09:51 +0200 Original-Received: from localhost ([::1]:37095 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFjhu-0004eT-IL for geh-help-gnu-emacs@m.gmane.org; Fri, 29 Apr 2011 05:09:50 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:43980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFjho-0004eD-Tg for help-gnu-emacs@gnu.org; Fri, 29 Apr 2011 05:09:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QFjhn-0004hV-SE for help-gnu-emacs@gnu.org; Fri, 29 Apr 2011 05:09:44 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:63089) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFjhn-0004hI-KC for help-gnu-emacs@gnu.org; Fri, 29 Apr 2011 05:09:43 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LKE00C00PAGAN00@a-mtaout23.012.net.il> for help-gnu-emacs@gnu.org; Fri, 29 Apr 2011 12:09:41 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.124.209.153]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LKE00CHRPG423B0@a-mtaout23.012.net.il> for help-gnu-emacs@gnu.org; Fri, 29 Apr 2011 12:09:41 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.175 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:80872 Archived-At: > From: Deniz Dogan > Date: Fri, 29 Apr 2011 10:10:19 +0200 > Cc: help-gnu-emacs@gnu.org > > I didn't think that PROCESSOR_ARCHITECTURE would change after > configuring/making, so the results I got last time were from a "clean" > cmd.exe. Sorry about that. The "real" value is x86. Sorry, I still don't understand. PROCESSOR_ARCHITECTURE doesn't change after configuring/making, it's just that make.exe, as a 32-bit application running on a 64-bit Windows, should see the x86 value in that environment variable. Windows itself takes care of that when it constructs the environment passed to make.exe. And since Make automatically converts all the environment variables into Make variables available in the Makefile, the test before line 161 should have succeeded to detect your architecture as "x86". Which part of this didn't work, and why? And what does "a clean cmd.exe" mean, anyway? In sum, I'm still unsure how that problem happened to you and what solved it. I need to determine whether there's some general problem in the Windows configury that rears its ugly head on a 64-bit Windows, or maybe it was due to some one-time local cockpit error on your side. Please help me understand which one is it. If it's your local error, please explain what did you do differently during the botched bootstrap. Maybe you need to try a clean bootstrap again in a fresh tree, to reproduce the problem? If you do succeed in reproducing it, please don't update from the repository until we understand the reason(s), because new changes can obscure the original problem. TIA > However, I'm having even more problems. This time, when I bootstrap I get this: > > c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../../mingw32/bin/ld.exe: > cannot find -lC:/gnutls/lib > c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../../mingw32/bin/ld.exe: > cannot find -lC:/gnutls/bin That's because your configure arguments are incorrect: > c:\repos\emacs-trunk\nt>configure.bat --without-png --without-jpeg > --without-gif --without-tiff --without-xpm --prefix=C:\emacs > --cflags="-IC:/gnutls/include" --lib=C:/gnutls/lib --lib=C:/gnutls/bin ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The --lib switch tells the compiler the _names_of_the_libraries_ it needs to link in, not the directory where to find those libraries. You need to use --ldflags=-LC:/gnutls/lib --ldflags=-LC:/gnutls/bin instead (note: upper-case "L"). I believe the Windows configury already knows the names of the gnutls libraries in those directories, so you don't need to use the --lib switches in this case. Btw, why do you make your life harder by installing support libraries outside the main MinGW include/, lib/ and bin/ directories? That just doesn't make any sense: once you have these libraries installed, they should be available to any build of any program you compile with MinGW, without any futzing with the -I or -L compiler switches. Install them in the standard places, and you will never again need to use these tricksy --cflags, --ldflags etc. switches, ever.