This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Problems building Xemacs-21.5--i686-pc-Cygwin: PART III :=(D


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]