X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_83,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: sourceware.org Message-ID: <4A185E90.10704@cwilson.fastmail.fm> Date: Sat, 23 May 2009 16:37:36 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Static linking issue under cygwin. References: <4f8dccd00905231221v2f82acb9rcf1ffa9f228650be AT mail DOT gmail DOT com> In-Reply-To: <4f8dccd00905231221v2f82acb9rcf1ffa9f228650be@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Vladimir A. Petrov wrote: > Hello! > > I've faced with strange static linking issue in Cygwin environment. > Trivial C program can not be linked against PostgreSQL libpq with the > following diagnostics: > > $ gcc -Wall -I /cygdrive/c/Program\ Files/PostgreSQL/8.2/include/ -L > /cygdrive/c/Program\ Files/PostgreSQL/8.2/lib -lpq -o pgtest.exe > pgtest.c > /cygdrive/c/DOCUME~1/vap/LOCALS~1/Temp/cclXAlCk.o:pgtest.c:(.text+0x33): > undefined reference to `_PQconnectdb' > /cygdrive/c/DOCUME~1/vap/LOCALS~1/Temp/cclXAlCk.o:pgtest.c:(.text+0x78): > undefined reference to `_PQstatus' > /cygdrive/c/DOCUME~1/vap/LOCALS~1/Temp/cclXAlCk.o:pgtest.c:(.text+0x8c): > undefined reference to `_PQerrorMessage' > /cygdrive/c/DOCUME~1/vap/LOCALS~1/Temp/cclXAlCk.o:pgtest.c:(.text+0xc5): > undefined reference to `_PQfinish' > /cygdrive/c/DOCUME~1/vap/LOCALS~1/Temp/cclXAlCk.o:pgtest.c:(.text+0xd9): > undefined reference to `_PQfinish' > collect2: ld returned 1 exit status > > The library is at place and has those symbols defined > > $ nm /cygdrive/c/Program\ Files/PostgreSQL/8.2/lib/libpq.a | egrep > '(_PQconnectdb|_PQstatus|_PQerrorMessage|_PQfinish)' > 00000000 T _PQstatus > 00000000 I __imp__PQstatus > 00000000 T _PQfinish > 00000000 I __imp__PQfinish > 00000000 T _PQerrorMessage > 00000000 I __imp__PQerrorMessage > 00000000 T _PQconnectdb > 00000000 I __imp__PQconnectdb > > This libpq.a is from PostgreSQL 8.2.9 distribution for win32. > My cygcheck.out is in the attachment. > > The similar problem is also reproducible at the another PC with > different Cygwin installation and with different set of libraries > (opengl-1.1.0-10 and freeglut-2.4.0-1) that in this case are part of > the Cygwin distribution and were installed via standard Cygwin setup > program. For details see attached fly-cubes-cygcheck.out and > fly-cubes-link-failure.out. Most strange thing that belongs to this > issue is that this sources could be successfully linked with the same > package about one month ago, but after some day it became broken > without any sight cause because Cygwing installation had never been > changed. > > Does anybody knows why this happens and how to solve this? Bad: $ gcc -Wall -I /cygdrive/c/Program\ Files/PostgreSQL/8.2/include/ -L /cygdrive/c/Program\ Files/PostgreSQL/8.2/lib -lpq -o pgtest.exe pgtest.c Good: gcc -Wall -I /cygdrive/c/Program\ Files/PostgreSQL/8.2/include/ -L /cygdrive/c/Program\ Files/PostgreSQL/8.2/lib -o pgtest.exe pgtest.c -lpq Bad: gcc -o fly-cubes.exe -lopengl32 -lglut32 -lglu32 fly-cubes.c Good: gcc -o fly-cubes.exe fly-cubes.c -lopengl32 -lglut32 -lglu32 Fair-to-poor: using gcc to go in one step from source code to executable. It works, but it hides some of the issues -- especially *linking* issues -- from you. You'd have an easier time diagnosing these problems if you broke it down into separate compile and link steps (this rule applies on unix, too): For example: gcc -o fly-cubes.o -c fly-cubes.c gcc -o fly-cubes.exe fly-cubes.o -lopengl32 -lglut32 -lglu32 (good) gcc -o fly-cubes.exe -lopengl32 -lglut32 -lglu32 fly-cubes.o (bad) Here, it is easy to see that the undefined symbols in fly-cubes.o are satisfied by libraries that follow it on the link command in the first case, but in the second case there is nothing "after" fly-cubes.o to do so. This is obscured when you compile-and-link in a single step -- when that works, great! but when it doesn't things are a bit opaque. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/