> > Thanks for following up. I had even erased and re-installed cygwin to > > try to make sure it wasn't something in my setup. Attached is the > > output of 'cygcheck -svr'. > > Hmmm. I wonder if it's because my cygwin root is e:\cygwin. I just > installed cygwin's gcc onto another machine here (with cygroot = > c:\cygwin) and 'gcc -print-file-name=libc.a' yielded > '/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libc.a'. > Probably not. On the machine where I build XEmacs all the time, cygwin in installed inD:\cygwin and I still get '/usr/lib/...' out of 'gcc -print-file-name=libc.a'. Nothing jumps out at me from your cygcheck output. In particular, I was looking at your mount table, but I don't see anything obviously wrong with it. What does 'gcc -v' tell you?

----- Original Message ---- From: Vin Shelton <acs(a)xemacs.org&gt; To: Rick Rankin <rrankin1424-xemacs(a)yahoo.com&gt; Cc: xemacs-patches(a)xemacs.org; Dr. Volker Zell <dr.volker.zell(a)oracle.com&gt; Sent: Tuesday, January 24, 2006 10:08:33 AM Subject: Re: [PATCH 21.4] Xpm no-X builds fail on current cygwin > On 1/24/06, Rick Rankin <rrankin1424-xemacs(a)yahoo.com&gt; wrote: > > > > Thanks for following up. I had even erased and re-installed cygwin to > > > > try to make sure it wasn't something in my setup. Attached is the > > > > output of 'cygcheck -svr'. > > > > > > Hmmm. I wonder if it's because my cygwin root is e:\cygwin. I just > > > installed cygwin's gcc onto another machine here (with cygroot = > > > c:\cygwin) and 'gcc -print-file-name=libc.a' yielded > > > '/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libc.a'. > > > > > Probably not. On the machine where I build XEmacs all the time, > > cygwin in installed inD:\cygwin and I still get '/usr/lib/...' out > > of 'gcc -print-file-name=libc.a'. > > > > Nothing jumps out at me from your cygcheck output. In particular, > > I was looking at your mount table, but I don't see anything obviously wrong > > with it. What does 'gcc -v' tell you? > > gcc -v > Reading specs from /bin/../lib/gcc/i686-pc-cygwin/3.4.4/specs > Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose > --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib > --libexecdir=/usr/lib --mandir=/usr/share/man > --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,java,objc > --enable-nls --without-included-gettext > --enable-version-specific-runtime-libs --without-x > --enable-libgcj --disable-java-awt --with-system-zlib > --enable-interpreter --disable-libgcj-debug --enable-threads=posix > --enable-java-gc=boehm --disable-win32-registry > --enable-sjlj-exceptions --enable-hash-synchronization > --enable-libstdcxx-debug : (reconfigured) > Thread model: posix > gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Interesting. Here's what I get: $ gcc -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug : (reconfigured) Thread model: posix gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Notice the 'Reading specs' line. Right now, I have no idea what would cause gcc to get its path munged like this. I can't help but wonder if somehow your mount table has something wrong, although I didn't see anything in your cygcheck output. The only thing I can think of to try would be to completely recreate your mount table. * run 'mount -m >remount.bat' from bash * exit all cygwin-related processes * blow away your mount table by using regedit to delete 'HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions' * start cmd.exe and run 'remount.bat' * reboot (the Windows sysadmin mantra ;-) It wouldn't hurt anything, but based on what *I* see in your cygcheck output, it shouldn't change anything, either. I guess the next step would be to ask on the cygwin list.

----- Original Message ---- From: Vin Shelton <acs(a)xemacs.org&gt; To: Rick Rankin <rrankin1424-xemacs(a)yahoo.com&gt; Cc: xemacs-patches(a)xemacs.org; Dr. Volker Zell <dr.volker.zell(a)oracle.com&gt; Sent: Tuesday, January 24, 2006 2:24:01 PM Subject: Re: [PATCH 21.4] Xpm no-X builds fail on current cygwin > > Aha! It turns out it matters whether you run /bin/gcc or /usr/bin/gcc - > [ output elided ] > > I think my patch is good, because it supports both /bin/gcc and > /usr/bin/gcc :-) > > Rick and Volker - what do you think? > Well, it's nice to know what's going on. I verified on my system that I get the same output as you with /bin/gcc vs. /usr/bin/gcc. I went back and looked at the patch, but I think I need to look at the code in configure.ac. Basically, I'm not sure I understand why we need all this machinery to begin with. What all this evaluates to is '/usr/include', which is what it should evaluate to on every cygwin system, regardless of where cygwin is installed. The non-x version of XPM is in /usr/include/noX. It's not clear to me what all this extra machinery is buying us. If the header files aren't in those locations for some reason, it's not clear to me that any of this is going to work, anyway. In fact, the existing code didn't work when I had a home-grown version of gcc installed for a while. I had to force configure/make to use the version of gcc that is packaged with cygwin. Also, it appears from some of the surrounding patch text that the mingw headers are being included in a cygwin build, which would not be correct. Again, though, I need to look at this in more context which I won't be able to do until this evening at the earliest.