Any plans to incorporate UTF-8 support into Cygwin?
There's already a patch that purports to be fairly complete, which modifies Cygwin so that its paths are UTF-8: http://www.okisoft.co.jp/esc/utf8-cygwin/ It's extremely annoying now that Cygwin cannot reliably work with file names containing non-ASCII non-Latin1 characters (and even with Latin-1 chars it may be touch and go). NOTE: Such filenames come up a lot for me, even though I'm a native US speaker. Stuff downloaded using P2P may often have foreign words in it or foreign notations in brackets, music tracks from foreign bands often have foreign characters in the filenames, etc. If a directory has a foreign-named file anywhere in it, both cp -a and tar-cp will fail to copy the directory properly, mangling the filenames in the process. Any plans to incorporate this fix into mainline Cygwin? I'd rank it pretty high priority, and it shouldn't be too hard to do. ben -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
free NFS client for Cygwin and/or support for FUSE?
Is there a free NFS client anyone can recommend that works will with Cygwin? Also, has anyone considered building something like FUSE into Cygwin? FUSE is a package for creating user-mode filesystems in Linux. It requires a certain amount of kernel support; but I can't see how it would be difficult to adapt for Cygwin. That, in turn, would allow all sorts of nice file systems to be added -- e.g. the sshfs, which allows you to mount a remote ssh connection as a file system; CVSFS, which shows the different revisions of CVS repositories as different files, somewhat ala ClearCase; WikipediaFS, for mounting Wikipedia as a file system (easier to change than going through the normal interface); archivemount (mounting tar, cpio, etc. archives as directories); etc. The result would be Cygwin-specific, i.e. wouldn't work in non-Cygwin utilities, but that's OK; the benefit of having such a system would be so great that it would vastly outdo the trouble of not being able to use non-Cygwin utils. ben -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
questions about excessive disk usage when doing tab completion
I am using zsh on the latest cygwin and the first time I load it up and try to do tab completion on e.g. /mnt/g/download/TAB, it spends an inordinate amount of time grinding the disk -- sometimes on the order of 2 minutes or more. the directory contains only 8 subdirs: /ben/ut/os-fall-2006 18:25 2012% ls -l /mnt/g/download total 0 drwxrwxrwx+ 6 Ben None 0 Oct 21 16:59 cygwin/ drwxrwxrwx+ 3 Ben None 0 Oct 20 15:57 emule/ drwxrwxrwx+ 3 Ben None 0 Oct 21 18:26 emule-incomplete/ drwxrwxrwx+ 33 Ben None 0 Oct 12 04:22 useful books/ drwxrwxrwx+ 160 Ben None 0 Oct 16 11:03 utorrent/ drwxrwxrwx+ 19 Ben None 0 Oct 16 11:03 utorrent-incomplete/ drwxrwxrwx+ 2 Ben None 0 Oct 16 11:03 utorrent-torrents/ drwxrwxrwx+ 2 Ben None 0 Oct 16 11:03 utorrent-torrents-incomplete/ granted, the subdirs have a lot in them; evidently it's grinding its way through all of the subdirs. but why? anyone seen this before? it does not seem to be specific to zsh, as i'm almost positive i've seen similar behavior under bash. it consistently happens when your machine has just been rebooted or its file cache is otherwise empty, but not easily repeatable otherwise. ben -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Ssh ignores $HOME
I've cc'ed cygwin@cygwin.com because I've apparently identified a problem with Cygwin's ssh. Ben And I don't know what to do. This is the same request that comes Ben out of using `crw'. Everything in .ssh/ is exactly as it was on Ben the old machine. My guess is that you have a different global setting for protocol version 1 vs. 2. Could you post the output of ssh -v cvs.xemacs.org All right, that identified the problem: /ben 18% ssh -v cvs.xemacs.org OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004 debug1: Connecting to cvs.xemacs.org [130.225.247.90] port 22. debug1: Connection established. debug1: identity file /home/Ben/.ssh/identity type -1 debug1: identity file /home/Ben/.ssh/id_rsa type -1 debug1: identity file /home/Ben/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1 debug1: match: OpenSSH_3.9p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.9p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server-client aes128-cbc hmac-md5 none debug1: kex: client-server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'cvs.xemacs.org' is known and matches the RSA host key. debug1: Found key in /home/Ben/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug1: Next authentication method: publickey debug1: Trying private key: /home/Ben/.ssh/identity debug1: Trying private key: /home/Ben/.ssh/id_rsa debug1: Trying private key: /home/Ben/.ssh/id_dsa debug1: Next authentication method: keyboard-interactive debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug1: Next authentication method: password [EMAIL PROTECTED]'s password: The problem is that /home/Ben is the wrong (and nonexistent, until created by ssh) directory. My home directory is /ben. For some reason, this version of ssh is ignoring $HOME (despite its documentation) and arbitrarily looking in /home/$USERNAME. A symlink fixed the problem; but any suggestions as to what is going on here? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Ssh ignores $HOME
What in ssh's documentation says that it will *use* $HOME to determine where your .ssh directory is? The documentation uses $HOME for notational convenience and says that it will *set* HOME in the ssh environment AFAICS. Your $HOME directory in a ssh session under Cygwin is determined the same way it's determined in a local shell session. Your home directory is defined in /etc/passwd. Ack, the thinko strikes again ... Thanks for the correction. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: How to make `mv the hard way' fail
If you have enough disk space you could do cp -pr FROM TO followed by rm -rf FROM if there are no errors reported by the cp command. You could do a diff -qr FROM TO before the rm to feel even safer. You could even write a little shell script that does the above, name it mv, and put it in /usr/local/bin or some other place that comes before mv.exe in your path. If you really wanted to, that is. :) Maybe someone could add an option to `mv' to make it fail rather than copy/rm? E.g. --no-copy. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
How to make `mv the hard way' fail
Apologies if this is a FAQ. When I use `mv' on a directory and any file within it happens to be locked for some reason [e.g. I've opened it in Word], it will try to copy the entire directory and then delete the original. I consider this very dangerous behavior to be happening without my specifically requesting it, and I'd like to make this fail rather than doing this. Is there any option in Cygwin to disable this? Usually it is very easy to fix the problem, but I want to be told about it rather than having to ^C the mv and hope I caught it before it was in the middle of deleting the original. Thanks. ben -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Please help: fixup_after_exec problem
Jerry Jones wrote about this problem: http://sources.redhat.com/ml/cygwin/2004-10/msg00942.html I'm the one getting this problem. I have gotten this *consistently* for the last two months every time I try to run any version of XEmacs compiled under Cygwin. Nothing obvious changed in XEmacs to trigger this, and it seems to happen even when I compile old versions of XEmacs that have not been changed and used to work fine. I am one of the main developers of XEmacs -- usually the heaviest contributor, in fact -- and this problem makes it impossible for me to test XEmacs under X Windows or in any Unix-like environment. No one has responded to this. Could one of the Cygwin engineers give me some sort of feedback on what's going on here? Thanks. ben -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Weird interaction between Visual C++ and Cygwin
If any Cygwin program is running, e.g. a compilation, Visual C++ takes an incredibly long time to start up. This has been the case for me for years. Does anyone know if there is some sort of locking contention here? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Bad interaction -- alternate console buffer and console history
I apologize if this is a FAQ. One of the clever features of the `cygwin' TERM type is that programs like `man' and `more' and others switch to a secondary screen buffer, so that when you exit the program, you get back the original buffer, uncluttered by the program's output. Unfortunately, this interacts extremely badly with the console history -- all console history is erased as soon as the secondary screen is invoked. Any plans to fix this? This is under W2k if it matters. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Weird bug with cp -f
Try this, latest Cygwin, Win2k latest: /xemacs/cygbuild/build-mule/src 2049% cat foo foo [hit ^D] /xemacs/cygbuild/build-mule/src 2050% od -bc foo 000 146 157 157 015 012 f o o \r \n 005 /xemacs/cygbuild/build-mule/src 2051% cp foo bar /xemacs/cygbuild/build-mule/src 2052% cp -f foo bar cp: writing `bar': Invalid request code /xemacs/cygbuild/build-mule/src 2053% ls -ld bar drwxrwxrwx+ 2 Ben Wing None0 Oct 2 22:40 bar/ /xemacs/cygbuild/build-mule/src 2054% Clever, no? Somehow, your file magically got converted into a directory ... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Scanf bug
Somehow or other, sscanf() has gotten messed up in recent Cygwin
installations.
Test program, with output:
/xemacs/test 2391% cat testscanf.c
int
main (int argc, char **argv)
{
int ret, cp1, cp2, endcount;
char *p = 0x7d 0x000E ;
ret = sscanf (p, %i %i%n, cp1, cp2, endcount);
printf (ret: %d cp1: %d cp2: %d endcount: %d\n, ret, cp1, cp2,
endcount);
printf (%d\n, endcount + strspn (p + endcount, \t\n\r\f));
return 0;
}
/xemacs/test 2392% gcc --verbose testscanf.c
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/specs
Configured with: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr
--exec-prefi
x=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/s
hare/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,java,objc,
pascal --enable-nls --without-included-gettext --enable-libgcj
--with-system-zli
b --enable-interpreter --enable-threads=posix --enable-java-gc=boehm
--enable-sj
lj-exceptions --disable-version-specific-runtime-libs
--disable-win32-registry
Thread model: posix
gcc version 3.3.3 (cygwin special)
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/cc1.exe -quiet -v -D__GNUC__=3
-D__GNUC_M
INOR__=3 -D__GNUC_PATCHLEVEL__=3 -D__CYGWIN32__ -D__CYGWIN__ -Dunix
-D__unix__ -
D__unix -idirafter
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../../include/w32
api -idirafter
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../../i686-pc-cygwin/
lib/../../include/w32api testscanf.c -quiet -dumpbase testscanf.c -auxbase
tests
canf -version -o /DOCUME~1/BENWIN~1/LOCALS~1/Temp/cco65aDq.s
GNU C version 3.3.3 (cygwin special) (i686-pc-cygwin)
compiled by GNU C version 3.3.3 (cygwin special).
GGC heuristics: --param ggc-min-expand=82 --param ggc-min-heapsize=98244
ignoring nonexistent directory /usr/i686-pc-cygwin/include
ignoring duplicate directory /usr/i686-pc-cygwin/lib/../../include/w32api
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/include
/usr/include
/usr/include/w32api
End of search list.
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../../i686-pc-cygwin/bin/as.exe
--t
raditional-format -o /DOCUME~1/BENWIN~1/LOCALS~1/Temp/ccSaWKvo.o
/DOCUME~1/BENWI
N~1/LOCALS~1/Temp/cco65aDq.s
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/collect2.exe -Bdynamic
--dll-search-prefi
x=cyg /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../crt0.o
/usr/lib/gcc-lib/i68
6-pc-cygwin/3.3.3/crtbegin.o -L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3
-L/usr/lib/
gcc-lib/i686-pc-cygwin/3.3.3/../../..
/DOCUME~1/BENWIN~1/LOCALS~1/Temp/ccSaWKvo.
o -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc
/usr/lib/gcc-lib
/i686-pc-cygwin/3.3.3/crtend.o
/xemacs/test 2393% a
ret: 2 cp1: 125 cp2: 14 endcount: 11
11
The value of endcount should be 13, not 11. The problem is with hex numbers
with more than one leading 0. Change 0x000E to 0x0FFE or 0xFFFE and you get
13. Change it to 0x00EE and you get 12. In all cases cp2 is correct.
This used to work. I know because the above code is part of XEmacs and we
are getting lots of warnings as a result of this bug, which didn't used to
be there, and the code hasn't changed.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
cygwin hanging/wedging, again
i've heard no responses at all to my previous message concerning cygwin hanging. there appear to be various different problems going on. 1] calling telnet from within expect results in telnet.exe wedging with 100% CPU time. at one point i saw a send: invalid spawn id (4) while executing send \r [i.e. my login] (file /ben/bin/t66 line 5) coming from expect. i don't know if this makes any difference. 2] printing out weird characters from within a telnet results in telnet.exe wedging with 100% CPU time. perhaps same as previous. this is highly predictable if i run tail [or probably just cat] on my procmail.log file. last time i tried it, it hung on this line: Subject: (RAZOR2_CHECK) (PYZOR_CHECK) (DCC_CHECK) (RCVD_IN_SBL) You\x92ve been se which has only one weird character in it. i've tried attaching to the telnet process, but the backtrace is garbage: #0 0x77fa144c in ntdll!DbgUiConnectToDbg () from /WINNT/system32/NTDLL.DLL #1 0x7c57feb4 in KERNEL32!DebugActiveProcess () from /WINNT/system32/KERNEL32.DLL #2 0x7c57b382 in lstrcmpiW () from /WINNT/system32/KERNEL32.DLL #3 0x0629fcbc in ?? () #4 0x77f98191 in wcstoul () from /WINNT/system32/NTDLL.DLL 3] running bash from a .bat file. this is what i've got: @echo off rem Cygwin's original had these two lines but none of the set lines. rem #c: rem chdir \bin set MAKE_MODE=unix set CYGWIN=tty set PATH=C:\bin;C:\usr\local\bin;%PATH% bash --login -i it's bound to a button on a toolbar across the bottom of the screen. when i run it, much of the time the console opens and then bash wedges. this is *NOT* a new problem; i've seen it for years. interestingly, if you hit the spacebar a couple of times when the console first opens, you never get wedging. no cpu time associated with the wedged bash; HOWEVER, i left some of these wedged consoles sitting for awhile, and 12 hours later noticed that two of them were pegging at 100% cpu, and some 7000 page faults per second! i have no idea what was happening. anyone have any hints, suggestions, etc.? the telnet problem in particular is extremely annoying. ben the hanging that i've seen appearing recently always seems to happen inside of a telnet session. it's possible that it's not actually new, since when i think about it -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
hangs with recent cygwin versions
i am using the latest 1.5.5-1, with everything updated via setup within the last couple of days. Windows 2000, all the latest sp's and patches. ever since upgrading from 1.3.something to 1.5.5-1, i've gotten periodic hangs of various sorts. in all cases, the console is completely wedged and can only be killed through the upper-right-hand close button. [1] i have an expect script that runs telnet. sometimes when run, it gets as far as `Spawning telnet xxx ...' then wedges, with 100% CPU chewage. this appears to increase in frequency until eventually it happens always, and can only be fixed by rebooting. [2] for awhile i was getting 100% repeatable wedges [no CPU usage] by running tail on a long file. the following is what tail was attempting to display: Folder: /usr/home/wing/users/wing/mail/Trash 5211 From [EMAIL PROTECTED] Fri Oct 17 06:36:43 2003 Subject: (RAZOR2_CHECK) (RCVD_IN_SBL) (RCVD_IN_NJABL) Ben, Make Your Debt Disa Folder: /usr/home/wing/users/wing/mail/Trash12445 From [EMAIL PROTECTED] Fri Oct 17 06:45:32 2003 Subject: (RAZOR2_CHECK) \xc4\xfa\xba\xc3,\xb9\xd8\xd3\xda\xce\xd2\xc3\xc7\xba\xcf\xd7\xf7\xca\xc2\xd2\xc b Folder: /usr/home/wing/users/wing/mail/Trash11483 From [EMAIL PROTECTED]@FINANCEBIZ.COM.BR Fri Oct 17 06:50:53 2003 Subject: (HTML only) (RAZOR2_CHECK) (PYZOR_CHECK) (DCC_CHECK) (RCVD_IN_NJABL) Folder: /usr/home/wing/users/wing/mail/Trash 7190 [in place of \x sequences are actual characters; none of these lines should wrap, if they are, that's my mail reader's fault.] it was hanging when trying to display the line with the weird characters in it. last thing you'd see is the previous line. unfortunately i can't reproduce this any longer. instead, i get output like this: 666:~/etc/users/wing/procmail 117$ tail procmail.log.old Folder: /usr/home/wing/users/wing/mail/Trash 5211 From [EMAIL PROTECTED] Fri Oct 17 06:36:43 2003 Subject: (RAZOR2_CHECK) (RCVD_IN_SBL) (RCVD_IN_NJABL) Ben, Make Your Debt Disa Folder: /usr/home/wing/users/wing/mail/Trash12445 From [EMAIL PROTECTED] Fri Oct 17 06:45:32 2003 BIZ.COM.BR Fri Oct 17 06:50:53 2003 Subject: (HTML only) (RAZOR2_CHECK) (PYZOR_CHECK) (DCC_CHECK) (RCVD_IN_NJABL) Folder: /usr/home/wing/users/wing/mail/Trash 7190 where there's some text eaten but no hanging. ben -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: module problems on cygwin
well then, how do you build import libraries under cygwin? - Original Message - From: Larry Hall (RFK Partners, Inc) [EMAIL PROTECTED] To: Ben Wing [EMAIL PROTECTED]; Jerry James [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, October 29, 2002 7:04 AM Subject: Re: module problems on cygwin Sounds to me like you're expecting too much, at least for Windows. On Windows, the closest thing to shared libraries are DLLs and these require all references to be resolved at build-time. That's generally done by providing import libraries with stubs to all the calls that will be resolved to other DLLs (at run-time). So you can't have unresolved external references using gcc during builds on Windows, even under Cygwin. Cygwin can't replace the Windows linker/loader so we're all stuck with it's behavior as is. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX At 03:12 AM 10/29/2002, Ben Wing wrote: cygwin is not terribly windows-specific. it's basically unix, and runs all the standard gcc suite of tools, so if you understand shared libraries under Unix, you understand them under gcc. the failures are unresolvable references to the various functions in the XEmacs executable. clearly the XEmacs executable is not around, and so these are indeed unresolvable. the man pages claim that this is ok, and they will be resolved by the run-time linker, but for some reason it's still complaining. any help here? to the cygwin guys: we're trying to create separate modules that can be loaded once the program has started. they are build as shared libraries, and of course contain references to the main executable. Under Cygwin, both gcc-2 and gcc-3, when the .o files are linked into the library (called something like postgres.ell), done using essentiall just `gcc -shared', we get tons of unresolved externals warnings for all the references to the main executable. this obviously shouldn't happen -- the unresolved references should be allowed, and the run-time linker should fix them up. what's going wrong here? - Original Message - From: Jerry James [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, October 28, 2002 5:46 AM Subject: Re: module problems on cygwin [EMAIL PROTECTED] wrote: ./configure --with-x=no --pdump --with-postgresql=no works fine for me with gcc or gcc-2. Removing the with-postgresql=no fails with either gcc or gcc-2. I am away at a conference this week. I can get access to my email from here, but I am working in console mode over a bandwidth-limited pipe (and using an AZERTY keyboard, which is driving me bananas). I won't be able to do much coding until I return, but I should be able to answer questions. I freely confess that I do not understand either native Windows or cygwin, so I will need some help figuring out what to do. I already pointed out that the new module setup is broken on native Windows, so this means that it is broken on both Windows platforms. Ben posted his ellcc.h, which has newlines in strange places. Do other cygwin users have similar ellcc.h files? For comparison purposes, here is mine from a RedHat Linux 7.3 machine. /* DO NOT EDIT THIS FILE */ /* Most of this is required due to a bug in the GCC compiler driver which prevents us from passing this on the command line. It also reduces the compiler command line length, which can be a problem on some systems. */ #ifndef ELLCC_HDR #define ELLCC_HDR #define ELLCC_CCgcc #define ELLCC_CFLAGS-march=i686 -O2 -g #define ELLCC_CPPFLAGS #define ELLCC_LDFLAGS #define ELLCC_CF_GENERAL-DHAVE_CONFIG_H #define ELLCC_CF_ALL-DHAVE_CONFIG_H -I/usr/X11R6/include #define ELLCC_LF_GENERAL #define ELLCC_LF_ALL-L/usr/X11R6/lib #define ELLCC_LIBS_GENERAL -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil #define ELLCC_DLL_CFLAGS-fPIC #define ELLCC_DLL_LDFLAGS -shared #define ELLCC_DLL_POST #define ELLCC_DLL_LDgcc #define ELLCC_DLL_LDO -o #define ELLCC_CONFIGi686-pc-linux #define ELLCC_EMACS_VER 21.5-b9 #define ELLCC_PROGNAME xemacs #define ELLCC_ARCHDIR /usr/local/test/lib/xemacs-21.5-b9/i686-pc-linux #define ELLCC_MODDIR /usr/local/test/lib/xemacs-21.5-b9/i686-pc-linux/modules #define ELLCC_SITEMODS /usr/local/test/lib/xemacs/site-modules #endif /* ELLCC_HDR */ -- Jerry James http://www.ittc.ku.edu/~james/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting
Re: module problems on cygwin
OK, I've disabled module support on Cygwin. Jerry, you need to fix this at some point. ben - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, October 29, 2002 3:12 PM Subject: Re: module problems on cygwin Check out http://cygwin.com/cygwin-ug-net/dll.html. This will build a DLL with an import library for the DLL. Use the import library in the link stream of any other DLL or EXE that references things in this DLL. Larry Original Message: - From: Ben Wing [EMAIL PROTECTED] Date: Tue, 29 Oct 2002 13:55:33 -0700 To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: module problems on cygwin well then, how do you build import libraries under cygwin? - Original Message - From: Larry Hall (RFK Partners, Inc) [EMAIL PROTECTED] To: Ben Wing [EMAIL PROTECTED]; Jerry James [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, October 29, 2002 7:04 AM Subject: Re: module problems on cygwin Sounds to me like you're expecting too much, at least for Windows. On Windows, the closest thing to shared libraries are DLLs and these require all references to be resolved at build-time. That's generally done by providing import libraries with stubs to all the calls that will be resolved to other DLLs (at run-time). So you can't have unresolved external references using gcc during builds on Windows, even under Cygwin. Cygwin can't replace the Windows linker/loader so we're all stuck with it's behavior as is. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX At 03:12 AM 10/29/2002, Ben Wing wrote: cygwin is not terribly windows-specific. it's basically unix, and runs all the standard gcc suite of tools, so if you understand shared libraries under Unix, you understand them under gcc. the failures are unresolvable references to the various functions in the XEmacs executable. clearly the XEmacs executable is not around, and so these are indeed unresolvable. the man pages claim that this is ok, and they will be resolved by the run-time linker, but for some reason it's still complaining. any help here? to the cygwin guys: we're trying to create separate modules that can be loaded once the program has started. they are build as shared libraries, and of course contain references to the main executable. Under Cygwin, both gcc-2 and gcc-3, when the .o files are linked into the library (called something like postgres.ell), done using essentiall just `gcc -shared', we get tons of unresolved externals warnings for all the references to the main executable. this obviously shouldn't happen -- the unresolved references should be allowed, and the run-time linker should fix them up. what's going wrong here? - Original Message - From: Jerry James [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, October 28, 2002 5:46 AM Subject: Re: module problems on cygwin [EMAIL PROTECTED] wrote: ./configure --with-x=no --pdump --with-postgresql=no works fine for me with gcc or gcc-2. Removing the with-postgresql=no fails with either gcc or gcc-2. I am away at a conference this week. I can get access to my email from here, but I am working in console mode over a bandwidth-limited pipe (and using an AZERTY keyboard, which is driving me bananas). I won't be able to do much coding until I return, but I should be able to answer questions. I freely confess that I do not understand either native Windows or cygwin, so I will need some help figuring out what to do. I already pointed out that the new module setup is broken on native Windows, so this means that it is broken on both Windows platforms. Ben posted his ellcc.h, which has newlines in strange places. Do other cygwin users have similar ellcc.h files? For comparison purposes, here is mine from a RedHat Linux 7.3 machine. /* DO NOT EDIT THIS FILE */ /* Most of this is required due to a bug in the GCC compiler driver which prevents us from passing this on the command line. It also reduces the compiler command line length, which can be a problem on some systems. */ #ifndef ELLCC_HDR #define ELLCC_HDR #define ELLCC_CCgcc #define ELLCC_CFLAGS-march=i686 -O2 -g #define ELLCC_CPPFLAGS #define ELLCC_LDFLAGS #define ELLCC_CF_GENERAL-DHAVE_CONFIG_H #define ELLCC_CF_ALL-DHAVE_CONFIG_H -I/usr/X11R6/include #define ELLCC_LF_GENERAL #define ELLCC_LF_ALL-L/usr/X11R6/lib
Re: module problems on cygwin
cygwin is not terribly windows-specific. it's basically unix, and runs all the standard gcc suite of tools, so if you understand shared libraries under Unix, you understand them under gcc. the failures are unresolvable references to the various functions in the XEmacs executable. clearly the XEmacs executable is not around, and so these are indeed unresolvable. the man pages claim that this is ok, and they will be resolved by the run-time linker, but for some reason it's still complaining. any help here? to the cygwin guys: we're trying to create separate modules that can be loaded once the program has started. they are build as shared libraries, and of course contain references to the main executable. Under Cygwin, both gcc-2 and gcc-3, when the .o files are linked into the library (called something like postgres.ell), done using essentiall just `gcc -shared', we get tons of unresolved externals warnings for all the references to the main executable. this obviously shouldn't happen -- the unresolved references should be allowed, and the run-time linker should fix them up. what's going wrong here? - Original Message - From: Jerry James [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, October 28, 2002 5:46 AM Subject: Re: module problems on cygwin [EMAIL PROTECTED] wrote: ./configure --with-x=no --pdump --with-postgresql=no works fine for me with gcc or gcc-2. Removing the with-postgresql=no fails with either gcc or gcc-2. I am away at a conference this week. I can get access to my email from here, but I am working in console mode over a bandwidth-limited pipe (and using an AZERTY keyboard, which is driving me bananas). I won't be able to do much coding until I return, but I should be able to answer questions. I freely confess that I do not understand either native Windows or cygwin, so I will need some help figuring out what to do. I already pointed out that the new module setup is broken on native Windows, so this means that it is broken on both Windows platforms. Ben posted his ellcc.h, which has newlines in strange places. Do other cygwin users have similar ellcc.h files? For comparison purposes, here is mine from a RedHat Linux 7.3 machine. /* DO NOT EDIT THIS FILE */ /* Most of this is required due to a bug in the GCC compiler driver which prevents us from passing this on the command line. It also reduces the compiler command line length, which can be a problem on some systems. */ #ifndef ELLCC_HDR #define ELLCC_HDR #define ELLCC_CCgcc #define ELLCC_CFLAGS-march=i686 -O2 -g #define ELLCC_CPPFLAGS #define ELLCC_LDFLAGS #define ELLCC_CF_GENERAL-DHAVE_CONFIG_H #define ELLCC_CF_ALL-DHAVE_CONFIG_H -I/usr/X11R6/include #define ELLCC_LF_GENERAL #define ELLCC_LF_ALL-L/usr/X11R6/lib #define ELLCC_LIBS_GENERAL -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil #define ELLCC_DLL_CFLAGS-fPIC #define ELLCC_DLL_LDFLAGS -shared #define ELLCC_DLL_POST #define ELLCC_DLL_LDgcc #define ELLCC_DLL_LDO -o #define ELLCC_CONFIGi686-pc-linux #define ELLCC_EMACS_VER 21.5-b9 #define ELLCC_PROGNAME xemacs #define ELLCC_ARCHDIR /usr/local/test/lib/xemacs-21.5-b9/i686-pc-linux #define ELLCC_MODDIR /usr/local/test/lib/xemacs-21.5-b9/i686-pc-linux/modules #define ELLCC_SITEMODS /usr/local/test/lib/xemacs/site-modules #endif /* ELLCC_HDR */ -- Jerry James http://www.ittc.ku.edu/~james/ -- 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/
