Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 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" CC: Xemacs Beta Development MailList , Cygwin General MailList 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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/