Re: TTYfier
Eric Mangold wrote:
First of all, i think it's better to post it to cygwin mailing list.
I'm trying to use ttyfier to make the native win32 build of Python play
nice over a cygwin/ssh/bash shell. I can ssh in to my Windows machine and
run the Native python but it has all kinds of issues dealing with
interactive input/output.
Why not use cygwin version of python? It's much better integrated with
cygwin shells than native one.
I compiled ttyfier successfuly, but it unfortunately didn't solve my
problem. Running Python under tfy causes it to print the normal Python
prompt, then it just hangs and won't respond to any input.
I figured I would email you just in case you had some idea about what
might be going wrong.
I can guess that you're logging in to your cygwin machine from the unix
host, right?
If this is the case, then you're (almost, see below) out of luck.
Ttyfier uses special feature of cygwin console, called raw-mode input.
tfy.exe sends special command to console application, which makes
console pass each your keypress, encoded, to tfy.exe. It then parses it
and send to the application it's running.
If you ssh from xterm on unix machine to cygwin host, run tfy.exe, then
your xterm continues sending cooked keypresses, instead of raw ones,
and tfy ignores them.
So to be able to use tfy.exe, your console application must be
'ttyfier-compatible', that is, it must support raw mode of input, which
tfy.exe can understand. If you've been compiling latest sources of
ttyfier, you may have noticed file x11_trans.c inside. This is
experimental module to parse raw input from specially patched xterm (I'm
attaching my old patch to xterm sources).
So, to run your python application from unix machine via ssh you have 2
options:
1. Run cygwin version of python.
2. a. Apply attached patch to xterm sources, and compile special version
of xterm.
b. Build tfy using wide-character version of libncurses
(libncursesw), so that tfy can correctly display pseudo-graphic
characters in unicode xterm window.
Which one is easier, is up to you. I must admit that since i've moved
from windows to linux several years ago, i have not much motivation to
push raw-mode patches to xterm or rxvt.
egor.
diff -rup2 xterm.org/Imakefile xterm/Imakefile
--- xterm.org/Imakefile Tue Aug 20 11:05:57 2002
+++ xterm/Imakefile Thu Aug 22 16:58:44 2002
@@ -104,4 +104,7 @@ module.o: ; $(CC) -c defines $(CFLAGS) m
XRFDEPLIBS = XftClientDepLibs $(DEPXRENDERLIB)
#endif
+#if RawKeyboardSupport
+ RAW_KBD_OPTION = -DOPT_RAW_KEYBOARD
+#endif
MAIN_DEFINES = $(UTMPDEF) $(TTYGROUPDEF) $(PUCCPTYDDEF) $(NOPOSIXTERMIOS) \
@@ -110,5 +113,5 @@ module.o: ; $(CC) -c defines $(CFLAGS) m
MISC_DEFINES = /* -DALLOWLOGGING -DALLOWLOGFILEEXEC */
XKB_DEFINES = XkbClientDefines
-DEFINES = -I. $(XKB_DEFINES) $(TERMCAPDEFINES) $(FEATURE_DEFINES) $(SCROLLBAR_RIGHT) $(UTF8_OPTION) $(XRFDEF)
+DEFINES = -I. $(XKB_DEFINES) $(TERMCAPDEFINES) $(FEATURE_DEFINES) $(SCROLLBAR_RIGHT) $(UTF8_OPTION) $(XRFDEF) $(RAW_KBD_OPTION)
#ifdef OS2Architecture
diff -rup2 xterm.org/charproc.c xterm/charproc.c
--- xterm.org/charproc.c Tue Aug 20 11:05:57 2002
+++ xterm/charproc.c Thu Aug 22 17:18:45 2002
@@ -3371,4 +3371,9 @@ dpmodes(
break;
#endif
+#if OPT_RAW_KEYBOARD
+ case 2000:
+ set_raw_keyboard_mode(term, func == bitset);
+ break;
+#endif
}
}
diff -rup2 xterm.org/input.c xterm/input.c
--- xterm.org/input.c Tue Aug 20 11:05:57 2002
+++ xterm/input.c Thu Aug 22 17:11:31 2002
@@ -1219,2 +1219,22 @@ xtermcapKeycode(char *params, unsigned *
}
#endif
+
+#ifdef OPT_RAW_KEYBOARD
+void
+handleRawKeyboardEvent (Widget w, XtPointer client_data, XEvent *event, Boolean *continue_to_dispatch)
+{
+ char raw_buf [50];
+ char *p;
+ if (term-keyboard.raw_mode) {
+ sprintf (raw_buf, \033{%d;%d;%dK, event-xany.type,
+ event-xkey.state, event-xkey.keycode);
+ for (p = raw_buf; *p; p++)
+ unparseputc (*p, term-screen.respond);
+ *continue_to_dispatch = FALSE;
+ } else if (event-xany.type == KeyRelease) {
+ *continue_to_dispatch = FALSE;
+ } else {
+ *continue_to_dispatch = TRUE;
+ }
+}
+#endif
diff -rup2 xterm.org/main.c xterm/main.c
--- xterm.org/main.c Tue Aug 20 11:05:57 2002
+++ xterm/main.c Thu Aug 22 17:12:21 2002
@@ -1975,4 +1975,14 @@ main (int argc, char *argv[])
init_keyboard_type(keyboardIsVT220, resource.sunKeyboard);
#endif
+#if OPT_RAW_KEYBOARD
+ set_raw_keyboard_mode (term, FALSE);
+
+ XtInsertEventHandler ((Widget) term,
+ KeyPressMask | KeyReleaseMask,
+ FALSE,
+ (handleRawKeyboardEvent),
+ NULL,
+ XtListHead);
+#endif
screen = term-screen;
diff -rup2 xterm.org/ptyx.h xterm/ptyx.h
--- xterm.org/ptyx.h Tue Aug 20 11:05:57 2002
+++ xterm/ptyx.h Tue Aug 20 11:08:40 2002
@@ -1322,4 +1322,7 @@ typedef struct
int reset_DECBKM; /* reset should set DECBKM */
#endif
+#ifdef OPT_RAW_KEYBOARD
+int raw_mode;
Re: TTYfier
Barry B wrote: Does anyone still have the source code to a Cygwin program called ttyfier? TTYfier is supposed to allow the running of Windows console applications that don't know how to converse with a tty. This would allow one to run such programs via the sshd that comes with Cygwin. There used to be a web site in Russia run by Egor Deo that contained the project files, but the site no longer exists and I am unable to locate the files anywhere else on the Internet. Also, is TTYfier still necessary for my intended purpose? Or has someone else come up with a better way to accomplish this over years? Thanks! Hi, Barry! You can download ttyfier sources from here: http://www.corpit.ru/deo/ttyfier-src.tar.bz2 There was certainly some bit-rot in it since 2001. Moreover, i've added some new functionality, such as ability to access 'ttyfied' program from xterm window, but it's somewhat experimental at the moment, and relies on unicode version of ncurses library -- libncursesw, which, AFAICT, was never officialy released for cygwin. I'm going to revisit ttyfier this week to see if anything needs fixing for recent cygwin. Feel free to build it yourself and ask any questions about it. egor. -- 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: BusyBox build problem on Cygwin
Tero Niemela wrote: Egor, hi, I'm having a build problem of BusyBox-1.00 on Cygwin and I think I've tracked the origin of it being related to a change you've contributed to BusyBox (1). Specifically, when building BusyBox, its top-level Makefile include a huge amount of Makefile.in files with this line: include $(patsubst %,%/Makefile.in, $(SRC_DIRS)) Actually, such include was present in build system before my change, so i doubt this line is the culprint Now, when I'm building BusyBox-1.00 on Cygwin in directory /busybox-1.00 everything goes ok. But when I'm using a bit longer path, like /tmp/a_longish_directory_name_for_testing/busybox-1.00 I got an error when doing 'make': gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep /tmp/a_longish_directory_name_for_testing/busybox-1.00/scripts/mkdep.c gcc: installation problem, cannot exec `/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/collect2.exe': Resource temporarily unavailable make: *** [scripts/mkdep] Error 1 When testing with path /tmp/a_longish_directory_name_for_test/busybox-1.00 things work again. I presume this has something to do with Cygwin's exec() implementation, the build seems to be chiking when to length for include exceeds some limit. It sounds more like memory corruption problem to me. It may be in cygwin itself or in cygwin's version of make. When you use longer paths, some static buffers or allocated memory seem to be overwritten which may cause such behaviour. It would be interesting to check if simply running gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep /tmp/a_longish_directory_name_for_testing/busybox-1.00/scripts/mkdep.c from command line works ok. I tried all sorts of tricks in Makefile to find a workaround but didn't succeed to produce anything useful. Do you have any ideas how to fix this? Is this more Cygwin or BusyBox problem? Currently, I can live with using always /busybox-1.00 for building but that is a bit awkward.. I suggest you to follow cygwin bug reporting guidelines from http://cygwin.com/problems.html, including cygcheck output to debug th -- 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: checking for working mmap...no
Sam Steingold wrote: It appears that cygwin mmap() is lacking: configure:20536: checking for working mmap configure:20617: gcc -o conftest.exe -g -O2 conftest.c 5 configure:20620: $? = 0 configure:20622: ./conftest.exe configure:20625: $? = 1 configure: program exited with status 1 configure: failed program was: Maybe this: http://www.cygwin.com/ml/cygwin/2000-09/msg00380.html is the reason? egor -- 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: Locking down cygwin for security
Colin JN Breame wrote: Is it possible to disabled certain features to make cygwin secure over ssh such that the logged in user cannot: - cd into any /cygdrive drives - mount any local or UNC drives but still: - access a system wide mount to a local drive You will gain little additional security by doing this. As long as you can't prevent user from calling normal win32 applications (such as as cmd.exe) and win32 APIs (like CreateFile ()) he will be able to accesss any drives on your system you're supposing to prevent him from. Your only gain will be false sense of security. The way to achieve real security is to set proper access rights for all files on all filesystems on your host and all other hosts this user can log into. egor -- 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: Anyone Done This ???
Reini Urban wrote: cygwin cannot control remote registry entries (besides ssh'ing to each machine), but the win32 tool regedt32.exe can, and there's a COM API. it can since 2002. just add hostname to the key name in regtool's command line. For detailed info see http://cygwin.com/cygwin-ug-net/using-utils.html#REGTOOL egor -- 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/
make IPC_INFO visible to ipc system utilities only
Hi! Currently IPC_INFO is defined whenever we include sys/sem.h, but struct seminfo, which is returned by semctl(IPC_INFO) is defined only for _KERNEL applications. This inconsistency breaks, for instance, libmudflap builds. I believe there's no point to have IPC_INFO in non-_KERNEL application as long as we can't get semctl(IPC_INFO) results right anyway. Patch attached. egor 2004-Jun-08 Egor Duda [EMAIL PROTECTED] * include/cygwin/ipc.h: Make IPC_INFO visible only for ipc system utilities, to make it consistent with declaration of struct seminfo. Index: include/cygwin/ipc.h === RCS file: /cvs/src/src/winsup/cygwin/include/cygwin/ipc.h,v retrieving revision 1.6 diff -u -p -2 -r1.6 ipc.h --- include/cygwin/ipc.h3 Jun 2004 19:51:10 - 1.6 +++ include/cygwin/ipc.h8 Jun 2004 07:27:29 - @@ -49,5 +49,8 @@ struct ipc_perm #define IPC_SET 0x1001/* Set options. */ #define IPC_STAT 0x1002/* Get options. */ + +#ifdef _KERNEL #define IPC_INFO 0x1003/* For ipcs(8). */ +#define #ifdef _KERNEL
Re: make IPC_INFO visible to ipc system utilities only
Corinna Vinschen wrote: Currently IPC_INFO is defined whenever we include sys/sem.h, but struct seminfo, which is returned by semctl(IPC_INFO) is defined only for _KERNEL applications. This inconsistency breaks, for instance, libmudflap builds. I believe there's no point to have IPC_INFO in non-_KERNEL application as long as we can't get semctl(IPC_INFO) results right anyway. ^ What is the author trying to tell me here?!? I was unclear here, probably. I meant that userspace application, i.e. application which includes sys/sem.h but don't define _KERNEL, may call semctl(IPC_INFO), but result of this call will have no meaning for application since it can't interpret it. So by we in underscored sentence i meant userspace, non-system ipc application. egor
Re: .rdata section in Cygwin executables?
Joe Buehler wrote: The emacs recompile fails because there is a section in the initially built emacs.exe named .rdata that the unexec() code for Cygwin is not expecting. The section appears to have something to do with exception handling and is only 1k in size. .rdata is a section where read-only data, such as constants, is stored. Most modern OSes and toolchain try to put as much info as possible to read-only segments of binary image because it reduce memory required by programs to run (when program is fork()ed, for instance, read-only pages may be shared between processes) On linux such section is called .rodata, so probably you can take a look how linux version of emacs deals with that. I'm reading up on this at the moment, but a couple questions occur to me that someone here might be able to answer off the top of their head: - can .rdata just be combined with the preceeding .data section? It's possible, but it's not the Right Way (tm). - perhaps there is a way to do this with the linker so I don't have to change the emacs unexec() code? You may write your own linker script so that all rdata section will be put to .data when emacs.exe is linked, but again, it doesn't look as the proper way to deal with the problem. egor.
Re: SIGSEGV in cygwin1.dll
Marco Canini wrote: Hi list, this is my first post here. I'm writing an application that uses SDL, lib3ds and glib I've installed SDL and lib3ds from sources, both compiled with -mno-cygwin, while glib (2.2) comes from here http://web.sfc.keio.ac.jp/~s01397ms/cygwin/ I wasn't able to compile it from sources, still need to understand why. Anyway after I actually compiled my application I run it and ... SIGSEGV So, your application is linked both with cygwin1.dll, and with Microsoft's C library (msvcrt or crtldd) indirectly, via sdl and lib3ds which are built with -mno-cygwin. You can't do that. See http://cygwin.com/faq/faq_4.html#SEC99 (The application works in my linux box) With gdb I was able to collect this stack trace: Program received signal SIGSEGV, Segmentation fault. 0x61021a8b in unsetenv () from /usr/bin/cygwin1.dll (gdb) bt #0 0x61021a8b in unsetenv () from /usr/bin/cygwin1.dll #1 0x6101f9b2 in dlfork () from /usr/bin/cygwin1.dll That probable means that cygwin's version of unsetenv() is called on variable that was set by Microsoft's runtime. You have to build cygwin versions of those 3rd-party libraries you use. [...] interestend in compiling only src/winsup/cygwin and not all cygwin. Is it possible? How? src/winsup/cygwin is basically all cygwin. You can tweak build process to avoid building misc utilities such as cygcheck etc., but it won't save you much time or disk space. If i can compile it I'll able to understand where's the problem -- 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: search and replace tool
Yitzchak Scott-Thoennes wrote: On Fri, Feb 20, 2004 at 10:02:03AM +0300, Egor Duda wrote: huh? what do you mean in-place? linux writes new file to new place, it just deletes .bak file afterwards, unlike cygwin. [EMAIL PROTECTED]:~$ echo aaa xxx [EMAIL PROTECTED]:~$ ls -i xxx 408096 xxx [EMAIL PROTECTED]:~$ perl -i -pe 's/aaa//' xxx [EMAIL PROTECTED]:~$ ls -i xxx 408074 xxx [EMAIL PROTECTED]:~$ cat xxx That doesn't ever create a backup file or a temporary file. It opens xxx for read, unlinks it, opens xxx for writing, then reads from the original handle and writes to the second handle. This is AFAIUI impossible on windows, but possible on things like unix and VMS (where the unlink is skipped because of the automatic versioning). Well, it creates new file, while old one is still present on disk. Space occupied by original file is freed only after handle is closed. What is deleted immediatly on linux is just directory entry, not the file itself. Depending on the goal you wish to achive, cygwin may have drawbacks compared to linux or they may be equal. If you want to search-and-replace in 700Mb file on 1Gb disk then you won't be able to do so either on linux or on cygwin. If you wish to keep your real .bak file from being overwritten by search-and-replace script, then linux is slightly more convenient here, but on cygwin it's almost as easy to work around. egor. -- 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: search and replace tool
On Thu, 19 Feb 2004, Brian Dessent wrote: What on Earth are you talking about? What inability? WFM (see below). ... $ perl -i -pe 's/blah/stuff/g' sometext $ ls sometext sometext.bak It didn't do the editing inline, it created a new file and renamed the old one .bak. In other words, on Cygwin -i is really -i.bak. If you try the above sequence on linux you don't get a .bak file and the changes are truly done in-place. I assume this relates to differences in filesystem semantics. huh? what do you mean in-place? linux writes new file to new place, it just deletes .bak file afterwards, unlike cygwin. [EMAIL PROTECTED]:~$ echo aaa xxx [EMAIL PROTECTED]:~$ ls -i xxx 408096 xxx [EMAIL PROTECTED]:~$ perl -i -pe 's/aaa//' xxx [EMAIL PROTECTED]:~$ ls -i xxx 408074 xxx [EMAIL PROTECTED]:~$ cat xxx egor. -- 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: Cross Compiler and __RUNTIME_PSEUDO_RELOC_LIST__
Tim Renner wrote: $ for f in `find . -name '*.a'`;do nm $f 2/dev/null |grep PSEUDO_RELOC_LIST echo $f; done U ___RUNTIME_PSEUDO_RELOC_LIST_END__ U ___RUNTIME_PSEUDO_RELOC_LIST__ ./libcygwin.a U ___RUNTIME_PSEUDO_RELOC_LIST_END__ U ___RUNTIME_PSEUDO_RELOC_LIST__ ./libg.a Can anyone tell me what eventually resolves those symbols in a normal cygwin(not cross) compile? Or better, if you know how I can fix this in my cross compiler ;) Use last version of binutils. Current ld emits both this symbols while linking executable. egor. -- 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/
Bug in dumper
Ronald Landheer-Cieslak wrote: Does dumper.exe work? Well, i should have answered this, but unfortunately, i have no access to windows machine right now to debug, or even verify this. Upon execution I see the following in the cygwin console: $ ./div.exe 7 [main] div 2296 handle_exceptions: Error while dumping state (probably corrupted stack) Arithmetic exception (core dumped) In the cmd.exe console window that dumper.bat starts I see the following: C:\cygwin\home\jlambertdumper.exe -d C:/cygwin/home/jlambert/div.exe 1884 dumping process #1884 to div.exe.core setting bfd architecture: No error Well, this is a strange line. This last line of dumper's output indicates than call to bfd_set_arch_mach(abfd, bfd_arch_i386, 0) havs returned non-zero status, which should indicate an error (if i understand things correctly), yet bfd_perror called immediately afterwards has printed No error message. This means that either i'm wrong about my assumptions about bfd_set_arch_mach() and its return, or there's a bug in binutils. It should be quite easy to debug, though, for those who have a cygwin toolchain installed. Just build dumper with debug info (this will require building bfd alongside), start any innocent process, say, bash, get its pid and then run 'dumper -d c:/cygwin/bin/bash.exe bash_pid' under gdb. This should reveal what status is returned by bfd_set_arch_mach, and why. egor. -- 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/
Re: Repeated gcc yields differing .exe files
Hi! Friday, 20 December, 2002 [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: fbun I found this just now. I'm afraid I don't know enough about gcc to deduce fbun whether this is just yet another symptom of problems already reported or fbun something else, that genuinely matters (I think it does) and that can be fbun mended (I hope it can). fbun I just repeatedly used gcc with hello.c attached to get this: ~/tmp gcc -o hello hello.c; md5sum hello.exe fbun 15fbfaadc53cede5d797eb544dae032e *hello.exe ~/tmp gcc -o hello hello.c; md5sum hello.exe fbun 3a7d9a1536e0b3dcb4fa8557a2933ffb *hello.exe ~/tmp gcc -o hello hello.c; md5sum hello.exe fbun 952a3bee8d35b627a92c679640e1d1df *hello.exe fbun The fact that hello.exe alters seems a bit non-optimal to me, given that fbun md5sums are a pretty standard way for people like you and me to check that fbun we're running the same stuff, intended to do the same thing. Incidentally, fbun it's always the same two bytes that alter: ~/tmp cmp -l hello.exe hello1.exe fbun 137 74 254 fbun 217 33 213 ~/tmp cmp -l hello.exe hello2.exe fbun 137 74 257 fbun 217 33 216 ~/tmp cmp -l hello.exe hello3.exe fbun 137 74 262 fbun 217 33 221 fbun I had an earlier problem with a _long_ myfile.c giving variant myfile.exe. I fbun knew you wouldn't like to be bothered with myfile.c which is why I looked at fbun hello.c. The variations in successive copies of myfile.exe were again in fbun bytes 137 and 217. This is by design. PE specification states that binary files should have a timestamp field in their header. Obviously, it changes whenever you rebuild the application. As we generate windows executables we should comply with standards adopted by microsoft for their platform. Other option -- i.e. zeroing timestamp in PE header will solve your problem but may pose problems with compatibility with new versions of microsoft's OSes and, possibly, other windows software. So i highly doubt that current situation will change anytime soon. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: --enable-runtime-pseudo-reloc support in cygwin, take 3.
Hi! Sunday, 08 December, 2002 Charles Wilson [EMAIL PROTECTED] wrote: CW Charles Wilson wrote: I've tested Egor's patch and it seems to work just fine, as demonstrated by the two test cases he posted last week, AND as demonstrated by the test case posted to the binutils list some months ago (it tested pseudo-reloc behavior in the child after a fork). I've also tested Egor's runtime reloc support with Ralf's binutils use the DLL as the import lib and it ALSO works fine in all three cases. I'm going to continue using ld.exe-ralf and cygwin1.dll-egor/libcygwin.a-egor for my day-to-day use, just to see if something wacky crops up... CW [snip] On balance, I agree that #1 is the best option. Unless I run afoul of some unforseen wackiness in the next few days, recommend inclusion as is (in the most recent iteration, e.g. no cygwin.sc changes) CW So far, no problems. I'm gonna go on record in favor of this patch, in CW its 4th incarnation BTW, it should now be possible to build libstdc++ as a dll and use it from application. C++-specific things were the main motivation of introducing pseudo-relocs, because C++ generate references from client application to typeinfo records in in libstdc++.dll, which cannot be handled in other way than via pseudo-relocs. Previously, simple program which uses simple C++-style 'std::cout Hello, world;' couldn't be linked against libstdc++.dll because it contained non-zero-addend-references. My own simple tests indicated that it works, but i hadn't performed tests on real large-scale applications. I wonder if some real applications in current cygwin distro uses libstdc++, and if they can be tested against current binutils and cygwin with libstdc++ built as DLL? Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
Re: stdint.h missing
Hi! Tuesday, 10 December, 2002 Neal D. Becker [EMAIL PROTECTED] wrote: NDB It seems that /usr/include/stdint.h is missing. I am using: Welcome to the world of portable programming. Single Unix Specification version 2 -- a standard cygwin is trying to comply with -- doesn't include such file. Newer versions of standard do include this file, but a lot of systems (a quick check reveals FreeBSD 4.7, along with cygwin) doesn't provide this file yet. So if you want to make your program portable across wide range of platforms, you shouldn't rely on recent versions of standards because it takes time for system implementors to catch up. Instead, you should check in configure script if this file exists, and if not, provide your own declaration for uint8_t, and other types and constants your program needs. Additionally, you may provide a patch to add this file to cygwin, and if done properly, it will be gratefully accepted. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: --enable-runtime-pseudo-reloc support yadda, yadda [APOLOGY TO CHUCK]
Hi! Monday, 09 December, 2002 Christopher Faylor [EMAIL PROTECTED] wrote: CF On Sat, Dec 07, 2002 at 11:08:46PM -0500, Christopher Faylor wrote: On Sat, Dec 07, 2002 at 09:51:31PM -0500, Charles Wilson wrote: Now you're just being an asshole. I don't relish going to Red Hat lawyers and trying to explain this situation to them but I have just sent an email briefly explaining the situation. They will be the ones who eventually decide. CF I want to publicly apologize to Chuck for my tone in my message previous CF to this one. Licensing issues are not fun because they mean that I need CF to get lawyers involved. And i'd like to make it clear, that i have absolutely no problems with putting pseudo-reloc.c under cygwin license. I know myself that talking to the lawyers is not much fun, so if there're any problems WRT licensing i'd easily change it back. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
Re: --enable-runtime-pseudo-reloc support in cygwin, take 3.
Hi! Monday, 02 December, 2002 Charles Wilson [EMAIL PROTECTED] wrote: CW OTOH, if you, Egor Duda, do NOT assign ownership to Red Hat, but instead CW release the code as public domain FIRST, then mingw is free to take it. That's what i was meaning. CW Also, Red Hat is free to take it as well -- but they do not have CW ownership of the code; they simply are using it as they would any CW other public domain code. Which means Red Hat has the right to CW re-release it under their proprietary cygwin license and under the GPL. CW But, I am not sure how your (Egor's) pre-existing assignment form for CW continuing contributions affects this. Does the assignment kick in CW automatically, since this was developed against the cygwin source dist? Yes, you're right there was such clause in copyright assignment. That means that it's up to Redhat to place this code to public domain. Anyway, if there's any problems with that, the code can be easily implemented independently. It's not a rocket science, after all. CW So, IANAL, but it seems that the right way to do this is for you to CW release the code as public domain, and then for someone else -- cgf? -- CW to adapt it to the cygwin build system for assimilation. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
Re: --enable-runtime-pseudo-reloc support in cygwin, take 3.
Hi! Monday, 02 December, 2002 Christopher Faylor [EMAIL PROTECTED] wrote: CF On Mon, Dec 02, 2002 at 01:30:24PM +0300, egor duda wrote: 2002-12-02 Egor Duda [EMAIL PROTECTED] * cygwin/lib/pseudo-reloc.c: New file. * cygwin/cygwin.sc: Add symbols to handle runtime pseudo-relocs. * cygwin/lib/_cygwin_crt0_common.cc: Perform pseudo-relocs during initialization of cygwin binary (.exe or .dll). CF I'm rapidly approaching the I-don't-care-anymore state for this but I am CF not clear on why we need to add the changes to cygwin.sc. This is for people CF who want to link the cygwin DLL without using the appropriate header files CF which label things as __declspec(dllexport) or using the appropriate libcygwin.a, CF right? Why should that matter? Yes, you're right. This part is not needed. It's probably been left out from the experimental phase when i tried different ways to handle pseudo-relocs. Here's the updated one. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 pseudo-reloc.c Description: Binary data cygwin-runtime-pseudo-reloc-support-4.diff Description: Binary data cygwin-runtime-pseudo-reloc-support-4.ChangeLog Description: Binary data
Re: --enable-runtime-pseudo-reloc support in cygwin, take 3.
Hi! Monday, 02 December, 2002 egor duda [EMAIL PROTECTED] wrote: ed 2002-12-02 Egor Duda [EMAIL PROTECTED] ed * cygwin/lib/pseudo-reloc.c: New file. I guess i should put it to the public domain, so that mingw folks can also use it. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 pseudo-reloc.c Description: Binary data
Re: --enable-runtime-pseudo-reloc support in cygwin, take 3.
Hi! Monday, 02 December, 2002 Earnie Boyd [EMAIL PROTECTED] wrote: EB egor duda wrote: Monday, 02 December, 2002 egor duda [EMAIL PROTECTED] wrote: ed 2002-12-02 Egor Duda [EMAIL PROTECTED] ed * cygwin/lib/pseudo-reloc.c: New file. I guess i should put it to the public domain, so that mingw folks can also use it. EB Is it usable without Cygwin? Yes. It doesn't use any cygwin functionality. Recent binutils should export __RUNTIME_PSEUDO_RELOC_LIST__ and __RUNTIME_PSEUDO_RELOC_LIST_END__ symbols for all PE-based targets, including Mingw. I'm not that familiar with Mingw internals, but you just have to add a call to _pei386_runtime_relocator() to the application startup (to the crt2.o, IIRC) and link with pseudo-reloc.o. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
Re: --enable-runtime-pseudo-reloc support in cygwin, take 3.
Hi! Monday, 02 December, 2002 Earnie Boyd [EMAIL PROTECTED] wrote: EB egor duda wrote: Hi! Monday, 02 December, 2002 Earnie Boyd [EMAIL PROTECTED] wrote: EB egor duda wrote: Monday, 02 December, 2002 egor duda [EMAIL PROTECTED] wrote: ed 2002-12-02 Egor Duda [EMAIL PROTECTED] ed * cygwin/lib/pseudo-reloc.c: New file. I guess i should put it to the public domain, so that mingw folks can also use it. EB Is it usable without Cygwin? Yes. It doesn't use any cygwin functionality. Recent binutils should export __RUNTIME_PSEUDO_RELOC_LIST__ and __RUNTIME_PSEUDO_RELOC_LIST_END__ symbols for all PE-based targets, including Mingw. I'm not that familiar with Mingw internals, but you just have to add a call to _pei386_runtime_relocator() to the application startup (to the crt2.o, IIRC) and link with pseudo-reloc.o. EB So, should this be a part of binutils instead of Cygwin? No. It's a part of runtime environment. It just uses some information binutils provide. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
Re: max user processes
Hi! Monday, 02 December, 2002 Lee Tuck [EMAIL PROTECTED] wrote: LT Can I recompile or rebuild the cygwin source so that I LT can set the maximum process per user id to 500? If LT yes, how? Which is the source that I should change? LT Hope that you can help out. If you want it, you'll have to implement it yourself, i.e. you have to modify cygwin sources to support such feature. I suppose it might be tricky, so i suspect nobody can point you a file which can be easily changed to add such functionality. I should warn you, however, that if your goal is to prevent malicious user from eating up system resources, then your restriction won't help. User can always start more processes using native syscalls (CreateProcess()), which cygwin cannot control. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: undefined reference to __pei386_runtime_relocator
Hi! Friday, 29 November, 2002 Alan Hourihane [EMAIL PROTECTED] wrote: AH I'm using the new --enable-runtime-pseudo-reloc parameter to ld and AH finding that nothing links and ld blurts out AH ertr03.o(.rdata+0x0): undefined reference to AH `__pei386_runtime_relocator' AH Is there something extra I need to add to ld, or is this missing from the AH current libraries ? AH Or does this option not work yet ? Right, it doesn't work yet. From the announcement: However, this option requires functionality in the cygwin DLL which is not yet present. Stay tuned. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: Cygwin official logo ?
Hi! Friday, 29 November, 2002 Barry Buchbinder [EMAIL PROTECTED] wrote: BB How about a penguin looking through a window? It'd be clearly misleading. Cygwin is not Linux for Windows. We have enough confusion already with people thinking otherwise. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: Cygwin official logo ?
Hi! Friday, 29 November, 2002 Rolf Campbell [EMAIL PROTECTED] wrote: -Original Message- From: egor duda [mailto:[EMAIL PROTECTED]] Sent: Friday, November 29, 2002 9:59 AM To: Barry Buchbinder Cc: [EMAIL PROTECTED] Subject: Re: Cygwin official logo ? BB How about a penguin looking through a window? It'd be clearly misleading. Cygwin is not Linux for Windows. We have enough confusion already with people thinking otherwise. RC That is true, but Cygwin does make it easier to compile Linux programs RC under windows. (maybe replace Linux with POSIX, but the most RC popular POSIX OS in Linux) [maybe replace popular with well known] And explosives do make it easier to do mining. Does it mean that miner's emblem should be a dynamite with a burning fuse? _We_ know that cygwin just makes it easier to port unix programs to windows. But people who are just curious about what the heck this cygwin thingie is? will see the logo and get the impression that it just some kind of linux to be run on windows. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: [ANNOUNCEMENT] Updated: binutils-20021117-1
Hi! Monday, 25 November, 2002 Christopher Faylor [EMAIL PROTECTED] wrote: Wouldn't that mean that it should be added somehow to _cygwin_dll_entry winsup/cygwin/include/cygwin/cygwin_dll.h ? It only have to be called during application (or library, in case of app.exe-x1.dll-x2.dll) initialization. CF Did you look at the cygwin_dll.h file? Are you saying that you don't CF think the call should go there? It can go there. But if it's put there, then fixups will be performed on x1.dll's refeneces to data in x2.dll only. As far as i understand, if we put fixup code to cygwin_dll.h, then we must also add it to startup code for app.exe. It's my understanding that dll_crt0_1 is the piece of code that's activated at binary startup if the binary is linked with libcygwin.a; and it doesn't matter if binary is executable or dll. But obviously, i may be wrong here, please correct me if so. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
Re: [ANNOUNCEMENT] Updated: binutils-20021117-1
Hi! Tuesday, 19 November, 2002 Christopher Faylor [EMAIL PROTECTED] wrote: CF I've made a new version of binutils available for download. This is CF just a refresh from sources.redhat.com. A notable change is the CF addition of Egor Duda's --enable-runtime-pseudo-reloc option which CF allows almost transparent linking of dll's without the need of a def CF file. However, this option requires functionality in the cygwin DLL CF which is not yet present. Stay tuned. Ok, it's time to revive a discussion about implementation of pseudo-relocations in runtime. So far, there were 3 propositions: 1. Implement everything in application (in crt0.o) Benefits: Will work with any version of cygwin1.dll. All problems with lack of support from runtime are detected during application linking. (Possibly) common code with mingw. Drawbacks: Will require rebuilding application in case we'll want change something. 2. Implement everything in cygwin1.dll. In this case application is about to have an external reference to _pei386_runtime_relocator. Benefits: Easy to change relocation semantics without relinking application. Drawbacks: GUI window popping up when new application is loaded with old runtime. Lack of support is detected only at application startup. 3. Implement actual relocation in dll, and call it from crt0 via cygwin_internal(). Check dll api version and print error message if runtime is too old. Benefits: Easy to change relocation semantics without relinking application. Drawbacks: Lack of support is detected only at application startup. Question: How can one distinguish console application from GUI one? What is the best wording for the error message? My own preference list (from most preferable to least preferable) is: 1st, then 3rd, then 2nd. Comments? Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
Re: compiling clicq, problems with c++
Hi! Monday, 18 November, 2002 Uwe Mayer [EMAIL PROTECTED] wrote: UM ok, sorry. i wanted to keep the mail as short as possible, here's the UM call to make: UM merkosh@M111 /tmp/clicq-0.1 UM $ make UM make[2]: Entering directory `/tmp/clicq-0.1/src' UM gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../icqlib/icqlib-g -O2 -c clicq.c UM clicq.c:16:18: term.h: No such file or directory Here's the error. UM Where's the Error that make indicates? To find out which package contains the file your program requires, use Setup Package Search Link on the cygwin homepage. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: --enable-auto-import extension
Hi! Thursday, 14 November, 2002 Nick Clifton [EMAIL PROTECTED] wrote: NC Hi Charles, Hi Egor, 2002-07-01 Egor Duda [EMAIL PROTECTED] * ldmain.c (main): Make runtime relocs disabled by default. Remove assignment which has no effect. * pe-dll.h (pe_create_import_fixup): Change prototype. * pe-dll.c (make_runtime_pseudo_reloc): New function. (pe_create_runtime_relocator_reference): Ditto. (pe_create_import_fixup): Handle relocations with non-zero addends. * emultempl/pe.em: Add options --enable-runtime-pseudo-reloc and --disable-runtime-pseudo-reloc. (make_import_fixup): Handle relocations with non-zero addends. Create an external reference to _pei386_runtime_relocator symbol if at least one pseudo reloc was created. * ld.texinfo: Document --enable-runtime-pseudo-reloc and --disable-runtime-pseudo-reloc options. 2002-07-01 Egor Duda [EMAIL PROTECTED] * bfdlink.h (struct bfd_link_info): Add new boolean field pei386_runtime_pseudo_reloc. NC Approved and applied. [Sorry for the long delay]. NC Note: The cygwin targeted ports (eg i686-pc-cygwin) are currently NC showing three unexpected failures in the GAS testsuite: NC FAIL: i386 abs reloc NC FAIL: i386 pcrel reloc NC FAIL: i386 sub NC Which their non-PE cousins do not. I would appreciate it if you could NC spare a few moments to investigate this. First of all, thanks, Charles, for fixing spelling and formatting errors, and pushing the patch through. I'm to revive a discussion about runtime part of changes in cygwin-apps@ after weekend. As for gas testsuite failures, i suppose they have nothing to do with this patch. I've just reverted the patch but failures persist. I'll try to track them down further, but i highly doubt that adding a field to 'struct bfd_link_info', which is the only thing in the patch which may affect gas, could lead to reloc failures in gas testsuite. Egor.mailto:deo;logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19
Re: How can I use in console codepage different from ANSI and OEM?
Hi! Sunday, 03 November, 2002 Alexander Gotlib [EMAIL PROTECTED] wrote: AG Subj? For russian language ANSI-codepage is cp1251 (win1251), OEM - cp866 AG (dos866). But in unix systems used another one - koi8-r. Koi8-r is de-facto AG standart for E-mail and News messages. Therefore will be good if Cygwin AG console will receive possibility to use some different from CYGWIN AG codepage=oem and CYGWIN codepage=ansi. May be CYGWIN codepage=none? AG P.S.: In cygwin beta 19 and 20 time was no such problem. Simple run AG chcp.com 20866 at bash-console and you can relax with koi8-r codepage. :-) See http://www.cygwin.com/ml/cygwin-patches/2002-q1/msg00064.html Egor.mailto:deo;logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: trouble using a PTY
Hi!
Sunday, 03 November, 2002 [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Fcc I'm trying to run some very simple code that uses ptys. The
Fcc code is from W. Richard Stevens APUE book. The only change is
This code is non-portable. The names of ptys are system-specific, and
not guaranteed to be named /dev/ptyXY.
On cygwin, master side of pseudo tty can be opened via
open(/dev/ptym,...). Then you can use grantpt(), unlockpt() and
ptsname() functions to access a slave side of pty.
Unfortunately, its not very portable, either. Proposed portable
interface to open master side of pseudo tty is posix_openpt(), but it
haven't been implemented on cygwin yet. Patches are gratefully
accepted (tm).
BTW, implementing this function looks like an easy prey for those who
wish to contribute something to cygwin, but afraid of complexities of
cygwin internals.
Fcc the printf you see below. In this routine:
Fcc int
Fcc ptym_open(char *pts_name)
Fcc {
Fcc int fdm;
Fcc char*ptr1, *ptr2;
Fcc strcpy(pts_name, /dev/ptyXY);
Fcc /* array index: 0123456789 (for references in following code) */
Fcc for (ptr1 = pqrstuvwxyzPQRST; *ptr1 != 0; ptr1++) {
Fcc pts_name[8] = *ptr1;
Fcc for (ptr2 = 0123456789abcdef; *ptr2 != 0; ptr2++) {
Fcc pts_name[9] = *ptr2;
Fcc /* try to open master */
Fcc if ( (fdm = open(pts_name, O_RDWR)) 0) {
Fcc printf (ptym_open, open returned errno of: %d, pts_name=%s\n,
Fcc errno,pts_name);
Fcc if (errno == ENOENT)/* different from
Fcc EIO */
Fcc return(-1); /*out of pty devices
Fcc */
Fcc else
Fcc continue;/*try next pty device
Fcc */
Fcc}
Fcc pts_name[5] = 't'; /* change pty to tty */
Fcc return(fdm);/* got it, return fd of
Fcc master */
Fcc }
Fcc }
Fcc printf (pty, at end, errno is: %d\n, errno);
Fcc return(-1); /* out of pty devices */
Fcc }
Fcc the first call to open() fails, and the printf produces:
Fcc ptym_open, open returned errno of: 2, pts_name=/dev/ptyp0
Fcc As far as I can deduce by reading cygwin docs and mailing list archives,
Fcc PTYs would be expected to work.
Fcc I'd appreciate it if someone could point me in the right direction here.
Fcc attached is output of cygcheck -s
Egor.mailto:deo;logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19
--
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/
Re: How can I use in console codepage different from ANSI and OEM?
Hi! Sunday, 03 November, 2002 Alexander Gotlib [EMAIL PROTECTED] wrote: AG Subj? For russian language ANSI-codepage is cp1251 (win1251), OEM - cp866 AG (dos866). But in unix systems used another one - koi8-r. Koi8-r is de-facto AG standart for E-mail and News messages. Therefore will be good if Cygwin AG console will receive possibility to use some different from CYGWIN AG codepage=oem and CYGWIN codepage=ansi. May be CYGWIN codepage=none? AG P.S.: In cygwin beta 19 and 20 time was no such problem. Simple run AG chcp.com 20866 at bash-console and you can relax with koi8-r codepage. :-) See http://www.cygwin.com/ml/cygwin-patches/2002-q1/msg00064.html AG Thanx for help. But I've just try this recipe and nothing win. :-( Which recipe? The thread talks about proposed patch. By looking at the announcements, you may find that the patch has never been applied to the main cygwin sources. So you can either apply it yourself and build your own version of cygwin1.dll or wait for this patch to be applied. And no, i don't know when it's supposed to be, and whether author's assignment reached Redhat. Egor.mailto:deo;logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: Assymetric network performance on cygwin
Hi! Thursday, 24 October, 2002 David Geldreich [EMAIL PROTECTED] wrote: DG And I get the following bandwidth (I am on a 100Mbit switched network) !!! DG cygwin (ttcp -r -s -fm) - linux (ttcp -t -s -fm) : 20Mbit DG linux (ttcp -r -s -fm) - cygwin (ttcp -t -s -fm) : 64Mbit I don't know exactly which APIs ttcp uses, but if it uses select() while reading the data from network, then it your results are predictable. Cygwin's select() is much slower than linux' one. Cygwin source code contains all needed information, if you want to investigate this further. If you're concerned about cygwin performance, i can pinpoint 4 major possible sources of cygwin slowness compared to, say, linux. They are fork(), stat(), select() and symlink resolution. Some work is done from time to time to decrease performance penalty from them, but as preserving correctness is the goal of higher priority, i wouldn't expect much progress in this area. Ah, ttys are not blazingly fast either. I wish people could understand that performance issues are not the ones cygwin developers are happily to snatch. Most of those issues are known for quite a long time and proved rather hard to resolve. So reports like program foo works on linux twice as fast compared to being run on cygwin is of little value to cygwin developers. Compared to linux, performance-wise, cygwin is clear looser. If you'll compare two versions of cygwin and find that old one is faster than the last one, it can possibly be a signal for action. But again, there more detailed your analysis is, the more valuable it'll be for developers. Egor.mailto:deo;logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: Another problem using GDB
Hi! Thursday, 17 October, 2002 Thomas Mellman [EMAIL PROTECTED] wrote: TM I'm having another problem with GDB. Normally, one would debug a core file TM as follows (correct?): TM gdb -nw gtl.exe gtl.exe.stackdump *.stackdump is not a corefile. To create core file, use 'dumper' utility, supplied with cygwin. Then you can debug created gtl.exe.core by issuing 'gdb --core=gtl.exe.core' command. Documentation on using dumper should be present in User's manual. Egor.mailto:deo;logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: new gdb interface
Hi! Thursday, 17 October, 2002 Thomas Mellman [EMAIL PROTECTED] wrote: TM I had to power down my box - neither kill(-9) on either the process under test, TM the debugger or the debugger window, nor even the task manager were able TM to kill the two processes, and even windows-shutdown hung. This is (probably) a bug in windows debugging interface. Similar hangs (when one tries to kill debugee or debugger, and then they both remains unkillable) are not gdb specific. They occur with any windows program which exercise debugging APIs. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: paths like //usr/local
Hi! Wednesday, 16 October, 2002 Sven Köhler [EMAIL PROTECTED] wrote: SK the sollution that paths like //comp/share are interpreted like an SK UNC-path is just not compatible with an application might expect from a SK unix-environment. Then those applications are making false assumptions. Expecting two leading slashes to be interpreted like single one is non-portable and therefore is wrong. Chris has already cited appropriate words from standard. Just fix the application. Ain't that simple? Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: pthreads in YahooPOPs
Hi! Sunday, 13 October, 2002 Andrew Lynch [EMAIL PROTECTED] wrote: AL Hopefully, the author will see the issue and rewrite AL the code in a more portable manner. Can you deduce AL what the YahooPOPs author is trying to do? Would you AL suggest a more portable method I could look at? I AL will likely be finding or writing a replacement for AL this code section and appreciate any tips. AL lock.__m_reserved = 0; AL lock.__m_count = 0; AL lock.__m_owner = 0; AL lock.__m_kind = PTHREAD_MUTEX_TIMED_NP; AL lock.__m_lock.__status = 0; AL lock.__m_lock.__spinlock = __LT_SPINLOCK_INIT; It's hard to be sure from such short snippet, but it looks like they should use pthread_mutex_init() function if they want to create a new pthread mutex and initialize it. Single Unix Specification (http://www.opengroup.org/onlinepubs/007908799/) is a standard cygwin is trying to conform to. They have all needed reference information online. Additionally, would you please keep the answers on-list? I deliberately set 'Reply-To:' to point to mailing list, because i read it along with my personal e-mail, so i don't want to get duplicate copies of one message. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: pthreads in YahooPOPs
Hi! Sunday, 13 October, 2002 Andrew Lynch [EMAIL PROTECTED] wrote: AL http://sourceforge.net/projects/yahoopops AL on Cygwin but have run into a problem with pthreads. AL The lines below do not compile even though Cygwin AL supports pthreads and pthread.h is included in the AL header file. AL lock.__m_reserved = 0; AL lock.__m_count = 0; AL lock.__m_owner = 0; AL lock.__m_kind = PTHREAD_MUTEX_TIMED_NP; AL lock.__m_lock.__status = 0; AL lock.__m_lock.__spinlock = __LT_SPINLOCK_INIT; AL Does anyone know why these pthread commands(?) are not AL supported or won't compile? The project you're talking about is using non-portable method of dealing with pthreads. Pthread interface doesn't specify an internal structure of pthread primitives, so their actual implementation may vary (and does vary) between different systems. You should ask YahooPOPs people to use portable constructs so that their code can be compiled on any system which supports pthread interface. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: Named pipes problem
Hi! Thursday, 10 October, 2002 Chris [EMAIL PROTECTED] wrote: C I have recently installed Cygwin (version 1.3.12-2) on Windows 2k (SP2) and C have been trying to evaluate by developing some small programs. One of these C uses named pipes. However none of the named pipes functions seem to work - C all return -1. perror() is your friend. C Example: C retcode = unlink (aPipe); if (retcode) perror(unlink); C retcode = mknod (aPipe, S_IFIFO, 0); if (retcode) perror(mknod); C retcode = chmod (aPipe, 0660); if (retcode) perror(chmod); C fd = open (aPipe, O_RDONLY); if (fd 0) perror(open); C return code for all functions is -1. prints: unlink: No such file or directory mknod: Function not implemented chmod: No such file or directory open: No such file or directory which should be sufficient to answer your question. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: __RUNTIME_PSEUDO_RELOC_LIST__
Hi!
Tuesday, 08 October, 2002 Danny Smith [EMAIL PROTECTED] wrote:
DS The __RUNTIME_PSEUDO_RELOC_LIST__ addition to ldscripts causes problems
DS with ld -r -o foo.o bar.o baz.o because of multiple definitions. This
DS change fixes that problem, but how will it affect intended usage of the
DS -auto-import extension?
I suppose it won't affect it. We care about __RUNTIME_PSEUDO_RELOC_LIST__
being defined only in final executable. So, this patch looks correct
to me.
DS --- pe.sc.orig Sun Sep 29 05:26:05 2002
DS +++ pe.sc Mon Oct 07 23:04:11 2002
DS @@ -85,11 +85,11 @@ SECTIONS
DS *(.rdata)
DS ${R_RDATA}
DS *(.eh_frame)
DS - ___RUNTIME_PSEUDO_RELOC_LIST__ = .;
DS - __RUNTIME_PSEUDO_RELOC_LIST__ = .;
DS +${RELOCATING+___RUNTIME_PSEUDO_RELOC_LIST__ = .;}
DS +${RELOCATING+__RUNTIME_PSEUDO_RELOC_LIST__ = .;}
DS *(.rdata_runtime_pseudo_reloc)
DS -___RUNTIME_PSEUDO_RELOC_LIST_END__ = .;
DS -__RUNTIME_PSEUDO_RELOC_LIST_END__ = .;
DS +${RELOCATING+___RUNTIME_PSEUDO_RELOC_LIST_END__ = .;}
DS +${RELOCATING+__RUNTIME_PSEUDO_RELOC_LIST_END__ = .;}
DS}
Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
Re: [PATCH] fhandler_tty doecho change
Hi! Tuesday, 24 September, 2002 Steve O [EMAIL PROTECTED] wrote: SO I was thinking about the deadlock problem some more last night, SO and it occured to me that if termios processing were done on SO the slave side, some of the buffering and tricky bits of SO flushing the write buffer would go away (maybe). And you wouldn't SO need this patch. What do you mean exactly by termios processing? And did you take into account the possibility that process which owns slave side of tty forks and child gets handle to slave too. Then child does some termios processing. Will parent use old or new termios settings? Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
Re: df --local
Hi! Friday, 20 September, 2002 Rob Brown [EMAIL PROTECTED] wrote: RB OK, that will *mostly* work except for the cdrom drive issue. The proper way is to convert path to win32 form and then use GetDriveType() and GetVolumeInformation() APIs. RB -Original Message- RB From: Igor Pechtchanski [mailto:[EMAIL PROTECTED]] RB Sent: Friday, September 20, 2002 10:29 AM RB To: Rob Brown RB Cc: [EMAIL PROTECTED] RB Subject: RE: df --local RB Well, as I said before, unless you have invalid local mounts (i.e., RB without the drive name), all your local mounts will have a : as part of RB the name. RB Igor RB On Fri, 20 Sep 2002, Rob Brown wrote: Yea, except that I wanted this script to run on a bunch of machines, all with different drive letters and configurations. Is there no other way for cygwin to know whether a drive is local or not? Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
missing w32-shared-ptr.c
Hi! Maybe i'm running slightly ahead of the train, but it looks like w32-shared-ptr.c haven't been actually added to repository. Neither trying to check it out nor looking for it via cvsweb interface helps. Is it unintentional omission during check-in, or i just don't understand something? I'm working on cygwin-mingw-gcc-3_2-branch. 2002-08-16 Danny Smith [EMAIL PROTECTED] crtstuff.c (__do_frame_init): Call __w32_sharedptr_initialize. config/i386/t-cygming (LIB2FUNCS_EXTRA): Add __w32_sharedptr_initialize.c config/i386/t-mingw32 (LIB2FUNCS_EXTRA): Adjust for common component in t-cygming. * config/i386/w32-shared-ptr.c (__w32_sharedptr_initialize): Initialize default terminate and uncaught_exception handlers to abort. Remove dependency on windows.h. 2002-08-16 Adriano dos Santos Fernandes [EMAIL PROTECTED] * unwind-dw2-fde.c (unseen_objects, seen_objects): Support for w32 catch exceptions across EXE/DLLs boundaries. * config/i386/w32-shared-ptr.c: New file. Initialize shared pointers. egor.mailto:[EMAIL PROTECTED] icq 5165414 fidonet 2:5020/496.19
Re: --enable-auto-import extension
Hi! Wednesday, 03 July, 2002 Charles Wilson [EMAIL PROTECTED] wrote: CW The new version looks good to me; I built and ran your test without CW problems. I do have a suggestion for later, when CW --enable-runtime-pseudo-reloc is made the default: in pe-dll.c (around CW line 2209) change CW if (pe_dll_extra_pe_debug) CWprintf (creating runtime pseudo-reloc entry for %s (addend=%d)\n, CW fixup_name, addend); CW to CW if (link_info.pei386_runtime_pseudo_reloc == -1) CWinfo_msg (_(creating runtime pseudo-reloc entry for %s (addend=%d)\n), CW fixup_name, addend); CW So that if pseudo_reloc is implicitly enabled, print messages for each CW psuedo-reloc entry (but not all that other pe_dll_extra_pe_debug stuff). CW It's not a warning, but its info the user probably needs to know if he CW didn't explicitly say --enable-runtime-pseudo-reloc. Agreed. CW The business with fork() and -DNO_RUNTIME_PSEUDO_RELOC_SUPPORT stuff in CW your example is a bit confusing -- do you have some pending CW patches to cygwin1.dll? Yes, i've sent them yesterday to cygwin-patches@. Of course, they should be added after new binutils package (in which ld exports ___RUNTIME_PSEUDO_RELOC_LIST__ and ___RUNTIME_PSEUDO_RELOC_LIST_END__) is released. Or we can only export them in pe.sc for now, and go ahead with cygwin (and mingw, if anybody's interested) change. It'd just have no effect until full ld patch is applied. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
Re: --enable-auto-import extension
Hi! Tuesday, 02 July, 2002 Charles Wilson [EMAIL PROTECTED] wrote: What i was talking about is 64-bit versions of windows where addresses (and so base symbol values and addends are 64-bit). Or if we want to add some other types of relocations. Adding type field will make it possible to add extensions to this feature. CW /sheepish Yeah. What he said. I'll be over here Well, after thinking twice about it i concluded that such flexibility may be not that good after all. Sure, it allows adding extensions, but make it hard to check at link-time if runtime support for those extensions is present. So i think we can stay with simple format of pseudo relocations for now. Of course. Luckily, all we have to check is that it doesn't change binaries for existing code, CW Hard to do, really -- DLLs get a timestamp in their header, so even CW under ideal conditions you can't do a simple diff on two DLLs...I CW suppose you could make sure that two DLLs differ ONLY in unimportant CW ways, like timestamp. Someone suggested that one can do 'cmp -i 150 old.dll new.dll', or whatever offset timestamp is located at. Ok, i've finalized patch and test. I suppose i have a copyright assignment with FSF for this changes to get incorporated into official sources. As far as i understand, i have to get an assignment form from binutils maintainer, right? Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 include.ChangeLog Description: Binary data include.diff Description: Binary data ld.ChangeLog Description: Binary data ld.diff Description: Binary data crtest.c Description: Binary data crtest.h Description: Binary data crtest_dll.c Description: Binary data Makefile Description: Binary data
--enable-auto-import extension
Hi! Currently, --enable-auto-import feature of ld has a limitation of not allowing importing dll data, which resides at some offset from exported symbol. This limitation is derived from limitation of native win32 loader which can't handle such imports. There're ways to work around such limitation, by changing code so that it adds offset at runtime, but it won't work very well in case when reference is in data segment. For instance, when g++ emits exception handling information, it puts pointer to vtable+8bytes to data segment. If vtable is imported from dll, application can't auto-import it, and have no clean way to work around it. Clean way to handle such situations (other than convincing Microsoft to change a loader) is to add some runtime support for non-zero-offset imports. The idea is to add a vector of cygwin internal pseudo-relocation entries to executable data section and to perform relocations of appropriate data manually at program startup. Attached is a proof-of-concept patch to ld and simple testcase. If this idea is worthwhile, i think i should add more things to the patch: 1. Make cygreloc generation conditional via --enable-cygwin-reloc or something like that. 2. If linker creates at least one cygreloc entry, it should emit reference to some external symbol, say 'cygwin_process_cygreloc' so that if object contains non-empty cygreloc vector it'd be guaranteed that it can't be linked with runtime without cygreloc support. 3. Make relocations a bit more flexible by adding type and size (possible 64-bit support?) Comments? egor.mailto:[EMAIL PROTECTED] icq 5165414 fidonet 2:5020/496.19 crtest.c Description: Binary data crtest_dll.c Description: Binary data ld.diff Description: Binary data Makefile Description: Binary data
Re: mingw and other gotchas in gcc 3.1
Hi! Monday, 24 June, 2002 Conrad Scott [EMAIL PROTECTED] wrote: CS egor duda [EMAIL PROTECTED] wrote: Btw, libstdc++ in gcc 3.* is configured so that classes in std:: namespace are not visible unless one specify std:: via 'using' or explicitly. I feel this can be the problem that will make most noise. Cygwin setup is just one example of program affected. I have a patch that should work with both 2.95.3 and 3.*, and can post it if you're interested. CS As I understood this (that's a disclaimer), if you include the CS legacy headers, i.e. xxx.h, you get the names in the global CS namespace and it's only if you include the new headers, i.e. xxx, CS that you need the std:: qualifier or a using declaration. Of course, CS people may now be using the new headers without then using the std:: CS qualifier, since gcc 2.95.3 allows this. But they're wrong already :-) CS (not that that ever stopped someone complaining). CS Or have they abandoned the legacy headers altogether? No. But iosfwd and string and bunch of others are present in both old and new g++ headers. So, program like setup.exe which contain #include iosfwd and then 'ostream ostr;' would compile no more until someone changes 'ostream ostr;' to 'std::ostream ostr;' Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
Re: mingw and other gotchas in gcc 3.1
Hi! Monday, 24 June, 2002 Christopher Faylor [EMAIL PROTECTED] wrote: CF I'm finishing up on the release of gcc 3.1 and I have a few gotchas that CF I'd like to discuss: CF 1) I was going to take Red Hat's cue and release the new version of CFgcc as gcc3. However, this will require manual deinstallation of CFgcc (2.95.3-whatever) so this is probably a bad thing. Somehow, I CFjust think that if we don't still make the older version of gcc CFavailable, there will be many This used to build on gcc 2.95.3!!! CFmessages. CFSo, maybe I should rename the old version to gcc2 or release a version CFof 2.95.3 that names the binaries (i686-pc-cygwin-gcc2) differently. CFAny thoughts? This should be ok. There're also libstdc++ header files but, fortunately, dirs are named differently (g++-3 for 2.95.3 and g++-v3 for 3.*). Can we make sure that this will remain so? Btw, libstdc++ in gcc 3.* is configured so that classes in std:: namespace are not visible unless one specify std:: via 'using' or explicitly. I feel this can be the problem that will make most noise. Cygwin setup is just one example of program affected. I have a patch that should work with both 2.95.3 and 3.*, and can post it if you're interested. One more problem is min() and max() macros in windef.h. They conflict with min and max functions from std_limits.h. I've patched std_limits.h to #undef min and #undef max, but applications which do the following: #include windows.h // even if it's included non-directly #include limits ... x = max (a, b); would break. I haven't found better solution for this, other than mention it in release notes, though. CF 2) I'm trying to remove most of the spec file magic that dealt with CFmingw and I think I've actually been pretty successful. However, CFmy new scheme relies on changing the machine name from i686-pc-cygwin CFto i686-pc-mingw. That means that the new layout looks like this: CF /usr/i686-pc-mingw/: CF total 0 CF lrwxrwxrwx1 cgf None 122 Jun 23 23:41 bin - ../i686-pc-cygwin/bin CF lrwxrwxrwx1 cgf None 125 Jun 23 23:42 include - /usr/include/mingw CF lrwxrwxrwx1 cgf None 113 Jun 23 23:42 lib - /usr/lib/mingw CF /usr/lib/gcc-lib: CF total 0 CF drwxr-xr-x4 cgf None0 Dec 25 2000 i686-pc-cygwin CF lrwxrwxrwx1 cgf None 108 Jun 23 23:48 i686-pc-mingw - i686-pc-cygwin CFIdeally, the include, lib stuff in /usr/i686-pc-mingw should not be a CFsymbolic link but should, instead, be the actual directories that they CFreference. However, coordinating this will be tricky. I'm thinking that CFI should just add a postinstall script that will try to do the right thing CFif /usr/i686-pc-mingw doesn't have the right stuff. However, I'd like to CFconfirm with Earnie/Danny that this new layout makes sense. Do you think bin/ should contain cygwin-mingw cross-tools instead of being link to i686-pc-cygwin? CFFWIW, I think this is the way I should have laid stuff out originally. CF 3) The above layout has a problem. It works ok generating mingw binaries but, CFwith gcc-3.1, I've configured things using --enable-threads=posix. So, some CFbinaries don't link successfully. That means that the libgcc.a library is CFinappropriate for mingw. So, the above directory layout can potentially CFbecome a little trickier since I'll need to build a libgcc.a (and libstdc++.a, CFI guess) for mingw. This seems like a lot of duplication of effort, though, CFso maybe I'll try to figure out some way to download the bits that I need CFfrom sourceforge or something. Or,... CF 4) Since mingw is becoming so logically separated from gcc, it is possible that CFit could become a separate package. So, if someone was willing to supply CFa gcc-mingw package, it would actually be helpful. I don't think I could CFstand the pain of making this optional, so the gcc package would rely on CFthe gcc-mingw package rather than the other way around. This would allow CFupdating libgcc.a and libstdc++.a without requiring a new release of gcc. CFHmm. I wonder if I should break libstdc++.a out of the gcc package. Urgh. CFAny suckers (cough) want to contribute a separate package? libstdc++ seems to be a problem, no matter what was passed to --enable-threads. I agree that libstdc++ (and libgcc in case of --enable-threads=posix) stuff for mingw should be packaged separately. I build them by hand and tested cygwin setup with them, but i still have no automatic script to produce such package. CF I've been toiling away at this for some time, so I'd appreciate any CF useful suggestions. My next hurdle is updating the gcc cygwin 3.1 CF branch with the latest changes in the gcc 3.1 branch. Have you created cygwin branch in gcc repository? I've seen your question about it in [EMAIL PROTECTED]
Patch to add NtShutdownSystem() to w32api
Hi! NtShutdownSystem() is crude no-caches-flushed-and-no-apps-notified but almost always working way to restart nt system. egor.mailto:[EMAIL PROTECTED] icq 5165414 fidonet 2:5020/496.19 w32api-ntshutdownsystem.diff Description: Binary data w32api-ntshutdownsystem.ChangeLog Description: Binary data
Re: Patch to add NtShutdownSystem() to w32api
Hi! Sunday, 16 June, 2002 Earnie Boyd [EMAIL PROTECTED] wrote: EB egor duda wrote: NtShutdownSystem() is crude no-caches-flushed-and-no-apps-notified but almost always working way to restart nt system. EB Uh, these aren't yet a part of w32api. Cygwin, supplies a header for EB one in winsup/cygwin and I know that both WINE and ReactOS both have EB their own versions. We have discussed on the mingw-dvlpr list of EB possibly adding this so that everyone doesn't have to invent new EB wheels. I see that you have a new file for ntdll.h but from where did EB you get your ntdll.def? Huh? Hasn't it just been added to winsup/w32api/lib? http://sources.redhat.com/ml/cygwin-cvs/2002-q2/msg00276.html Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
Re: Need documentation for dumper.exe
Hi! ed Tuesday, 11 June, 2002 Christopher Faylor [EMAIL PROTECTED] wrote: CF I just noticed that dumper.exe is not documented in utils.sgml. CF Is anyone interested in taking a stab at it? There should be lots of CF info in the mailing list archives. Patch attached. Can anybody with sgml tools installed please check if formatting is ok? Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 dumper-docs.diff Description: Binary data dumper-docs.ChangeLog Description: Binary data
Re: regtool support for remote registry
Hi! Thursday, 06 June, 2002 Corinna Vinschen [EMAIL PROTECTED] wrote: CV On Thu, Jun 06, 2002 at 02:11:46PM +0400, Egor Duda wrote: Attached patch allows regtool to access registry on remote hosts, e.g.: regtool get \\bumba\machine\software\microsoft\windows\currentVersion\programFilesDir CV Just a question: Wouldn't it make sense to use a syntax as rcp/scp: CV regtool get bumba:\machine\software\microsoft\... CV This together with the capability to use forward slashes looks CV more unixy: CV regtool get bumba:/machine/software/microsoft/... CV In this context I see for the first time, that the usage doesn't CV say anything about using forward slashes. Shouldn't we add a word CV that this is possible, too? No probs. This should support both formats. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 regtool-remote-registry-support-2.diff Description: Binary data regtool-remote-registry-support-2.ChangeLog Description: Binary data
regtool support for remote registry
Hi! Attached patch allows regtool to access registry on remote hosts, e.g.: regtool get \\bumba\machine\software\microsoft\windows\currentVersion\programFilesDir egor.mailto:[EMAIL PROTECTED] icq 5165414 fidonet 2:5020/496.19 regtool-remote-registry-support.diff Description: Binary data regtool-remote-registry-support.ChangeLog Description: Binary data
mknetrel generalisation patch
Hi! attached is a patch to make possible to use mknetrel on host different from sourceware. build-host-specific parameters are read from ~/.mknetrel file. i've tried to preserve old behaviour, but, possibly, there's no real need for default initializations in read_user_config() Comments? egor.mailto:[EMAIL PROTECTED] icq 5165414 fidonet 2:5020/496.19 mknetrel.diff Description: Binary data mknetrel.ChangeLog Description: Binary data
Re: Annoying cmd console spawn with remote access and Win 2000
Hi! Friday, 17 May, 2002 Pawel Czechowicz [EMAIL PROTECTED] wrote: PC Do you think that I want to use this crappy Window$ stuff? No, I am PC forced to! This OS was bought for me by my employer and I am obliged to PC be happy with it!!! The same with VC++ and so on. PC THIS IS A CRY FOR HELP! there's absolutely no need for shouting. you may want to take a look at http://ns.logos-m.ru/~deo/ttyfier.html Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: [MinGW-dvlpr] Re: gcc 3.1 [-mno-cygwin and __main ]
Hi! Wednesday, 15 May, 2002 Christopher Faylor [EMAIL PROTECTED] wrote: I don't know how (when/if) cygwin will implement dwarf2 EH. Richard Henderson's patch was spot on, except for wrong use of -1 rather than 0 as sentinel for end of eh_frame table. My preference is to try to keep the differences between mingw and cygwin in gcc code as small as possible. CF For sure. I'd like there to be no difference at all, if possible. CF I'd like to either create a cygwin-mingw branch on the main repository CF or create a completely separate CVS repository so that we could CF coordinate patches. Would you be interested in doing this, Danny? I CF can see that we'll be in patch hell otherwise. I have a local sandbox CF with your changes but it appears to be out-of-date already. That'd be great. I believe i can try to step in as cygwin gcc maintainer (at least i currently do have both time and willingness for that). Having cvs branch or separate repo would make things easier. I certainly lost a track for cygwin- and mingw-specific patches some time ago. Btw, Chris, some time ago there was a discussion of would be cygisolate or cygjail of cyg-some-other-fancy-name utility to allow several independent cygwins running simultaneously on the same machine. As long as you've added appropriate cygwin_internal hooks, i suppose you have this utility. If it's so, would you mind putting it winsup/utils ? Using it would certainly make testing of new packages more robust. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: connect() does not work with UNIX domain datagram sockets
Hi! Tuesday, 02 April, 2002 DEVRIENDT ERIK [EMAIL PROTECTED] wrote: DE I am porting a client-server set of programs that run DE fine under linux. DE The programs communicate using UNIX domain datagram sockets. DE the server does the classic socket(), unlink(), bind() and then a loop DE with read(). There is no accept() because we use datagram DE sockets. DE The problem is in the client, which does socket(), connect() DE and then a loop with write() calls. DE The connect() hangs for 10 seconds and then fails with errno=111 DE (Connection refused). DE When using sendto() I manage to send data, but that doesn't fit well DE in the current implementation of the client (we use the same DE codebase for several platforms). DE According to the man pages of select() on linux and HP-UX it is allowed DE to use connect() with datagram sockets; it sets the default destination DE address for the communication over that socket. DE Is this a cygwin bug, or am I doing something wrong ? It may be cygwin bug. You can do a couple of things to help us to find it out. First, send a test program to the list, i'll try to reproduce the problem. Second. Try running your program using strace utility, like this: strace -f -b 65000 -o strace.log some_program.exe Then look into strace.log. I bet it will contain a string accept from unauthorized server string (or connect from unauthorized client). If that's so, can you please send me strace.log.bz2 via personal e-mail to [EMAIL PROTECTED] ? Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: dumper.exe help/version patch
Hi! Saturday, 09 March, 2002 Christopher Faylor [EMAIL PROTECTED] wrote: CF On Fri, Mar 08, 2002 at 10:53:28PM -0800, Joshua Daniel Franklin wrote: Here is the next in the series of patches to standardize the help and version options in the utils. This also adds GNUish options to dumper. I left the Compiled on __DATE__ out of print_version since there is a #ifdef __GNUC__ in the file and I don't know whether that trick works with all compilers. 2002-03-09 Joshua Daniel Franklin [EMAIL PROTECTED] * dumper.cc (usage) Standardize usage output. Generalize to allow use for help. (longopts) New struct. Added longopts for all options. (print_version) New function. (main) Change getopt to getopt_long. Accommodate new help and version options. CF I'd like Egor to approve this patch, if possible. i have no objections to this patch. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
Re: Descriptor passing between process
Hi! Wednesday, 23 January, 2002 Corinna Vinschen [EMAIL PROTECTED] wrote: CV On Wed, Jan 23, 2002 at 10:55:07AM +0100, Christophe LEITIENNE wrote: I'm using Cygwin 1.3.8 on a Windows 2000 box. I'm looking for a way to pass a socket descriptor between 2 process, using sendmsg and recvmsg on a unix named pipe. This procedure seems to be well knowned and works well on Linux and AIX. I didn't found anything interesting about it in the mailing list archives, except someone who started to port this API to Cygwin some time ago, without any further informations. am I doing something wrong ? Will this API be ported to Cygwin in a near future ? CV It's part of the API since 1.3.8-1. Hmm. What change are you referring to? I don't see anything like this in the ChangeLog. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: STATUS+AF8-ACCESS+AF8-VIOLATION Exception
Hi!
Thursday, 24 January, 2002 Amos [EMAIL PROTECTED] wrote:
A Any simple c program that uses a string function crashes with the
A STATUS_ACCESS_VIOLATION exception.
A #include string.h
A main()
A {char *abc = a b c;
A strcpy(abc, hello);
A printf(%s\n, abc);
A }
your program is incorrect. a b c string is a constant and can't be
overwritten. complier places it in read-only segment, hence the
exception in strcpy. Please refer to any C language manual for rules
of proper string manipulation.
Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
--
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/
Re: setregid and setreguid
Hi! Thursday, 24 January, 2002 J S [EMAIL PROTECTED] wrote: JS Hi, JS I'm trying to compile eterm on cygwin, but running into problems because it JS needs setregid and setuid. I noticed that these were in the cygwin package JS testsuite and so I tried to compile that but the make file wouldn't work. JS Are there any binaries around for setregid and setreguid? If you look a bit closer upon cygwin testsuite, or run it at least once, you see that setregid and setuid tests are known to fail. Exactly because these functions are not supported. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: cygwin console
Hi! Wednesday, 09 January, 2002 Pavel Tsekov [EMAIL PROTECTED] wrote: its very good. Bad i have some program with ncurses. On the screen i see the box() function in curses creates an ugly looking box, where the extended characters drawing the box (ACS_VLINE, ACS_HLINE) are replaced with characters from the lower ASCII set (3 and Ä). This code works fine under VT100 terminal settings. PT If you set the global CYGWIN environment variable to codepage:ansi the PT problem should disappear - or am I wrong ? exactly the opposite. codepage:ansi is a default setting, and to draw pretty boxes one should use codepage:oem. Ain't it mentioned in ncurses README? Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: 1.3.6-6 CVS: BUG: opendir() returns ENOTDIR whereas ENOENT would probably be a better choice...
Hi!
Friday, 04 January, 2002 Christopher Faylor [EMAIL PROTECTED] wrote:
CF On Fri, Jan 04, 2002 at 09:59:31PM +0300, egor duda wrote:
Friday, 04 January, 2002 Alexei Lioubimov [EMAIL PROTECTED] wrote:
AL cvs [checkout aborted]: cannot open directory .../CVS/mypoj/Attic: Not a
AL directory
AL I send this error to info-cvs mailing list and they said, that it is due to
AL opendir() implementation in cygwin (it returns ENOTDIR instead of
AL ENOENT in most cases :( ).
this program prints 'errno=2', which is correct ENOENT result.
#include sys/types.h
#include stdio.h
#include dirent.h
#include errno.h
int main()
{
DIR* x = opendir ( /tmp/wazoof );
if (!x)
printf ( errno=%d\n, errno);
}
AL Will it be corrected in cygwin or in cygwin port of CVS?
care to provide a simple self-contained testcase?
CF Egor,
CF I just checked in a fix for this. Are you using the latest CVS?
argh, probably not. it looks like the problem was introduced with
fhandler_cygdrive thingie, and i was using earlier dll. sorry for
confusion.
CF I already had a test case sitting around for this so it probably is a
CF regression and I probably should add something to the test suite.
would be nice. i'll try to dig out a testcase (i vaguely remember i
had one that needed some tweaking) and add it to testsuite.
Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
--
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/
Re: w32api header problems
Hi! Wednesday, 09 January, 2002 Jean le Roux [EMAIL PROTECTED] wrote: JlR On Wed, Jan 09, 2002 at 01:07:47PM +0300, egor duda wrote: Hi! Wednesday, 09 January, 2002 Jean le Roux [EMAIL PROTECTED] wrote: JlR I need to include /usr/include/w32api/winbase.h in order to use the JlR GetVolumeInformation(...) system call under windows. JlR However, as i metioned in an earlier mail, DWORD seems to not be JlR defined. I tracked DWORD's definition down to windef.h.. but it seems JlR the whole include chain is a bit funny.. there are lots of JlR inter-dependencies which are not satisfied. JlR Does anyone have any words of wisdom to make life a little easier, or JlR do I simply have to test for, and include, all the headers in w32api ? you ought to #include windows.h JlR I've done this but windows.h seems to leave my code in a tangle :) JlR I suddenly have parse errors in my own header files, on normal JlR function declerations. I can only deduce that windows.h is leaving an JlR open ifdef or has unterminated strings or something silly. it's easy to find out what the reason is. gcc has a very useful option '--save-temps'. it instructs preprocessor, compiler and assembler to leave their temporary files in place, so if you compiling, say, zzz.c, you'll get zzz.i (output of preprocessor), zzz.s (assembly source -- output of compiler) and zzz.o (compiled binary object). You want to look into zzz.i it shows what your source file turns into, and it's almost always easy to see why. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: w32api header problems
Hi! Wednesday, 09 January, 2002 Jean le Roux [EMAIL PROTECTED] wrote: JlR On Wed, Jan 09, 2002 at 04:47:18PM +0300, egor duda wrote: JlR I've done this but windows.h seems to leave my code in a tangle :) JlR I suddenly have parse errors in my own header files, on normal JlR function declerations. I can only deduce that windows.h is leaving an JlR open ifdef or has unterminated strings or something silly. it's easy to find out what the reason is. gcc has a very useful option '--save-temps'. it instructs preprocessor, compiler and assembler to leave their temporary files in place, so if you compiling, say, zzz.c, you'll get zzz.i (output of preprocessor), zzz.s (assembly source -- output of compiler) and zzz.o (compiled binary object). You want to look into zzz.i it shows what your source file turns into, and it's almost always easy to see why. JlR Fair enough.. but how do i turn it on with autotools.. configure does JlR not seem to support such a flag. 1st way: redirect make output to file, cut'n'paste the failed command. then add the option and run resulting command. 2nd way: edit Makefile to add this option in the appropriate place (usually, CFLAGS or CXXFLAGS) then run 'make zzz.o' Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: 1.3.6-6 CVS: BUG: opendir() returns ENOTDIR whereas ENOENT would probably be a better choice...
Hi!
Friday, 04 January, 2002 Alexei Lioubimov [EMAIL PROTECTED] wrote:
AL cvs [checkout aborted]: cannot open directory .../CVS/mypoj/Attic: Not a
AL directory
AL I send this error to info-cvs mailing list and they said, that it is due to
AL opendir() implementation in cygwin (it returns ENOTDIR instead of
AL ENOENT in most cases :( ).
this program prints 'errno=2', which is correct ENOENT result.
#include sys/types.h
#include stdio.h
#include dirent.h
#include errno.h
int main()
{
DIR* x = opendir ( /tmp/wazoof );
if (!x)
printf ( errno=%d\n, errno);
}
AL Will it be corrected in cygwin or in cygwin port of CVS?
care to provide a simple self-contained testcase?
Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
--
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/
Re: gcc -mno-cygwin fail -- undefined reference to `_impure_ptr'
Hi!
Wednesday, 12 December, 2001 Jari Aalto+mail.emacs [EMAIL PROTECTED] wrote:
JAme Does anyone know why following code fails? Do I need some
JAme other libraries or gcc compile options? This is latest
JAme Cygwin / W2k Pro / srv.p. 2
JAme ---
JAme #include stdio.h
JAme #include stdlib.h
JAme #include X11/Intrinsic.h
you're including headers for X11 libraries. they're not supported by
mingw.
JAme main ()
JAme {
JAme fprintf(stdout, To stdout\n);
JAme printf(Reading stdin now. Type character: );
JAme }
Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
--
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/
Re: Debug version of cygwin dll
Hi! Wednesday, 05 December, 2001 Peter Buckley [EMAIL PROTECTED] wrote: PB You need to bunzip2 and untar the src, then cd to PB /usr/src/cygwin-1.3.5-3 (or wherever you extracted it to) and do the PB following: PB mkdir build PB cd build PB ../configure PB make PB make install please, don't make wrong suggestions! this way is _wrong_. for a correct way, check the FAQ, particularly question How do I rebuild the tools on my NT box? cygwin sources also contain a file how-to-debug-cygwin.txt which contains several debugging hints. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
