Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
Message-ID:	<3B7185D0.3000607@ece.gatech.edu>
Date:	Wed, 08 Aug 2001 14:32:48 -0400
From:	Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent:	Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713
X-Accept-Language:	en-us
MIME-Version:	1.0
To:	"David A. Cobb" <superbiskit AT home DOT com>
CC:	Xemacs Beta Development MailList <xemacs-beta AT xemacs DOT org>,
	Cygwin General MailList <cygwin AT cygwin DOT com>
Subject:	Re: Problems building Xemacs-21.5--i686-pc-Cygwin: PART III :=(D
References:	<5 DOT 1 DOT 0 DOT 14 DOT 0 DOT 20010808122455 DOT 03c8d140 AT mail>

David A. Cobb wrote:

> As I reported earlier, I can't seem to get past missing symbols in gdbm.
> 
> For starters, I did (CVS update -r r25-1-latest-beta) to start the day 
> in synch.
> There were some updates taken, no indication in the ChangeLog.
> 
>  From .../xemacs-21.5/i686-pc-cygwin/ did ../configure [options shown 
> below], and make.  CFLAGS=--verbose.  I'm not sure what it's telling 
> me.  I see "-L/usr/lib" and that is where "libgdbm.dll.a" exists.  I 
> can't tell whether the compiler recognizes it.  Is  ".dll" in the name a 
> secret known to gcc?  


Not exactly.  It is a secret known to ld, which is called by gcc.


> checking for database support
> checking for ndbm.h... yes
> checking for dbm_open in -lgdbm... yes


This means that configure built a test program and successfully linked 
it to libgdbm.  So, that means you can successfully link to gdbm, and it 
is properly installed on your system.


>     Prepending "-lgdbm" to $LIBS
>     Defining HAVE_DBM

> /usr/bin/gcc -mcygwin --verbose ...


This is good.


> Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specs
> gcc version 2.95.3-5 (cygwin special)
>  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/collect2.exe --subsystem 
> windows -Bdynamic --dll-search-prefix=cyg -o temacs.exe /usr/lib/crt0.o 
> -L/usr/local/lib -L/usr/lib -L/usr/lib/w32api ...


But this is not good.  The second step (and most important) of my advice 
was to add "--verbose" to THIS command as well.  Then, ld/collect will 
explicitly list EVERY place it looks for EVERY dependency, indicating 
whether or not the search was successful for EACH case.

Add --verbose to the collect2 command (if you're really ambitions, 
change the executable to "ld" instead of "collect2").


> linuxplay.o(.text+0x124c):linuxplay.c: multiple definition of 
> `play_sound_file'
> ntplay.o(.text+0x418):ntplay.c: first defined here
> linuxplay.o(.text+0x12cc):linuxplay.c: multiple definition of 
> `play_sound_data'
> ntplay.o(.text+0x6f8):ntplay.c: first defined here


Didn't SOMEBODY suggest that you fix this linux sound problem FIRST, so 
that your link failures are single-cause, and not multiple-cause?  Why 
did you refuse to follow that advice?

I am going to stop responding to this thread until you follow the advice 

that has already been given.  why should anyone help you if their advice will 

only be ignored?

--Chuck





--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -