DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:cc:subject:date:message-id
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	default; b=rIWvmaeKv3qSZ2kMNqfqV1L2iILIe7o/q27nooGe/tVUsSsdzYdnF
	wLS3VQkTGpyXgiV9uO9PThBQxnfUiraG+uhdTlazSvMoKXofQecUTdP5QXCqhbKa
	+9BbIJJeHtCmr1Wclu+bCP7efzMGpg2xGdqlnV1IcSrifZ1eNTGCc0=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
From: Pavel Fedin <p.fedin@samsung.com>
To: bug-make@gnu.org
Cc: cygwin@cygwin.com
Subject: [BUG] GNU Make - bad default .LIBPATTERNS on Windows/Cygwin
Date: Fri, 10 Jan 2014 15:49:35 +0400
Message-id: <001601cf0dfa$09311370$1b933a50$%fedin@samsung.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit

 Hello! I've just discovered one more bug in GNU Make under Cygwin.

 Make is able to understand -lfoo as depencencies and tries its best to look
up libraries correctly. However in some situations it fails to do so because
it lacks proper templates for Cygwin.
 The problem is fixed by adding the following proper definitions to
default.c:
--- cut ---
#elif defined(__CYGWIN__) || defined(WINDOWS32)
    ".LIBPATTERNS", "lib%.dll.a %.dll.a lib%.a %.lib lib%.dll %.dll",
--- cut ---
 I have obtained these rules from GNU ld source code:
http://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=ld/emultemp
l/pe.em;h=5d6da9e05f14425cfad9cc4ec71e1a20e450b336;hb=HEAD#l2068
 Since this file is for all PE targets, i suggest that the same applies also
to native Windows target.

 The problem was triggered by attempting to rebuild nfs-server package with
tirpc library. Its makefiles list $(LIBS) as dependencies. tirpc package for
x86-64 for some reason does not include static version libtirpc.a, only
libtirpc.dll.a. This caused the failure.

 I decided to cross-post this also in Cygwin ML for convenience.

 By the way... A good question: is this approach correct ? Actually i could
cross-compile this package for e.g. Linux host, and in this case i would
have come to the inversed version of the same problem. May be Make could be
more smart and somehow know for which target we are compiling ? For example,
this could be done by calling $(CC) -dumpmachine (in case of gcc >= v4). Or
could it check something like $(HOST) set by makefile ?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple