This is the mail archive of the 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?


Unsubscribe info:
Bug reporting:

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