RE: LogFile Q
OH, and resizable pages would be wonderful :}. Rob > -Original Message- > From: Gary R. Van Sickle [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 24, 2002 2:34 PM > To: Cygwin-Apps > Subject: Rob: LogFile Q > > > In LogFile::exit() there's code like this: > > if (exit_msg) > note (NULL, exit_msg); > > note() (among other duties) pops up a MessageBox() with the > text of the exit_msg at the end of the install. I'm trying > to eliminate the trailing "Install complete" popup, and > anyway it doesn't seem to be the best practice to be popping > up dialogs this deep in non-UI code. OK if I begin a process > of hoisting this out, maybe with a note_nobox() on successful > install initially? > > -- > Gary R. Van Sickle > Brewer. Patriot. > >
RE: LogFile Q
Sure. The logging capability has -nothing- to do with that message. It's a workaround for the lack of global destructor calling on exit that it's called from there. I'd suggest you simply make a new window for the wizard and show the message there. Rob > -Original Message- > From: Gary R. Van Sickle [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 24, 2002 2:34 PM > To: Cygwin-Apps > Subject: Rob: LogFile Q > > > In LogFile::exit() there's code like this: > > if (exit_msg) > note (NULL, exit_msg); > > note() (among other duties) pops up a MessageBox() with the > text of the exit_msg at the end of the install. I'm trying > to eliminate the trailing "Install complete" popup, and > anyway it doesn't seem to be the best practice to be popping > up dialogs this deep in non-UI code. OK if I begin a process > of hoisting this out, maybe with a note_nobox() on successful > install initially? > > -- > Gary R. Van Sickle > Brewer. Patriot. > >
Rob: LogFile Q
In LogFile::exit() there's code like this: if (exit_msg) note (NULL, exit_msg); note() (among other duties) pops up a MessageBox() with the text of the exit_msg at the end of the install. I'm trying to eliminate the trailing "Install complete" popup, and anyway it doesn't seem to be the best practice to be popping up dialogs this deep in non-UI code. OK if I begin a process of hoisting this out, maybe with a note_nobox() on successful install initially? -- Gary R. Van Sickle Brewer. Patriot.
RE: libpng dependencies
Chuck, I just fixed the WindowMaker setup.hint. I couldn't figure out what was where when I made the dependency, so I just picked the cleanest looking name :) Thanks for pointing this out. Harold > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Wilson > Sent: Thursday, May 23, 2002 11:50 PM > To: [EMAIL PROTECTED] > Subject: libpng dependencies > > > Attn maintainers: > > There are a number of packages that list 'libpng' as a requirement. > However, that's probably incorrect. You probably want to depend on > 'libpng10' (which contains cygpng10.dll) or 'libpng12' (which contains > cygpng12.dll) or 'libpng2' (which contains cygpng2.dll). > > Also, some packages list BOTH 'libpng' and 'libpng10' as requirements. > I'm pretty sure that's wrong, since 'libpng' really only contains > documentation these days. It's possible you want to require 'libpng10' > and 'libpng12-devel'. > > Please check your setup.hints: >WindowMaker >tetex >texmf-base >texmf-tiny > > Ghostscript maintainer: be sure to update your libpng2 dependency to the > appropriate package (libpng10 or libpng12) the next time you recompile. > > --Chuck >
Re: libpng dependencies
Christopher Faylor wrote: > > You know, I could modify upset so that you could do something like: > > requires: cygwin1.dll cygpng10.dll > > without too much effort. as opposed to 'libpng10' (the package which contains cygpng10.dll)? Mebbe. I know that rpm auto-computes that kind of dependency. But in the case of libpngX, it's a one-to-one mapping. For other packages, where package 'bar' contains 'cygbar.dll' and some import libs and some executables and some headers, it might be helpful. I dunno. It's up to the people who *depend on* libpng. As for my packages, when I write the requires: line, I just check what package contains the dlls I need and put it in. Oh, but your version would auto-update the dependency (so that the correct *package* is chosen) based on where the dll is. In case some tomfool library maintainer goes and restructures his packages. U, nobody here but us mice... > > Would this be worthwhile? Yes, given the auto-correcting behavior it would bestow. --Chuck
Re: libpng dependencies
On Thu, May 23, 2002 at 11:49:43PM -0400, Charles Wilson wrote: >Attn maintainers: > >There are a number of packages that list 'libpng' as a requirement. >However, that's probably incorrect. You probably want to depend on >'libpng10' (which contains cygpng10.dll) or 'libpng12' (which contains >cygpng12.dll) or 'libpng2' (which contains cygpng2.dll). You know, I could modify upset so that you could do something like: requires: cygwin1.dll cygpng10.dll without too much effort. Would this be worthwhile? cgf
libpng dependencies
Attn maintainers: There are a number of packages that list 'libpng' as a requirement. However, that's probably incorrect. You probably want to depend on 'libpng10' (which contains cygpng10.dll) or 'libpng12' (which contains cygpng12.dll) or 'libpng2' (which contains cygpng2.dll). Also, some packages list BOTH 'libpng' and 'libpng10' as requirements. I'm pretty sure that's wrong, since 'libpng' really only contains documentation these days. It's possible you want to require 'libpng10' and 'libpng12-devel'. Please check your setup.hints: WindowMaker tetex texmf-base texmf-tiny Ghostscript maintainer: be sure to update your libpng2 dependency to the appropriate package (libpng10 or libpng12) the next time you recompile. --Chuck
RE: binutils status ?
> > > 3) Ralf's patch for "objdump/cygwin crashes on auto-imported libs" > > > > > This patch does not help in this case. I will inspect this and supply > > a updated > > patch. > > Appended is a patch for ... see the ChangeLog entry. If have tested this patch with my cygin /bin dir (345 files) and rebinded kde 2.2.2 dll's and exes (335 files) and have got no problems with printing import tables. 2002-05-23 Ralf Habacker <[EMAIL PROTECTED]> * peXXigen.c (pe_print_idata): fixed some seg faults on printing import tables with auto-imported symbols. Regards Ralf objdump_ai_segfault_2.patch Description: Binary data
question about objdump output format ?
Hi all, the windows runtime linker allows rebinding of dll's and exe for which I have written a tool currently located on the kde-cygwin project on http://sourceforge.net/project/showfiles.php?group_id=27249. A side effect of this is, that objdump prints each line twice (the second line contains no additional infos), which blows up listing on bigger libs (for example about 35000 lines of 100860 for the kdecore dll from kde 2.2.2), so my question is, are there any objections for removing this ? 001540f0 0017f218 00189390 3934 DLL Name: qt-2-3.dll vma: Hint/Ord Member-Name 181798844 _7QString$null 5ff556b8 The Import Address Table (difference found) vma: Hint/Ord Member-Name 5ff556b8 844 _7QString$null Regards Ralf Habacker
RE: binutils status ?
Relating to this patch for peXXigen.c bfd/peXXigen.c: >date: 2002/05/15 15:28:12; author: nickc; state: Exp; lines: +54 -3 >Do not assume that the first thunk is located in the same section as the >import table. Instead check, and if necessary load the section containing >the thunk. I have a question, which can perhaps answer anyone: Does symbols, for which this patch is, are located in the text segment ? The reason for this questioin is, because for auto-imported symbols the first_thunk entry of the IMAGE_IMPORT_DESCRIPTOR points directly into the text segment to a pointer and not(!) to an IMAGE_IMPORT_BY_NAME structure, which lets the following codefragement crashes. peXXigen.c::pe_print_idata() --- get IMAGE_IMPORT_BY_NAME structure values ordinal = bfd_get_16 (abfd, data + iat_member - adj); member_name = (char *) data + iat_member - adj + 2; fprintf (file, "\t%04lx\t %4d %s\n", (unsigned long) iat_member, ordinal, member_name); } Or does anyone another idea how to solve this ? Ralf
Packaging error in squid-2.4.STABLE6-1 ?
Hi There seems to be a packaging error in the newly released squid-2.4.STABLE6-1: There is the following empty directory structure under /usr ./doc - ./doc/Cygwin <-|Should these be empty ? ./doc/squid-2.4.STABLE6 - ./logs ./src - ./src/squid | ./src/squid/package | ./src/squid/package/squid-2.4.STABLE6 | ./src/squid/package/squid-2.4.STABLE6/.inst <-| Should these be there at all ? ./src/squid/package/squid-2.4.STABLE6/.inst/usr | ./src/squid/package/squid-2.4.STABLE6/.inst/usr/doc | ./src/squid/package/squid-2.4.STABLE6/.inst/usr/doc/Cygwin| ./src/squid/package/squid-2.4.STABLE6/.inst/usr/doc/squid-2.4.STABLE6 - Ciao Volker
RE: Problem with cygwin install.
> -Original Message- > From: Ralf Habacker [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 23, 2002 4:40 PM > To: Cygwin-Apps; Robert Collins > Subject: FW: Problem with cygwin install. > > > > From: Don Thorp [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, May 22, 2002 8:53 PM > > To: [EMAIL PROTECTED] > > Subject: Problem with cygwin install. > > > > > > I'm excited to try the software out, but while I was > installing it I > > received several warnings. I've attached to images for your review. > > > Do you have an idea, why this could happen ? The archive is > valid, unpacking by hand works. Nope. You'll need to debug it. I tested this after Nicholas's recent remondier and it worked for me. Rob
Re: new package offering: zsh
Peter A. Castro wrote: > On Wed, 22 May 2002, Charles Wilson wrote: > > >>No -- if zsh can handle cr+lf internally, then let it do so. Explicitly >>open function files in binary mode -- this will override the "textmode >>mount" which sets the default read mode. >> > > zsh uses the open() call, not fopen(). There is no "binary" vs. "text" > mode to specify. Theoretically, open() should be opening the file in > binary mode already (ie: no text translation/interpretation), yet the > data read in clearly is being cooked under some scenarios. No, if I > understand how things are work here, I believe the carriage control > processing is being done at the filesystem level, which is below open() > and beyond my control. > But, like I said, if this causes enough trouble for people, I'll update > the code to be more relaxed on the size checking. You can use the "O_BINARY" flag in open() calls -- but since some platforms don't define it, you must include something like #ifndef O_BINARY #define O_BINARY 0 #endif somewhere in zsh's header files open() will still obey the default mount mode settings of the underlying cygwin system; that is, if the file is on a text mount, it will be opened using CR/LF-->LF translation. If the file is on a binary mount, it will be opened in O_BINARY mode. include O_BINARY in your open call to force binary mode on the file. But, an ounce of experience is worth a pound of theory...all I've got is theory. :-) --Chuck
