Re: GCC maintainer going AFK.
On Fri, Oct 31, 2008 at 11:50 AM, Dave Korn [EMAIL PROTECTED] wrote: I will try and stay attentive to the lists during this period; I am aware that I have a few outstanding emails to reply to, e.g. Marco A: I'm preparing a new release of gcc-4 with all DLLs for all the runtimes, and that will be available fairly soon, but I have a problem with typeinfo vs. libstdc++ DLL that I am currently working on a patch for ld before it can function correctly. Someone spent their SoC doing major MingW improvements on the compiler, including better handling of dwarf and pe weak symbols. It might be worthwhile to see what can be ported over to Cygwin. It sure would be nice to have pe weak symbols support in the cygwin loader...
Re: [RFC] 1.7 Packaging: Obsolete packages
Corinna Vinschen wrote: - Potentially case sensitivity file operations (on OSes and FSes supporting it). Have managed mounts been fixed yet? Sorry, I've been out of the loop for quite awhile. Anyway, I noticed that Yakkov was using this feature in Cygwin Ports, so I thought I might inquire, since I'm curious as well. ;-) Cheers, Nicholas
Re: mktemp and util-linux vs. new coreutils
On Jan 24, 2008 9:10 PM, Yaakov (Cygwin Ports) [EMAIL PROTECTED] wrote: Moving arch to coreutils makes sense to me, but let me look at util-linux 2.13 before I commit to anything. While you are at it, if/when you do another release of util-linux, please update the cygport to install more.exe in /usr/bin, rather than /bin (util-linux arch.exe is also doing this, too). It's superficial, but it's probably a good idea for consistency's sake, since /usr/bin == /bin. Cheers, Nicholas
Re: mktemp and util-linux vs. new coreutils
On Jan 27, 2008 9:17 AM, Christopher Faylor [EMAIL PROTECTED] wrote: On Sun, Jan 27, 2008 at 07:25:23AM -0500, Nicholas Wourms wrote: On Jan 24, 2008 9:10 PM, Yaakov (Cygwin Ports) [EMAIL PROTECTED] wrote: Moving arch to coreutils makes sense to me, but let me look at util-linux 2.13 before I commit to anything. While you are at it, if/when you do another release of util-linux, please update the cygport to install more.exe in /usr/bin, rather than /bin (util-linux arch.exe is also doing this, too). It's superficial, but it's probably a good idea for consistency's sake, since /usr/bin == /bin. Uh, no. This doesn't matter at all. There is no reason to bother with this. Actually, it does matter. The cygcheck utility believes there is a difference. For example, if I were to install the latest testing version of coreutils, I would have no way of knowing that it just clobbered arch.exe based on the information given by cygcheck. What if Eric decides not to distribute it? Or I decide to revert back to the stable version? Well I just got left with an inconsistent system. Just like installation to /usr/man and /usr/info is discouraged, so should installation to /bin and /lib. As the number of packages grows, it is going to be tougher to catch this kind of thing. To persist with packaging inconsistancies is not logical, especially given the nature of our /bin and /lib. In any event, since he uses cygports, this is merely a simple one line fix to the cygport file. I should think it would be no bother at all, really, and better safe than sorry. If he doesn't want to do it, then fine. Cheers, Nicholas
Re: [1.7.0 HEAD]: Cygwin no longer encoding/decoding names on managed mounts
Corinna Vinschen wrote: On Jan 14 16:41, Nicholas Wourms wrote: Hi All, I'm not sure when this cropped up, but it happened sometime after the great win 9x code purge. The problem is that the Cygwin dll no longer decodes or encodes file/directory names on managed mounts. File handling in CVS HEAD is work in progress. It's not stable. Don't use it in a production environment. Corinna, I understand this and believe me it isn't a big deal. I just thought I would toss it out there. I plan on giving gdb a whirl and see if I can't track it down when I get a few hours to kill. Cheers, Nicholas -- 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/
[1.7.0 HEAD]: Cygwin no longer encoding/decoding names on managed mounts
Hi All, I'm not sure when this cropped up, but it happened sometime after the great win 9x code purge. The problem is that the Cygwin dll no longer decodes or encodes file/directory names on managed mounts. Steps to reproduce (WinXP SP2 x32): --- 1) mkdir -p /usr/src2 2) mount -b -s -o managed C:\\cygwin\\usr\\src2 /usr/src2 3) cd /usr/src2 4) mkdir -p FOO 5) ls -1 /cygdrive/c/cygwin/usr/src2 1.5.25(0.156/4/2) results: -- Expected: %46%4F%4F Actual: %46%4F%4F 1.7.0(0.179/4/2) results: - Expected: %46%4F%4F Actual: FOO For this test, I setup a fresh, default Cygwin install on another machine. The Cygwin dll which was used was from the 1.5.25-7 package. I ran the test and everything worked as expected. However, on the machine with the Cygwin dll compiled from cvs HEAD, it did not. Running strace on the mkdir -p FOO operation seems to confirm that the munging gets skipped somewhere in the normalize_posix_path function. strace snippet from 1.5.25(0.156/4/2): -- [main] mkdir dll_crt0_1: user_data-main 0x4012A0 [main] mkdir __set_errno: void dll_crt0_1(void*):946 val 0 [main] mkdir normalize_posix_path: src FOO [main] mkdir cwdstuff::get: posix /usr/src2 [main] mkdir cwdstuff::get: (/usr/src2) = cwdstuff::get (0x22C740, 260, 1, 0), errno 0 [main] mkdir normalize_posix_path: /usr/src2/FOO = normalize_posix_path (FOO) [main] mkdir mount_info::conv_to_win32_path: conv_to_win32_path (/usr/src2/FOO) [main] mkdir set_flags: flags: binary (0x2) [main] mkdir mount_info::conv_to_win32_path: src_path /usr/src2/FOO, dst C:\Cygnus\cygwin\usr\src2\%46%4F%4F, flags 0x80A, rc 0 __^ [main] mkdir symlink_info::check: GetFileAttributes (C:\Cygnus\cygwin\usr\src2\%46%4F%4F) failed [main] mkdir geterrno_from_win_error: windows error 2 == errno 2 [main] mkdir symlink_info::check: GetFileAttributes (C:\Cygnus\cygwin\usr\src2\%46%4F%4F.lnk) failed [main] mkdir geterrno_from_win_error: windows error 2 == errno 2 [main] mkdir symlink_info::check: 0 = symlink.check (C:\Cygnus\cygwin\usr\src2\%46%4F%4F, 0x22C400) (0x80A) [main] mkdir mount_info::conv_to_win32_path: conv_to_win32_path (/usr/src2) [main] mkdir set_flags: flags: binary (0x2) [main] mkdir mount_info::conv_to_win32_path: src_path /usr/src2, dst C:\Cygnus\cygwin\usr\src2, flags 0x80A, rc 0 [main] mkdir symlink_info::check: not a symlink [main] mkdir symlink_info::check: 0 = symlink.check (C:\Cygnus\cygwin\usr\src2, 0x22C400) (0x80A) [main] mkdir path_conv::check: this-path(C:\Cygnus\cygwin\usr\src2\%46%4F%4F), has_acls(1) [main] mkdir build_fh_pc: fh 0x61169E30 [main] mkdir alloc_sd: uid 1010, gid 544, attribute 41FF [main] mkdir cygpsid::debug_print: alloc_sd: owner SID = S-1-5-21-1454471165-492894223-1957994488-1010 [main] mkdir cygpsid::debug_print: alloc_sd: group SID = S-1-5-32-544 [main] mkdir alloc_sd: ACL-Size: 148 [main] mkdir alloc_sd: Created SD-Size: 212 [main] mkdir mkdir: 0 = mkdir (FOO, 511) strace snippet from 1.7.0(0.179/4/2): - [main] mkdir dll_crt0_1: user_data-main 0x4012A0 [main] mkdir __set_errno: void dll_crt0_1(void*):931 val 0 [main] mkdir normalize_posix_path: src FOO [main] mkdir cwdstuff::get: posix /usr/src2 [main] mkdir cwdstuff::get: (/usr/src2) = cwdstuff::get (0x22C750, 260, 1, 0), errno 0 [main] mkdir normalize_posix_path: /usr/src2/FOO = normalize_posix_path (FOO) [main] mkdir mount_info::conv_to_win32_path: conv_to_win32_path (/usr/src2/FOO) [main] mkdir set_flags: flags: binary (0x2) [main] mkdir mount_info::conv_to_win32_path: src_path /usr/src2/FOO, dst C:\Cygnus\cygwin\usr\src2\FOO, flags 0x80A, rc 0 __^^^ [main] mkdir symlink_info::check: 0xC034 = NtQueryAttributesFile (\??\C:\Cygnus\cygwin\usr\src2\FOO) [main] mkdir geterrno_from_win_error: windows error 2 == errno 2 [main] mkdir symlink_info::check: 0xC034 = NtQueryAttributesFile (\??\C:\Cygnus\cygwin\usr\src2\FOO.lnk) [main] mkdir geterrno_from_win_error: windows error 2 == errno 2 [main] mkdir symlink_info::check: 0 = symlink.check (C:\Cygnus\cygwin\usr\src2\FOO, 0x224520) (0x80A) [main] mkdir mount_info::conv_to_win32_path: conv_to_win32_path (/usr/src2) [main] mkdir set_flags: flags: binary (0x2) [main] mkdir mount_info::conv_to_win32_path: src_path /usr/src2, dst C:\Cygnus\cygwin\usr\src2, flags 0x80A, rc 0 [main] mkdir symlink_info::check: not a symlink [main] mkdir symlink_info::check: 0 = symlink.check (C:\Cygnus\cygwin\usr\src2, 0x224520) (0x80A) [main] mkdir path_conv::check: this-path(C:\Cygnus\cygwin\usr\src2\FOO), has_acls(1) [main] mkdir build_fh_pc: fh 0x611E4C7C [main] mkdir alloc_sd: uid 500, gid 545, attribute 41FF [main] mkdir cygsid::debug_print: alloc_sd: owner SID = S-1-5-21-1292428093-813497703-1801674531-500 (+) [main] mkdir cygsid::debug_print: alloc_sd: group SID = S-1-5-32-545 (+) [main] mkdir alloc_sd: ACL-Size: 148 [main] mkdir
Re: Compiling XWin (modular Xorg)
On Dec 11, 2007 11:49 PM, Yaakov (Cygwin Ports) wrote: Janjaap Bos wrote: The changes I made are all in the patch. Let me know when you have suggestions, and whether you're able to build it. Perhaps Yaakov is willing to check it with his findings. Thank you VERY much. I will try to look into this into the near future, as the server is the only holdup in getting X11R7 finished on Cygwin. Hi all, Have you guys checked out the Xming patches (http://www.straightrunning.com/XmingCode/)? Most of them modify code that is the same as we use and contain many fixes to current problems we are experiencing, such as the 24bpp issue. Also, a lot of AG's fixes he did not commit to either trunk or the cygwin branch. He's also come up with a rather unsavory, yet workable hack to the overloaded function issue. There are a ton of DD improvements to the GLX acceleration code, too. Admittedly, the person who runs that project is still using monolithic as the base and has a rather bizarre way of updating the sources uses modular code, but still, it ought to be worthwhile to check out. Unfortunately, he keeps his latest changes behind a donation paywall, but I'm sure if asked by a well know cygwin-xorg developer, he would be willing to part with them. As for the overloaded function problem, I do recall we had this same issue back in 2002-2003 with shared libXt. You might want to search through the archives on that one for the whole story. It was a real frustrating problem to deal with, but a good solution was found that worked well. I had a thought on packaging. Perhaps we should adopt the Fedora scheme? I mean they seem to have packaged it nicely without having 60+ packages. We would still want our versioned packages for the runtime, but it should help to cut down on the number of packages without having binary compatibility problems. You could then use the current cygwin x11-xorg package names as collection stubs for the individual ones. Just a thought. Cheers, Nicholas -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Missing dll's in new package [was Re: Please upload: xorg-*-6.8.99.901]
On 10/28/05, Alan Hourihane wrote: This test version was built from the mainline X.Org trunk code and not the CYGWIN branch. I'll be working on getting whatever changes exist on that branch over into the mainline trunk code next. If the patches are still in CYGWIN then that's the problem. Thanks, Alan. It seems that DPS support is being phased out, so nevermind about that. However, I have noticed another issue which may (or may not) be solved on the branch. It seems that xcursorgen and the default cursor sets were not built and included this time around. Other then that, the new X seems to be working fine. On a side note, once the dust settles and if you have time to look into it, perhaps it would be possible to make static libraries available in addtion to the shared libraries? Just a thought. Cheers, Nicholas -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Missing dll's in new package [was Re: Please upload: xorg-*-6.8.99.901]
On 10/28/05, Alexander Gottwald wrote: On Thu, 2005-10-27 at 19:56 -0400, Nicholas Wourms wrote: I've taken the opportunity to evaluate the new package. Prior versions of Cygwin/Xorg provided the dlls and development files for the libDPS interface. For some reason, they were omitted in this release. I've been hunting through the Imake config files, and I cannot understand why they weren't built. Perhaps this is a problem in the packaging script? DPS has been obsoleted by xorg and is going to be removed from the xorg tree https://bugs.freedesktop.org/show_bug.cgi?id=3080 BTW, xcursorgen and the icon sets are missing in this release. And not to get into an ideological debate over this, but a package including static libs would be nice. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Missing dll's in new package [was Re: Please upload: xorg-*-6.8.99.901]
On 10/28/05, Nicholas Wourms wrote: On 10/28/05, Alexander Gottwald wrote: On Thu, 2005-10-27 at 19:56 -0400, Nicholas Wourms wrote: I've taken the opportunity to evaluate the new package. Prior versions of Cygwin/Xorg provided the dlls and development files for the libDPS interface. For some reason, they were omitted in this release. I've been hunting through the Imake config files, and I cannot understand why they weren't built. Perhaps this is a problem in the packaging script? DPS has been obsoleted by xorg and is going to be removed from the xorg tree https://bugs.freedesktop.org/show_bug.cgi?id=3080 BTW, xcursorgen and the icon sets are missing in this release. And not to get into an ideological debate over this, but a package including static libs would be nice. Ack. Ignore this one, it was supposed to be deleted. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Missing dll's in new package [was Re: Please upload: xorg-*-6.8.99.901]
On 10/27/05, Alan Hourihane wrote: Yep, uploading myself to sourceware now. They'll be in-place in the next hour. Alan, I've taken the opportunity to evaluate the new package. Prior versions of Cygwin/Xorg provided the dlls and development files for the libDPS interface. For some reason, they were omitted in this release. I've been hunting through the Imake config files, and I cannot understand why they weren't built. Perhaps this is a problem in the packaging script? Cheers, Nicholas -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 2nd summary (was Re: [HEADSUP] ALL Maintainers, please reply.)
On 10/2/05, Hack Kampbjorn wrote: [SNIP] keychain Hack Kampbjorn or up for grabs? ncftp Hack Kampbjorn or up for grabs? If Hack doesn't want these anymore, ditto on these. I would apreciate that. Ok, then I'll get to work on these. Cheers, Nicholas
Re: 3rd summary (was Re: [HEADSUP] ALL Maintainers, please reply.)
On 10/3/05, Corinna Vinschen wrote: [SNIP] clear Wasn't this moved to obsolete? Cheers, Nicholas
Re: 2nd summary (was Re: [HEADSUP] ALL Maintainers, please reply.)
Corinna, agetty Up for grabs (so far Sergey Okhapkin) chkconfig Up for grabs (so far Sergey Okhapkin) initscriptsUp for grabs (so far Sergey Okhapkin) sysvinit Up for grabs (so far Sergey Okhapkin) xinetd Up for grabs (so far Sergey Okhapkin) If Sergey doesn't want these, I've got some local packaged versions which are more recent. So I'll bite unless someone else really really wants them. Give me a week or so, and I'll see what I can cook up. keychain Hack Kampbjorn or up for grabs? ncftp Hack Kampbjorn or up for grabs? If Hack doesn't want these anymore, ditto on these. Cheers, Nicholas
Re: [ITP] gnome-libs-1.4.2
Yaakov, In a similar sense to my comments on qt3, I think it would be better to break up the package into something like: libname1(libtool dll version) - for each runtime lib package name - base package (docs, shared data, etc). name-devel - headers, static/import libs, .la/.pc files, dev docs. For example (not complete): libgnomesupport10 - /usr/bin/cyggnomesupport-0.dll libgnomeui132 - /usr/bin/cyggnomeui-32.dll gnome-libs --- /usr/bin/gnome-bug /usr/share/doc/gnome-libs-1.4.2/ABOUT-NLS /usr/share/doc/gnome-libs-1.4.2/AUTHORS /usr/share/doc/gnome-libs-1.4.2/ChangeLog /usr/share/doc/gnome-libs-1.4.2/COPYING /usr/share/doc/gnome-libs-1.4.2/COPYING.LIB /usr/share/doc/gnome-libs-1.4.2/HACKING /usr/share/doc/gnome-libs-1.4.2/INSTALL /usr/share/doc/gnome-libs-1.4.2/NEWS /usr/share/doc/gnome-libs-1.4.2/README /usr/share/locale/az/LC_MESSAGES/gnome-libs.mo /usr/share/locale/ca/LC_MESSAGES/gnome-libs.mo /usr/share/locale/cs/LC_MESSAGES/gnome-libs.mo /usr/share/locale/da/LC_MESSAGES/gnome-libs.mo /usr/share/locale/de/LC_MESSAGES/gnome-libs.mo /usr/share/locale/el/LC_MESSAGES/gnome-libs.mo /usr/share/locale/en_GB/LC_MESSAGES/gnome-libs.mo /usr/share/locale/es/LC_MESSAGES/gnome-libs.mo /usr/share/locale/et/LC_MESSAGES/gnome-libs.mo /usr/share/locale/eu/LC_MESSAGES/gnome-libs.mo /usr/share/locale/fi/LC_MESSAGES/gnome-libs.mo /usr/share/locale/fr/LC_MESSAGES/gnome-libs.mo /usr/share/locale/ga/LC_MESSAGES/gnome-libs.mo /usr/share/locale/gl/LC_MESSAGES/gnome-libs.mo /usr/share/locale/hr/LC_MESSAGES/gnome-libs.mo /usr/share/locale/hu/LC_MESSAGES/gnome-libs.mo /usr/share/locale/it/LC_MESSAGES/gnome-libs.mo /usr/share/locale/ja/LC_MESSAGES/gnome-libs.mo /usr/share/locale/ko/LC_MESSAGES/gnome-libs.mo /usr/share/man/man1/gnome.1.gz /usr/share/man/man1/gnome-bug.1.gz ... gnome-libs-devel - /usr/bin/gnome-config /usr/include/gnome-1.0/gnome.h /usr/include/gnome-1.0/popt-gnome.h /usr/lib/gnome-libs/include/gnomesupport.h /usr/lib/gnomeConf.sh /usr/lib/libgnomesupport.dll.a /usr/lib/libgnomesupport.la /usr/share/doc/gnome-libs-1.4.2/doc/README.gtkcauldron /usr/share/doc/gnome-libs-1.4.2/doc/README.gtkcauldron_for_python /usr/share/doc/gnome-libs-1.4.2/doc/adding-file-manager-new-items.txt /usr/share/doc/gnome-libs-1.4.2/doc/adding-sounds.txt /usr/share/doc/gnome-libs-1.4.2/doc/api-comment-style.txt /usr/share/doc/gnome-libs-1.4.2/doc/gnome-doc /usr/share/doc/gnome-libs-1.4.2/doc/gnome-doc.el /usr/share/doc/gnome-libs-1.4.2/doc/mime-type-handling.txt /usr/share/doc/gnome-libs-1.4.2/doc/mkstub /usr/share/doc/gnome-libs-1.4.2/doc/session-management.txt /usr/share/doc/gnome-libs-1.4.2/doc/suggestions.txt /usr/share/gnome/help/gnome-dev-info/C/addauth.html /usr/share/gnome/help/gnome-dev-info/C/altpol.html /usr/share/gnome/help/gnome-dev-info/C/arch.html /usr/share/gnome/help/gnome-dev-info/C/book1.html /usr/share/gnome/help/gnome-dev-info/C/codstd.html /usr/share/man/man1/gnome-config.1.gz /usr/share/man/man1/gnome-doc.1.gz /usr/share/man/man1/gnome-mkstub.1.gz ... Cheers, Nicholas
Re: lesstif packaging
On 9/27/05, Brian Ford wrote: On Mon, 26 Sep 2005, Nicholas Wourms wrote: Nicholas, You have been around here long enough to know that personal email is not the way to address these issues. As such, I have forwarded this reply to the proper mailing list and set the Reply To appropriately. Please honor this. The lack of doing so makes it less likely that your request will be addressed. Thanks. Yeah, yeah, yeah... I'm lazy, so sue me... ;-) Please go back to bzipping the manpages like they have been in previous packages. I see now that this was the case. However, the source package that Harold gave me to start with did not do this, nor does the current version of the gbs. As such, I'd prefer not to support a local gbs patch just to change its default behavior. If, however, there is consensus that this is the way it should be (TM), I'd be happy to submit a gbs patch. I don't know anyone who uses the gbs without tweaking it for a specific package, which you've already done for lesstif. Also, please don't just arbitrarily drop the static libs. Why? None of the dependent xorg X libs are available staticly. How does having a static lesstif help anyone? If you can present a reasonable argument for keeping them I will consider it, but no for an unfounded request. Sorry. First, I do not know if it is still the case, but in the past, *some* motif applications had problems when linked to the dynamic library. In fact this issue caused a lot of headaches when lesstif was first introduced, but eventually it was fixed for most applications. A search of the archive ought to show the relevant discussion. While I agree that the lack of static Xorg libs is less than desirable, it is has been a general courtesy to provide both static and dynamic libs to the developer. One reason might be that an app uses only a few portions of lesstif libs, but the dev doesn't want to require the user to install the entire lesstif package. In any event, I'll withdraw that particular request until such time as static Xorg libs become available. I'm not sure what the status is, but I contacted Alexander awhile back regarding Xorg static libs and IIRC he told me he was going to look into it when he gets a chance. If he's too busy still, I've been playing around with Xorg's build and can probably get it working sooner or later. Right now I'm working on more interesting things (like shared gcc/g++/gcj/g77 libs). Cheers, Nicholas
Re: libungif (was: Re: 2nd summary (was Re: [HEADSUP] ALL Maintainers, please reply.))
On Wed, 28 Sep 2005 15:06:31 -0500, in gmane.os.cygwin.applications you wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lapo Luchini wrote: I'd say up for grabs. I always used to say it's low priority, but being so low it didn't get updated in months probably means that someone else may well be more interested in it... I'm interested in keeping this going. But before I package it, was a decision ever made about including giflib in the net release (in terms of legalities)? This will make a big difference in how I would package libungif. We already had this discussion awhile back, and despite the FUD from the FSF, the patent has long since expired worldwide. The only company which might have a claim is IBM (which expires at the end of this year), do you really think they'd care (given their recnt battle with SCO)? Most other opensource packages with LZW capabilities have already quitely re-integrated it back into the default source. Cheers, Nicholas
Re: Packages with unusual (wrong?) tarball names (db, xemacs)
On Tue, 27 Sep 2005 14:52:18 +0100, in gmane.os.cygwin.applications you wrote: The (adhoc?) standard for package file names, which for the most part is followed, is: NAME-VERSION-RELEASE.tar.bz2 -- for binary packages NAME-VERSION-RELEASE-src.tar.bz2-- for source packages VERSION and RELEASE should not contain '-' characters. NAME is allowed to contain '-' characters, but NAME should not contain a '-' character immediately followed by a digit, because this would look too much like the start of VERSION. There are a few packages in the distribution which do not follow these rules: !!! ./db/db2 db-2.7.7-4-src.tar.bz2 !!! ./db/db2 db-2.7.7-4.tar.bz2 !!! ./db/db3.1 db-3.1.17-2-src.tar.bz2 !!! ./db/db3.1 db-3.1.17-2.tar.bz2 !!! ./db/db4.1 db-4.1.25-1-src.tar.bz2 !!! ./db/db4.1 db-4.1.25-1.tar.bz2 !!! ./db/db4.2 db-4.2.52-1-src.tar.bz2 !!! ./db/db4.2 db-4.2.52-1.tar.bz2 !!! ./db/db4.3 db-4.3.28-1-src.tar.bz2 !!! ./db/db4.3 db-4.3.28-1.tar.bz2 ^^^ These packages do not reflect their package name in their file name. Max, I only used that scheme because it was the one Chuck had used in his non-official db packages. At the time I saw no reason to change them, and I think it might be best to leave them as-is for now. Cheers, Nicholas
Re: 2nd summary (was Re: [HEADSUP] ALL Maintainers, please reply.)
On Mon, 26 Sep 2005 13:06:58 +0200, in gmane.os.cygwin.applications you wrote: On Sep 15 18:45, Corinna Vinschen wrote: Mails in the last couple of weeks indicate that we have lost one or the other maintainer without getting any notice from them. Since we have a couple of packages which haven't been updated for a good amount of time, there's apparently a need to find out, which packages are still maintained and which have lost their maintainer on the way. So, ALL maintainers of Cygwin packages, please reply to this mail within the next six weeks, including a list of ALL packages you maintain. This survey will run until 2005-10-31. I will ping every week, so you have a bit of time. However, if you don't reply until 2005-10-31, your packages will be up for grabs. Which means, they will disappear from the Cygwin net distribution if nobody wants to take over maintainership. Below are the results as of today 2005-09-26. It would be helpful if all maintainers could scan this lists again, so that we're sure that nothing has been left out accidentally and to clear up some questions. Later changes due to dropping or switching maintainership should be explicitely mentioned at one point, please. db2Gerrit P. Haase db3.1 Gerrit P. Haase db4.1 Gerrit P. Haase db4.2 Gerrit P. Haase db4.3 Gerrit P. Haase libdb2 Gerrit P. Haase libdb2-devel Gerrit P. Haase libdb3.1 Gerrit P. Haase libdb3.1-devel Gerrit P. Haase libdb4.1 Gerrit P. Haase libdb4.1-devel Gerrit P. Haase libdb4.2 Gerrit P. Haase libdb4.2-devel Gerrit P. Haase libdb4.3 Gerrit P. Haase libdb4.3-devel Gerrit P. Haase I'm a co-maintainer of these, FWIW. libpopt0 Christopher Faylor popt Christopher Faylor Actually, that's my package BTW, the rxvt maintainer is *NOT* subscribed to this list (he is to the main list). I'm sure we don't want to loose that package, so you might want to ping him here: [EMAIL PROTECTED] Cheers, Nicholas
Re: [ITP] qt3-3.3.4
On Fri, 02 Sep 2005 13:52:30 -0500, in gmane.os.cygwin.applications
you wrote:
[SNIP]
Yaakov,
First, thank you for packaging this. I was supposed to do it 2 years
ago but I never got around to it. First, libtool actually names
plugins the way you did, so no need to worry there.
I have some suggestions about the packaging:
1)
The manpages are screwed up. The issue, as you know, is that there
are a number of manpages which have the same name/different case. For
each pair that does so:
- All of the all-lowercase manpages contain actual manpage content.
- All of the mixed-case manpages contain a groff .so link to the
corresponding all-lowercase version.
So, for example, you have:
- qaccessibleobject.3qt
- QAccessibleObject.3qt
The qaccessibleobject.3qt contains the actual content and the
QAccessibleObject.3qt contains just '.so man3/qaccessibleobject.3qt'.
The first thing you need to do is make sure that the lowercase
manpages aren't clobbered by the mixed-case ones when the package is
untarred. Fortunately, newer cygwin dlls contain an undocumented
feature which allows you to mount a directory where files can exist
with the same name/different case. This is called a 'managed' mount.
One source package, gcc, is actually using managed mounts as part of
the build (since gcj has case issues). Anyhow, you would change
unpack() in the generic build script like so:
unpack() {
winbase=`cygpath -m ${srcdir}`
mkdir -p ${srcdir}
mount -u -omanaged ${winbase} ${srcdir}
tar xv${opt_decomp}f $1
}
and modify finish() like so:
finish() {
rm -rf ${srcdir}
umount -u ${srcdir}
}
Ok, so that stops the clobbering, now you have three options on how to
deal with the actual packaging of the manpages.
1) `cd doc/man rm -f Q*`
2) Put man1 and the all-lowercase man3 in:
/usr/share/qt3/doc/man/man{1,3}
Then put the mixed-case man3 in:
/usr/share/qt3/doc/mann/man3
Update MANPATH scripts to reflect this.
3) Make /usr/share/qt3/doc/man a managed mount.
Unfortunately, #3 is out of the question since setup.exe does not
(yet) support the creation of managed mounts. Nor can packages direct
it to do so (though I suppose if it supported pre-install scripts,
maybe it could). However, when, and if it does, I would definitely go
with this method.
Option #1 is the easiest, but you might cause problems in
cross-references that want mixed-case pages (for programs which
interpret troff cross-references).
Option #2, given the current state of cygwin and setup.exe, is
probably your best bet. Given that you already modify the MANPATH,
this should not be that hard to integrate into the packaging.
---
2)
The versioned dll's should go into a different package. In theory,
that should allow a person to just install only them, with no other
items. So, for example, I would put them in a package using the
following template:
libqt{major}{minor}{dll version}
So, for example, it would be:
libqt340-3.4-1
And you would bump the dll version whenever an incompatible change was
introduced. I think it is critical to plan ahead for possible
incompatible changes in the API which windows is hypersensitive to,
especially with c++ libraries.
So, for example, maybe libqt340-1 should contain:
/usr/bin/cygqt34-mt-0.dll
/usr/bin/cygqui34-0.dll
3)
Now that versioned dlls are out of the main package, you should
probably merge the -bin package into the base to cutdown on the number
of packages.
So, for example, the base package qt3-3.4-1, might contain:
/usr/bin/designer-qt3
/usr/bin/linguist-qt3
/usr/bin/qtconfig-qt3
/usr/lib/qt3/bin/designer.exe
/usr/lib/qt3/bin/findtr
/usr/lib/qt3/bin/linguist.exe
/usr/lib/qt3/bin/lrelease.exe
/usr/lib/qt3/bin/lupdate.exe
/usr/lib/qt3/bin/qm2ts.exe
/usr/lib/qt3/bin/qt20fix
/usr/lib/qt3/bin/qtconfig.exe
/usr/lib/qt3/bin/qtrename140
/usr/lib/qt3/plugins/designer/libcppeditor.dll
/usr/lib/qt3/plugins/designer/libdlgplugin.dll
/usr/lib/qt3/plugins/designer/libgladeplugin.dll
/usr/lib/qt3/plugins/designer/libkdevdlgplugin.dll
/usr/lib/qt3/plugins/designer/librcplugin.dll
/usr/lib/qt3/plugins/designer/libwizards.dll
/usr/lib/qt3/plugins/imageformats/libqjpeg.dll
/usr/lib/qt3/plugins/imageformats/libqmng.dll
/usr/lib/qt3/plugins/imageformats/libqpng.dll
/usr/lib/qt3/plugins/sqldrivers/libqsqlite.dll
/usr/lib/qt3/plugins/sqldrivers/libqsqlpsql.dll
/usr/share/applications/designer-qt3.desktop
/usr/share/applications/linguist-qt3.desktop
/usr/share/applications/qtconfig-qt3.desktop
/usr/share/doc/Cygwin/qt3-3.3.4.README
/usr/share/doc/qt3-3.3.4/FAQ
/usr/share/doc/qt3-3.3.4/INSTALL
/usr/share/doc/qt3-3.3.4/LICENSE.GPL
/usr/share/doc/qt3-3.3.4/LICENSE.QPL
/usr/share/doc/qt3-3.3.4/PLATFORMS
/usr/share/doc/qt3-3.3.4/README
/usr/share/doc/qt3-3.3.4/README-QT.TXT
/usr/share/doc/qt3-3.3.4/changes-3.3.4
/usr/share/pixmaps/designer-qt3.png
/usr/share/pixmaps/linguist-qt3.png
/usr/share/pixmaps/qtconfig-qt3.png
Re: 2nd summary (was Re: [HEADSUP] ALL Maintainers, please reply.)
On Wed, 28 Sep 2005 20:38:01 -0400, in gmane.os.cygwin.applications you wrote: On Wed, Sep 28, 2005 at 08:20:35PM -0400, Nicholas Wourms wrote: libpopt0 Christopher Faylor popt Christopher Faylor Actually, that's my package I just took these because I thought they were related to rpm and I'm taking on rpm. So, sorry for the confusion. Oh well, if you think it will be easier, taking it over is fine by me. If you want, I'll take any package you're tired of maintaining. Out of curiousity, any plans beyond just packaging rpm? A project that I had been working on, but never got around to investing much time or effort in, was adapting setup.exe to support rpms. Cheers, Nicholas
Re: [PATCH] setup: fix FTP behavior on timeout
On Tue, 27 Sep 2005 18:44:31 +0200, in gmane.os.cygwin.applications you wrote: On Sep 27 12:05, Igor Pechtchanski wrote: Hi, I noticed this problem when trying to do a fresh install -- if selecting packages takes too long, ftp mirrors will timeout, and setup will not reconnect, causing the failure. This patch fixes that. Finally! AMEN!!!
[PATCH]: Add get{delim,line} symbol alias to avoid autoconf detection failures
Hi Corinna,
I saw that you exported __get{delim,line} in the cygwin dll. I've had
this modification locally for awhile now. There are a number of
autoconfiscated applications which check for these functions and use
them if present. Unfortunately, autoconf's AC_CHECK_FUNCS will not
pickup CPP definitions in headers because the test links to the c
library using a phony prototype. Thus, in order to facilitate
autoconf, I've added the necessary resource aliases. I've also taken
the liberty of replacing the CPP definitions with actual function
prototypes for improved clarity. The patch for doing these
operations is attached. I hope you find it satisfactory.
Cheers,
Nicholas
2005-07-09 Nicholas Wourms [EMAIL PROTECTED]
* cygwin.din (getline): Add symbol alias to avoid problems with
autoconf's AC_CHECK_FUNCS macro.
(getdelim): Likewise.
* include/sys/stdio.h (getline): Improve clarity by replacing the cpp
definition with a proper function prototype.
(getdelim): Likewise.
* include/cygwin/version.h: Bump API minor number.
getdelim-getline-autoconf-fix.patch
Description: Binary data
Re: [PATCH]: decorate gcc extensions with __extension__
Christopher Faylor wrote: On Tue, Mar 29, 2005 at 01:52:32PM -0500, Nicholas Wourms wrote: You have correctly surmised that both Corinna and I understand what pedantic mode is. You have to take that thought a step further, however, and realize that the fact that there is no -pedantic in CFLAGS is because we both want to use the full expressive power of gcc without worrying if we are complying with ISO C or ISO C++. This is a conscious choice, not an oversight. I understand that, not many projects do compile at -pedantic by default. However, you are assuming I am asking you to change huge amounts of code to conform to ISO standards, which is not what I'm saying. While I did make some suggestions regarding variable sized arrays, that was about the limit of the iso-correctness on my part. I am not suggesting, in any way, that -pedantic be added to the default CFLAGS. And any other changes are going to be trivial, like nixing a trailing comma in the last member of an enum. I thought Corinna's intent was clear in that sentence. Apparently you didn't. What she was saying is, for this to be done right, both of us would have to be rigorous in the future about making sure that we add decorate every extension we use, or, worse, avoid using gcc extensions which we've come to rely on. That would be annoying. I hear you loud and clear. I am not suggesting you stop using gcc extensions, nor would I. It is true that I made a minor off-the-cuff suggestion regarding variable sized arrays, but it was intended to be an opinion. As for the done right part, I would point to the other __attribute__ tags which are used to explicitly mark intentions to the compiler (e.g. unused noreturn). Looking at the ChangeLog, many of these were added long after the offending initial code was added, mostly likely during a code cleanliness sweep. Of course there is no *requirement* for the tags, as code will compile just fine without them. The point, however, of using them is to separate the true-positive warnings from the false-positive warnings. My intention is no different. So why should adding __extension__ be any different? Just add when it is noticed/needed, like the other __attribute__ tags are. However, if I am correctly interpreting your intent, it sounds like you are saying that no one but you would have to worry about sprinkling __extension__'s throughout the code and that we could just write code as we always do. Again, I'm not suggesting I be the point man on this. Like other __attribute__ tags, they can be added as needed/noticed. It's rather trivial and I don't see the implied expenditure of labor involved. You can add them or not, it won't change the way the code is compiled. Just think of it like Rusty's Janitorial patches on LKML. If that is the case, then I don't see how it matters if we check in your code or not. You'll constantly be updating things to match the latest checkins one way or the other. Constantly? I'm afraid I would disagree. As was stated before, my changes touch a very small portion of code. While Cygwin development is lively, it doesn't come close to most other projects out there. Frankly, I find the pace here rather laid-back, which is quite fine IMHO. However, if your patches are not going to be checked in, Well, I had hoped to further discuss this... then you don't have to worry about packaging up your changes for cygwin-patches, which is less work for you. I know that, I'm not sending patches that I don't want committed. Btw, the use of a ?: c is a conscious decision. Maybe I'm just old fashion and do not like a ? : c, but I don't understand why you use it, other than saving a few keystrokes. Look, aside from the fact it keeps -pedantic from producing an error, explicitly expanding to a ? a : c makes the code easier to read and the intent more clear. Just like you could write: if (a) b; else c; but... if (a) b; else c; is more readable. Wouldn't you agree? I'm not trying to tell you what to do, I just think it would be better IMHO. Look, I understand that you and Corinna see my changes as making extra work for you. That isn't my intention and I've tried very hard to make my footprint minimal. Cheers, Nicholas
Cygwin (current): Bug in how managed mounts handle reserved words
(Note: I have not re-subscribed to the list yet and probably won't for another week or so, so please CC me in any replies - TIA) Hi, I've discovered a small bug in how Cygwin (CVS HEAD as of Saturday) handles reserved dos names created on managed mounts. I discovered this while working with a FreeBSD cross-compiler (actually CVS discovered it). Rather then bore you with my hypothesis, so here's the details: OS: Windows XP SP2 FS: NTFS UNAME: CYGWIN_NT-5.1 foobar 1.5.14(0.122/4/2) 2005-03-02 22:46 i686 unknown unknown Cygwin $CYGWIN: export check_case:strict tty ntea ntsec smbntsec server checkcodepage:oem NOTE: All cygwin packages are up to date. Steps to reproduce: --- 1) mkdir -p /usr/src/test 2) mount -o managed C:\\path to root\\usr\\src\\test /usr/src/test 3) cd /usr/src/test 4) mkdir -p cygwin-src/freebsd-src/sys/dev/digi 5) cd cygwin-src/freebsd-src/sys/dev/digi 6) touch .new.con.CX-IBM.h 7) mv .new.con.CX-IBM.h con.CX-IBM.h The error it gives me is: mv: cannot move `.new.con.CX-IBM.h' to `con.CX-IBM.h': Filename exists with different case So, I did a strace on the experimental testcase I mentioned above. In addition, I setup a control (known working) testcase which used the steps outlined above, except using the filenames .test.me.now and me.now instead. I've attached the differences between the strace outputs of my experiment and control (minus any extraneous differences). I haven't looked at it in depth, so unfortunately I don't have a fix. However, based on a cursory look, it would seem the problem is somewhere in path_conv (either posix or win). Cheers, Nicholas __ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp __ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp __ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp __ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp --- /home/Administrator/experimental-testcase.strace2005-03-06 13:08:46.057875000 -0500 +++ /home/Administrator/control-testcase.strace 2005-03-06 12:50:10.089125000 -0500 @@ -1,3 +1,3 @@ [main] mv set_myself: myself-dwProcessId 11776 -[main] mv time: 1110130976 = time (0) +[main] mv time: 1110131029 = time (0) [main] mv set_process_privilege: 0 = set_process_privilege (SeChangeNotifyPrivilege, 0) @@ -213,4 +213,2 @@ [main] mv sigproc_init: process/signal handling enabled(1001) -[sig] mv wait_sig: myself-dwProcessId 11776 -[sig] mv wait_sig: entering ReadFile loop, readsig 0x708, myself-sendsig 0x700 [main] mv tty_list::allocate_tty: console 0x1200550 associated with tty0 @@ -219,3 +217,3 @@ [main] mv build_fh_pc: fh 0x617D46E8 -[main] mv open_shared: name (null), shared 0xA02 (wanted 0xA02), h 0x6F4 +[main] mv open_shared: name (null), shared 0xA02 (wanted 0xA02), h 0x708 [main] mv add_handle: protecting handle 'cygheap-console_h', inherited flag 1 @@ -226,2 +224,4 @@ [main] mv fhandler_base::set_flags: filemode set to binary +[sig] mv wait_sig: myself-dwProcessId 11776 +[sig] mv wait_sig: entering ReadFile loop, readsig 0x6E0, myself-sendsig 0x6DC [main] mv fhandler_console::open: incremented open_fhs, now 1 @@ -231,3 +231,3 @@ [main] mv fhandler_console::output_tcsetattr: 0 = tcsetattr (,22E530) (ENABLE FLAGS 3) (lflag 0 oflag 0) -[main] mv tty::make_pipes: tty0 from_slave 0x6D0, to_slave 0x6D4 +[main] mv tty::make_pipes: tty0 from_slave 0x6CC, to_slave 0x6D0 [main] mv tty::get_event: created event Global\cygwin1S4-2005-03-02 22:46.cygtty.output.done.0 @@ -238,6 +238,6 @@ [main] mv fhandler_console::ioctl: WINSZ: (row=25,col=80) -[main] mv tty::create_inuse: Global\cygwin1S4-2005-03-02
Gnome versioning issues [was Re: [ITP] glib-2.4.2-1]
yselkowitz wrote: Gerrit P. Haase wrote: | http://anfaenger.de/cygwin/gtk+/glib/glib_devel-2.4.2-1.tar.bz2 ~ ^ | http://anfaenger.de/cygwin/gtk+/glib/glib_doc-2.4.2-1.tar.bz2 ~ ^ Shouldn't these be glib-devel and glib-doc with a hyphen, not an underscore? Another question (or RFC): glib-1.2 and glib-2.x were made to be able to coexist, and calling this glib (rather than glib2) may collide with a (perhaps private) package of glib-1.2. CyGnome2 has called this package glib2 for that reason, and some programs still use glib/gtk+-1.2 (dillo, gnucash, and more). How do the linux distros deal with this? I completely agree! Both Debian and RedHat use some form of versioning to distinguish between the major releases. This is a prudent model since both libs are still being used. I think using RedHat's naming conventions for the gnome packages ought to be a general rule of thumb. So, using the RedHat model for glib: glib-1.x - glib-version glib-2.x - glib2-version Likewise, for gtk+: gtk+-1.x - gtk+-version gtk+-2.x - gtk+2-version I'd like to suggest that the names of library-only packages, like glib/gtk+, be prepended with a lib, so that they show up in that portion of the full list and minimize confusion. This would compliment the current schema of packages like popt and iconv, which were prefixed with lib for that reason. I would further suggest appending [0-9] to the name so as to prepare for any binary incompatibilities which might arise. So my final suggestion would be like so: libglib20 libglib20-doc libglib20-devel Cheers, Nicholas
Re: [ITP] apr, apr-util
max wrote: APR is the Apache Portable Runtime. APR-util is an addon package to APR containing non-core useful features. Both are required by Subversion. I have prototype packages installed on my machine right now. I'll make apr, then apr-util, sequentially available for review once my previous ITP (neon) has finished the review process. Meanwhile, I'm posting this ITP to solicit votes. Max, You are treading on another maintainer's domain, as the apr runtime is part of Apache2. Regardless of whether you agree or disagree with Stipe's handling of apache, he's still the maintainer. The last time I heard, Stipe was still fixing serious bugs with the Apache2 server, which I guess is why it isn't working yet on Cygwin. Since you can just as easily build subversion with a static apr, I don't see any need for this additional packaging. Cheers, Nicholas
Re: Berkeley DB 4.2
Gerrit wrote: Nicholas schrieb: [EMAIL PROTECTED] wrote: Do the current Cygwin berkeley DB maintainers have any plans to package BDB 4.2? sure... I'm nearly finished with the build, will try to test it tomorrow and upload it after finishing the tests. So it is already released? Excellent, thanks for doing that [I'm currently in the middle of a data-recovery nightmare and have no idea when I'll get some time :-(]. Cheers, Nicholas
Re: Berkeley DB 4.2
[EMAIL PROTECTED] wrote: Do the current Cygwin berkeley DB maintainers have any plans to package BDB 4.2? sure...
Re: ttmkfdir no longer needed
Harold L Hunt II wrote: It looks like we no longer need ttmkfdir in order to expose the fonts installed with Windows to X11. The mkfontscale utility that is included with out distribution was inspired by ttmkfdir and essentially replaces it: That's not what it says, at least it makes no claim to be a full replacement. It mentions only that it is inspired from the original ttmkfdir, but I don't think it in the same class as the latest version (ttmkfdir-3.x) from RedHat. In fact, RedHat still retains and uses it to this day, even in the bleeding-edge Fedora's (which, BTW, are also using xorg-x11 for X11). IIRC, Mike Harris says in specfile that while mkfontscale is adequate for latin font encodings, it doesn't work all that well with unicode and other complex encodings. Since I speak English, I can't confirm nor deny if this is true, but if Mike is still using it for RedHat's TTF's, then I'd have to say there is some truth to it. You can do something like the following right now (well, not with Cygwin 1.5.9 since mkfontscale will core dump, you have to use snapshot of cygwin1.dll for the moment): 1) mkfontscale /cygdrive/c/WINDOWS/Fonts 2) mkfontdir /cygdrive/c/WINDOWS/Fonts 3) Launch Cygwin/X 4) In a bash shell under Cygwin/X, run: xset fp+ /cygdrive/c/WINDOWS/Fonts 5) Run xfontsel and observe that picking 'microsoft' from the 'rgstry' category exposes 'microsoft sans serif', 'tahoma', and 'verdana' among others under the 'fmly' category. Note also that valid chartacters appear when you select these fonts. Due to this I am going to pull the link to ttmkfdir from our 'Ported Software' page. Perhaps someone would like to write a postinstall script that creates symlinks to the Fonts folder for Windows under /usr/X11R6/lib/X11/fonts/windows, then runs mkfontscale and mkfontdir in that folder (since we can not guarantee that we have permissions to create files in the actual Fonts folder for Windows). Then it would take a minor adjustment of our startup scripts to pass this additional font folder to Cygwin/X on startup. Any takers? I'll package it if somebody works the kinks out of it. I would *strongly* advise against any action which would work directly in and/or on a user's system's FONTS dir. The first reason is that we can't guarantee the integrity of that link, since it could be broken due to some changes in CYGWIN case flags or inconsistencies in the case interpretation within the cygwin1.dll. Speaking from experience, this has bitten me once before. Secondly, the various utilities you want to use are required to open and read a significant portion of the font data from the font file. Why should this be of concern? Well if our font programs core dump while doing this, there is a possibility of corruption. There's even the possibility of corruption even if the program works as expected. Font corruption isn't always easy to detect, and often will lead people to make false assumptions about why they are getting unexpected or strange output from their fonts. We really don't want to get into the business of messing around with or in end-users' system directories. A better approach would be to copy the fonts to a predetermined Cygwin directory and work on them there. Perhaps a C program, mkttwin32dir, which does as follows (this is very simplistic): 1) Check for the existence of /usr/X11R6/lib/X11/fonts/win32: If yes, then hash the contents of that directory matching *.ttf into a sorted array, a[]. If no, then create the directory. 2) Check for the existence of the System font dir. If yes, goto next step. If no, abort and leave a textfile, README.fail, which contains some info on the reason it failed and to suggest user manually run the contents of the script. 3) Hash the contents of the system font directory for all matching *.ttf into a sorted array, b[]. Iterate the array, b[], converting strings to all-lowercase. Put each resulting string into the corresponding second column of b[], which will be the target's name. If we found a /usr/X11R6/lib/X11/fonts/win32 dir, then compare the contents of the first array, a[], with the contents of the target column of the second array, b[]. Discard from b[] any entries in which a font is in the target dir but not in the system dir. Also, discard any entries which have a match both in the system and the target dir. What is left will be the names fonts of needing copying and their case-converted target names. Obviously, if a[] is empty, then all matches should be copied. 4) For all contents of b[], spawn cp and binary copy the source to the target. Exit with a success return code. Then we could use this program during postinstall to do the necessary work of keeping a user's /usr/X11R6/lib/X11/fonts/win32 dir up to date. Furthermore, a user could set up a monthly cron job to do this automatically, so that the dirs are kept in sync. This program could also be extended
Re: Do I need XFree86 now that XOrg-x11 is the default X-windowing system? (fwd)
pechtcha wrote: Harold, I really hate to say this, but I told you so... :-D Yeah, this name change business is a bit of a pain. I hope that this whole X11 feud gets resolved eventually, so people can get back to harmony and cooperation rather then wasting energy and resources on maintaining separate forks. Then again, they aren't our packages, so who are we to say? Cheers, Nicholas
Re: ITP: leafnode
alper wrote: On Fri, Apr 02, 2004 at 04:17:16PM +0200, Corinna Vinschen wrote: 1. Leafnode relies on hard-link counts, so current implementation of hlinks on FAT32 breaks it. News spool has to be on NTFS, and it seems this will be an NT/2K/XP only package. Is that necessary? Can't that be ifdef'd for Cygwin? I've discussed this before with leafnode maintainer, Matthias Andree, and here's what he says: quote The whole /var/spool/news/* organization relies on hard links. The expire process relies on the hard link count (st_nlink in struct stat, as in the sys/stat.h header file and returned by the stat() syscall) being correct, file copies on FAT32 will lead to premature expiry and a horrible waste of disk space, it may become unbearable for cross-posted articles. /quote To diverge, and I know Corinna will tell me to submit a patch, but I think the problem this raises is worth discussing. Even if we are using NT/2k/XP/2k3, we still could be using fat32 filesystem. So, another approach to fix this problem would be to extend the managed mount api. That is, put Cygwin in charge of maintaining an internal accounting of hard links which is agnostic to the filesystem being used. U/Win has had this approach for years now, so we know its possible. Of course, it be nice if old man Korn would let us see the source ;-). Just a thought. As for the package, I tend to agree with Corinna. I don't think we should be packaging nt-only packages unless absolutely necessary. Cheers, Nicholas
ATTN: w32api maintainer, please remove mingw-specific code
Earnie or Danny, The recent directx reorganization in the winsup/w32api dir has allowed some mingw-only code to slip into the general build (lib/directx/dxerr.c). This causes a compile failure when building a cygwin target. Please have the author of the new code rectify this by not using tchar.h functions. Thanks in advance. Cheers, Nicholas
On forming a SC [was Re: ITP moratorium still in effect?]
cgf wrote: I'd like to explore new methods for getting packages into the distribution, however. Possibly we need a gdb packages steering committee which decides on these things. It could have rules like a package needs a simple majority vote to be a candidate for inclusion. I'd envision seven people on the committee. I have names in mind but the only two definites are really Corinna and me, both of whom would also have veto power. I'd also like to see a formal justification for why a package should be included, remembering that we have a software web page at cygwin.com which can be used to advertise packages that aren't quite up to snuff for the cygwin release. I think we have accepted a couple of packages here which really only deserve to be advertised on the web site. Chris, I'd really like to object to this SC idea, as most of us *have* exercised restraint while a select few have not. Why should the responsible maintainers be punished for someone's binge ITP'ing? I think we should keep it the way it is, perhaps with a little more of you laying the smack-down on anyone who is abusing it. I would respect a veto from you, Corinna, or Chuck, but the voting should still be left to the existing maintainers. After seeing what a steering committee has done to gcc, I'd be very hesitant to subject Cygwin to one. Please don't turn Cygwin decisions into political ones. Here's one idea to limit the binge ITP's: No more than 1 ITP per month unless approved by either you or Corinna. Another approach might be to ask: Do the Linux vendors support it?. Obviously this won't apply to strictly-windows applications. However, it is useful in that we are attempting to provide a unix/linux-like environment for Windows. If we are going to use any benchmark, this should be it. I'll end with some personal observations and opinions. I've been a RHL user since the 3.0.3 days, and I've seen the distro go from a small collection of packages to many hundreds of packages. Before that, I remember a time when an entire Slackware distribution fit on 20 floppies. Thus, I perceive our problems as being growing pains. I think understanding how the linux vendors handled these growing pains would be fruitful in how we approach this problem. I know some might not want to hear it, but if setup.exe can't handle the current load or scale in a sane manner, perhaps the problem lies with setup.exe itself? Look, setup.exe has served its purpose well, but now Windows comes with a feature-rich installer API. The last time I checked, this API is available for all versions of Windows since 95. Didn't someone broach the subject of possibly looking into NSIS installer (which, if I'm not mistaken, is a front-end for this API)? Aside from being more aesthetically pleasing, there are some features NSIS has which are quite nice and would mesh well with some of the extended needs now handled by post-install scripts. Choice is what it comes down to, and IMHO it should be the installer who needs to responsible for selecting the packages which best fit his/her needs. I'm sick and tired of seeing things being dumbed down for the benefit of the clueless at the expense of the power-user, and I know I'm not alone. Cheers, Nicholas
Re: Patch 20040321 for audio recording with /dev/dsp (indented), test issues
cgf wrote: On Tue, Mar 23, 2004 at 12:09:33PM +0100, Corinna Vinschen wrote: Chris, do you have a personally approved set of indent options which give a useful result, perhaps? No, I don't use indent very often. Gdb has an indent script, though. I've attached it to this message. I can't confirm or deny if it works well for c++, though. Indent is really for C code only, so it totally botches C++ constructors, destructors, classes, templates, virtuals, and just about anything else not C (especially templates). I was not aware that GNU had any style standards for C++-specific code. But then again, I find their standards to be boring, so I really haven't read them. Like Corinna, I usually run it through ident using -gnu and fix it up afterwards. Sometimes, if you pass private, public, class names and method names using -Tname1 -Tname2 it won't totally screw up. It still will treat labels (both C++ public/private and C goto) as if they were part of a switch statement, indenting them. Also, you'll want to use -T to declare any non-basic typedefs, such as off_t, clock_t, or size_t. If you don't, it will indent a pointer declaration as if it were a multiplication statement. Anyhow, IIRC, I believe these extra flags can be stored in a local dot file in the directory of the source file being indented (.indent.pro?). Cheers, Nicholas
Re: Ready for test coreutils-5.2.0-1 [again]
Here's what's changed since my last packaging attempt: 1) The following files are deleted from the distribution: usr/bin/uptime.exe usr/bin/kill.exe usr/share/man/man1/uptime.1.gz usr/share/man/man1/kill.1.gz 2) Fileutils patches have been included. Package is available at the same location: http://blackburn.homeip.net/cygwin-packages/release/coreutils/coreutils-5.2.0-1-src.tar.bz2 http://blackburn.homeip.net/cygwin-packages/release/coreutils/coreutils-5.2.0-1.tar.bz2 I have a suggestion for how to deal with the old fileutils/textutils/etc. Provide empty versions of the packages this replaces, bumping each by 1 revision. This way, it should uninstall the old stuff before installing the new stuff. At least, it worked for Jan when the new teTeX packages were made. Also, IIRC, some of the packages were linked against libbinmode.a to prevent problems with CR/LF. I wonder if this ought to be libautomode? Also, our /bin/sh is pretty much braindead (no job control, amoungst other things) since it was decided that shaving 50k off of ash is worth not having a POSIX compliant version. Subsequently, the nohup script will not work with /bin/sh (ash), so it is necessary to force it to use bash instead. See the following scripts from mknetrel to see what needs to be done pre/post config build: http://sources.redhat.com/cgi-bin/cvsweb.cgi/mknetrel/extra/fileutils?rev=1.2content-type=text/x-cvsweb-markupcvsroot=cygwin-apps http://sources.redhat.com/cgi-bin/cvsweb.cgi/mknetrel/extra/sh-utils?rev=1.3content-type=text/x-cvsweb-markupcvsroot=cygwin-apps http://sources.redhat.com/cgi-bin/cvsweb.cgi/mknetrel/extra/textutils?rev=1.2content-type=text/x-cvsweb-markupcvsroot=cygwin-apps Note that it is easier to just to pass -L/usr/lib -lbinmode to LDFLAGS instead of bothering with printing gcc's search path. Finally, this is kinda picky, but why not use bzip2 instead of gzip for the manpages? Cheers, Nicholas
Re: ITP moratorium
cgf wrote: We've had a flood of package ITPs and a missing package maintainer. I'm imposing a moratorium on ITPs for now. Thank you!!! I was wondering when someone was going to stop the insanity ;-). Cheers, Nicholas
Re: libungif (Was: Re: Maintainers/Packages List, 2003-11-01)
lapo wrote: Frédéric L. W. Meunier wrote: The author returned from a coma and it got a new home - http://libungif.sourceforge.net/ . 4.1.1 was released some days ago. Thanks, i'll have time to take a look at it (and package it) probably in the beginning of next week ^_^ Speaking of which, I'm almost certain UNISYS's patent on LZW is now totally expired in most *MAJOR* countries. Can we please make libungif - libgif? Cheers, Nicholas
Re: Possible legal problem with ccrypt? [Was: Re: Pending Packages List, 2004-02-13]
cgf wrote: On Sun, Feb 22, 2004 at 07:39:49PM +0100, Andreas Seidl wrote: However, a new problem might have popped up. Reading this thread http://www.cygwin.com/ml/cygwin/2004-02/msg01103.html I wonder if there are legal problems for RedHat to distribute the ccrypt package? Andreas, Next time, please keep it to yourself. Cheers, Nicholas
Re: [RFC] Would there be a need for a java-wrappers package?
pechtcha wrote: Hi, all, I would like to hear opinions on how useful a java-wrappers package would be. The package will contain a few shell scripts that allow users to invoke the regular Java SDK tools (java, javac, javadoc) from Cygwin, making them look like their Unix counterparts (i.e., POSIX filenames). The scripts would be updated versions of those posted in http://cygwin.com/ml/cygwin/2003-01/msg00174.html. There are a few reasons why I have misgivings about this. First off, some tools (notably Ant and Tomcat) recognize Cygwin and do something specific to Cygwin anyway, which will probably (most likely) get screwed up if the java they find looks like a Unix version (this did happen to me with Ant and Cygwin-native jikes). Secondly, the tools will certainly not be foolproof (although I'll try my best to make them as robust and autonomous as possible). Thirdly, java versioning may become a problem. You also might considier the problem which might arise if someone decided to package Kaffe. Perhaps it is time to investigate that system that Debian uses for managing packages with conflicting names. I think it is called update-alternatives or something like that... Anyhow, the scripts are still a nice idea :-). You might want to speak with Randall Schultz, he also has some really nice scripts I've been using for a year or two. Cheers, Nicholas
Re: Possible legal problem with ccrypt? [Was: Re: Pending Packages List, 2004-02-13]
cgf wrote:
On Sun, Feb 22, 2004 at 04:27:06PM -0500, Nicholas Wourms wrote:
cgf wrote:
On Sun, Feb 22, 2004 at 07:39:49PM +0100, Andreas Seidl wrote:
However, a new problem might have popped up. Reading this thread
http://www.cygwin.com/ml/cygwin/2004-02/msg01103.html
I wonder if there are legal problems for RedHat to distribute the ccrypt
package?
Next time, please keep it to yourself.
I'm sure you wouldn't enjoy it if Red Hat was taken to task for
something that could have been caught early, decided that cygwin wasn't
worth the hassle, and pulled it from sources.redhat.com.
No, I wouldn't, but I didn't intend on that being the only statement.
Consider this: The gpg which we distribute contains the *exact* same
cipher, AES{128,192,256}, as ccrypt plus gpg also has twofish
blowfish. The last time I checked, those two were also considered
strong encryption ciphers. Moreover, gpg can be used encrypt and
decrypt streams like ccrypt so, in a sense, they share similar
functionality. That's where I see the disconnect. Does this mean we
should ditch gpg as well or distribute a version with 128bit ciphers?
Frankly, I don't see why we should disqualified ccrypt because someone
thinks it might be a problem. Is it *really* a problem?
By his standard, RedHat has been breaking the law for years now, which
leads me to conclude that either:
A)The authorities don't care.
B)Red Hat doesn't care.
or
C)RedHat already has filed the necessary paperwork to allow it to
distribute binaries with strong encryption.
But, hey, thanks for clarifying just whom I can trust to be watching out
for the project's interests.
Hey, you certainly have a right to your opinion. The reality is that I
was trying to paste some text and accidentally sent that message before
it was complete. This reply contains some of the arguments I was
planning on including in that message to debunk his theory. Oh well,
that's all water under the bridge, believe what you want to believe...
I suppose I'll never get a gold star now ;-).
Cheers,
Nicholas
[1] The output of `gpg --help`:
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
Hash: MD5, SHA1, RIPEMD160, SHA256
Compression: Uncompressed, ZIP, ZLIB
*Ping*: fix strace and ssp opts for getopt argument permutation
Hi, Can someone please comment on what's holding up this patch: http://sources.redhat.com/ml/cygwin-patches/2003-q4/msg00223.html AFAICT, it was silently dropped without any reason. I'm waiting on someone to commit it so that I can submit my update to getopt which brings in the OpenBSD additions, including new getopt_long_only support. IANAL, but the modifications are s small (in fact half of them modify whitespace/comments) that I really should think it not be necessary to require an assignment. Thanks in advance. Cheers, Nicholas
Re: mingwex/getopt.c vs POSIXLY_CORRECT
danny_r_smith wrote: Hello This is a mingw issue, but effects cygwin -mno-cygwin apps (probably setup) too so I cross-post to see what antipathy (a new word: as in antipathy rules, OK) I raise. The cygwin implementation of getopt and getopt_long effectively defaults to POSIXLY_CORRECTness by virtue of: #define IS_POSIXLY_CORRECT (getenv(POSIXLY_INCORRECT_GETOPT) == NULL) Now, that environmental variable is bit strange to me, particularly in a native environment such as mingw that doesn't have a clue about PC, I propose this patch, for mingw subdir, so that the default implementation of mingw's getopt matches the documentation in NetBSD man page. In effect this means that the permute and in_order BSD extensions (the latter also a default GNUC extension) are enabled for mingw. According to Chuck, this was only done because the default behaviour broke strace under Cygwin. Unless I hear reasonable arguments against this, I will commit the patch after 48 hours. I don't think the above applies since the last time I checked, strace only works on Cygwin applications. Cheers, Nicholas
Re: Patch winuser.h in w32api
pechtcha wrote: 3) Patches for w32api should be sent to the mingw-patches mailing list (see http://mingw.org/). FYI, they also have their own rules for submitting patches -- see http://lists.sf.net/lists/listinfo/mingw-patches for instructions. Since when? I've seen patches for w32api posted to and accepted from here on numerous occasions in the past. Cheers, Nicholas
Re: [jjohnstn: initial version of iconv support checked in]
wrote: Please don't: we already have a perfectly good iconv implementation in the distribution and there's no law against providing iconv as a separate library from the kernel/libc/whatnot. Of course it isn't against the law, but the fact is that most modern, non-microsoft, libc's provide it. Not all apps are GNU and some require a good deal of retooling to get them to recognize our libiconv. You also might want to consider the interests of our current libiconv maintainer, who also happens to maintain quite a few other core packages. I'm almost certain that he'd welcome not having to prepare and release new libiconv versions. Also, you forget the fact that some of the binaries packaged in the Cygwin dll package rely on the external libiconv. IMHO, applications which are part of that core package really ought not to rely on a library external to those provided by cygwin/w32api/newlib/libiberty. Finally, it might be something desired by those looking to actually pay $$$ to license the Cygwin dll for use in non-GPL projects. By far most applications don't care too much about transcoding, so most applications would simply have to carry around some extra luggage if it were built into the Cygwin DLL. Stop spreading FUD, that last part isn't true at all. There is no extra baggage, if anything, application sizes might be reduced by a minuscule amount. This is assuming one less external library would make for a slightly smaller PE header. However, since it is: A) impossible, by design, to statically link with Cygwin's libc and... B) impossible, by design, for ld to re-export symbols found in libc[1] this concern really is a moot one. That, and I wonder how libiconv would interact with this.. but as I haven't given that any thought at all (only one neuron assigned to the task for the next two seconds or so) I wouldn't be willing to make any guesses about that. Simple, this replaces libiconv. The libiconv dev package would be obsoleted, replaced with an empty one, however we would retain current libiconv runtime libs for compatibility. This won't affect applications built against the old libiconv since the old libiconv data files aren't clobbered by newlib's iconv. Shared static libraries, however, would need to be rebuilt since libiconv uses different symbols from the libc iconv (it uses #define's in iconv.h to alias the expected symbols, such as iconv_open, to the libiconv versions. Just my $0.02 (canadian - which is where I will be going in two wheels and three spokes [1]) Which is about $0.0125 US... As I said before, I think we should take a wait and see approach. There's no rush or reason to make a decision now, since it is disabled by default. Let some people try it out on their own and report back with their findings. We can always revisit this at a later time, once the newlib iconv support is more mature. Cheers, Nicholas [1] This, of course, is assuming the default case and does not consider the operations done during the building of the Cygwin dll or those involving custom ld scripts.
Re: CAMP (was Re: HEADSUP: Apache maintainer wanted!)
[EMAIL PROTECTED] wrote: On Jan 22 04:02, Reini Urban wrote: Igor Pechtchanski schrieb: http://cygwin.com/acronyms/#CAMP. Done. :-D BTW: I hope you all know what camp originally means. Originally a term defined by Susan Sontag for a special outrageous and overt style mainly used by gays. We often use it in discussion on films. (camp style or camp aesthetic) http://www.filonova.no/konferanser/irscl/panel_3b.html Wow, and I thought camp is originally a native english word, having the meaning of a place where people stay in tents or other temporary structures. But I could be wrong. Actually you are right, I don't know where people come up with this craziness, but camp has been in use for ages as a shorten form of basecamp and campsite. I'm quite certain that it was in use long before the word gay meant anything else besides happy. Cheers, Nicholas
Re: ITP: sgml-base-1.1
[EMAIL PROTECTED] wrote:
This is a small package but one I hope will enable me (and perhaps
others) to contribute various SGML DTDs in a FHS-compliant way.
This is version 1.1-1 since there was a proposal about 2 years ago and
the 1.01-1 packages are floating around.
It is mainly a single perl script, update-sgml-catalog, which comes
from Debian's sgml-base package. It also includes text of the SGML/XML
location proposals for FHS and LSB in the /usr/share/doc/sgml-base/
directory so maybe people can know why.
# sgml-base
sdesc: A FHS-compliant foundation for SGML packages
ldesc: The sgml-base package provides the basis for SGML
and XML packages. Mainly this is the update-sgml-catalog(8)
script to build the /etc/sgml/catalog system catalog. Please
see the documentation and examples in
/usr/share/doc/sgml-base/ for more details.
category: Doc Text
requires: perl
8-
#!/bin/sh
wget http://ns1.iocc.com/~joshua/cygwin/sgml-base-1.1-1.tar.bz2
wget http://ns1.iocc.com/~joshua/cygwin/sgml-base-1.1-1-src.tar.bz2
wget http://ns1.iocc.com/~joshua/cygwin/setup.hint
8-
EXTRA INFO:
My eventual plan with this is to:
1. Get the DocBook SGML DTDs and DSSSL stylesheets packaged in a FHS-compliant
way. (Also the XML and XSL ones, though Marcel Telka has already packaged 4.2
without the SGML catalog part. It would be great if this could be eventually
updated and moved to the FHS standard locations.)
2. Remove the old cygnus-based stylesheet references from winsup/doc in CVS
(db2html, etc.), relying only on the FHS-compliant DocBook SGML installation.
3. Package openjade and opensp. These don't build with gcc3 yet, so that might
take a while. This would allow users to build cygwin-doc with tools available
from the Cygwin net release (with the possible exception of the info manual).
4. Package a bunch of other DTDs like {X,}HTML, TEI, EAD and stuff like
passivetex.
Thank You
I have a few comments to make, since I've been running a full-blown
redhat-based docbook system under Cygwin for about 6 months now (I have
all the extras, too, including the TeX stuff). For most folks, getting
a working system can be an exercise in masochism. Getting a system
which is distributed via packages can be even worse. As I mention later
on, this has been a long time in the making for me.
1) For various reasons, I don't care for debian's approach to the
layout of the /usr/share/sgml tree. For one, it is obtuse and quite
geared towards a debian linux system. IMNSO, and not to be a suckup to
RedHat, RedHat's layout makes much more sense. Plus, it follows a more
loosely adhered to standard for putting files where most scripts and
configure programs expect them. Furthermore, despite those links you
gave, the FHS *really* doesn't have very much to say on the subject,
other then specifying the TLD of the configuration directory and the
data directory.
2) As I mentioned, I have a working OpenSP/openjade. The main problem
is the prolific use of that [EMAIL PROTECTED] broken g++ #pragma (the same one
that breaks mysql builds) in OpenSP. Also, there are some other dumb
c++ style issues which cause gcc-3.3+ to choke (thanks, of course, to
the anal standards people on the gcc steering committee). Anyhow, I
have a patch against the current openjade OpenSP which resolve all
these problems, fix some leaks, and produce a usable jade suite.
3) Someone has got to force our teTeX maintainer, Jan, to apply changes
to the various TeX configuration files to make it usable with jadetex,
xmltex, passivetex, etc. The current defaults are way, way too small to
handle the memory requirements needed for processing sgml/xml streams.
In fact, these defaults seem to be geared towards users of machines with
16MB or less memory, which is ridiculous for us. Also, we need some new
backends, namely hugelatex, built and distributed with the base teTex
package. TeX configuration, I have found, can be very sensitive, which
is why minimizing the amount of changes to it from installed packages is
a good thing.
4) Another reason going with a more RedHat-ish layout is to make it
easier to package the other items. The spec files were extremely useful
in demystifying the install process. In fact, once I had hand-installed
the various base programs, I was able to use rpm to build and install
the rest from the srpms:
docbook-style-dssl-1.78-2
passivetex-1.24-2.1
xhtml1-dtds-1.0-5
docbook-utils-0.6.13-7
docbook-utils-pdf-0.6.13-7
docbook-dtds-1.0-22.1
docbook-style-xsl-1.61.2-2.1
xmltex-2118-14.1
jadetex-3.12-9
perl-SGMLpm-103ii-12
linuxdoc-tools-0.9.21-1
5) Doing it the RedHat way enabled me to produce a system which could
actually build our documentation using the db2* utils. The cygnus style
sheets are actually quite nice, once you get used to them.
6) You really shouldn't use
Re: libwin32-perl-0.191 (ready for upload and testing)
rkitover wrote: Hi Gerrit, Thanks so much for testing my package! What a mess :) Gerrit, Now that it seems we'll be providing perl module packages, I think we should come up with some sort of naming standard for consistency. For example, Red Hat prefixes their perl packages with perl- and generally uses the same case as is found on CPAN. So if we were to adopt this route, this package would be perl-libwin32-0.191-1. Also, may I suggest we make a release subdir especially for perl modules on the mirrors (like XFree86)? This way we can keep the perl modules neatly tucked away in their own subdir hierarchy, rather then cluttering up the already growing release TLD. Just a thought... Some other food for thought: 1) Man pages are good, especially since they can be indexed and keyed. Have builders use make manifypods prior to make install. 2) Try not to clobber the perllocal.pod, but rather come up with a way to update it (perhaps regenerate it from a pool of fragments?). 3) Make a vendorinstalldir for Cygwin, to keep our mods separate from user's local mods, but provide a stable api for dependencies like mod-perl or what-not. Cheers, Nicholas
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
Pierre A. Humblet wrote: At 12:46 PM 12/27/2003 -0500, Christopher Faylor wrote: I missed the 'sh -c' clue in your previous message. Since sh uses vfork, that indicates a vfork problem. I've checked in some more changes to deal with this. It seems to do the right thing both with sh -c and without. It also should have the added benefit of doing the right thing wrt deallocating the console appropriately since open_fhs should now track the ctty usecount. This was screwed up before, apparently even before I started mucking with the tty stuff. I sure do hate usage counting. cgf Yes, that works fine now, as does bash -c inetd. Sorry to jump in on this, but I run into a few problems with the changes you made last night and one issue which has been a problem for some time now. This is on my Win2k box and all problems were noticed when I logged in remotely via ssh (I have not tried locally). If it makes any difference, the /usr/src dir, where all my project and cygwin source is contained, is a managed mount. Issues from yesterday's checkin: 1)When run by itself from the command line, `make` is not forking properly for recursive makes, instead it aborts and returns a bogus HANGUP signal to the console. This is easily seen when attempting to build the Cygwin tree. I cannot provide any useful output since it appears that calling the process from within gdb or through strace actually keeps make from failing to fork, but make still screws up the order of entry into subdirs. 2)`procps auxf` incorrectly identifies top-parent processes as defunct, even though ps and the nt process monitor shows them to be valid. However, for postgres's postmaster, the parent and *all* children are labeled as defunct even though I can confirm that the server is up and running. 3)Running configure scripts using sh.exe (which is default when you ./configure) always hangs, whereas running them through bash.exe works fine (although it does hang from time to time). In either case, when it hangs, doing ctrl-c will drop you to the command line. However, the process isn't terminated, like one would expect. Also, it refuses to obey any signal except SIGKILL. Existing issues since 1.5.5: 3)I find myself involuntarily logged-out of my sessions at random intervals. This is especially prevalent when doing massive recursive `rm -rf`'s or `grep -rn`'s or any other form of intensive disk i/o. However, whatever is causing it seems to be getting fixed, since this happens less frequently then it used to. A small kludge I use to get around this is by running links.exe then using ctrl-Z to send it to a stopped state. Then if it tries to log me out, it will fail because I have a stopped process. 4)lynx crashes on startup, dropping me back to the command line. Running it through gdb, the segfault happens at line 81 of cygtls.cc, _last_thread-next = this which is inside the function _threadinfo::init_thread(void*). Unfortunately, my system is in a state where I cannot get make to run correctly, so trying to build a debug version of lynx at this point is not feasible. I should note that I do not see this problem inside links. Although I'm further investigating these problems, I thought I might share them since the next release is being discussed. Cheers, Nicholas -- 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: 1.5.6-pre: Occasional bad memory accesses within cygwin1.dll
Max Bowsher wrote: I installed a self-built cygwin HEAD version - mostly it works fine, but it causes odd failures during builds (speculation: race when many processes being created and destroyed?) The most common failure is a Windows error box: The instruction at 0x6108621a references memory at 0x610030b0. The memory could not be written. (These addresses are constant.) $ addr2line -e /bin/cygwin1.dll 0x6108621a 0x610030b0 .../src/winsup/cygwin/shm.cc:331 .../src/winsup/cygwin/cygthread.cc:34 The errors are usually in sed, grep, or dirname. This is sometimes accompanied by this error on the console: 4 [proc] sh 1160 sig_send: error sending signal 20 to pid 1160, pipe handle 0x, Win32 error 6 Less common failures include shell scripts receiving terminating with a Hangup message, or locking up entirely. I've seen this while running recursive `make`'s. Have you tried running configure or make from within gdb? I've found that doing that actually seems to prevent the races which you describe, however it does cause make to screwup the subdir entry order. As for the locking up, a big ditto there. Also, are you having any trouble with lynx? Cheers, Nicholas -- 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: ImageMagick/Graphicsmagick
[EMAIL PROTECTED] wrote: Again, you have not investigating the best solution here. You have made up you mind based on just a few criteria and you are shoving it down everyones throat. Given your strong statements and clear unwillingness to discuss which project is best based on merit, don't bother replying. I will not waste anymore of the CYGWIN community's time on a dead subject. I will tell the CYGWIN community that ImageMagick Studio intends to have full support of ImageMagick 5.5.7 and 5.5.8 Beta for CYGWIN and both source and binaries will be available on ftp://ftp.imagemagick.org/pub/ImageMagick. I'm sorry but I don't like the potential ramifications if this were to happen. Not that I really have any say in the matter, I don't, but I feel that others out there share some of the concerns I will mention. Harold, you've earned every right to make this decision as you see fit, and I respect that, but surely some sort of compromise can be reached which will satisfy both parties? The original author seems willing to work with your complaints if you are willing to keep an open mind. However, the original author should realize that Harold has some valid points concerning the libtool versioning you used as well as hardcoding the version minors into the module directory paths. In effect, this means that we'd have to make a new runtime package each time the subminor was bumped PLUS keep the existing packages to maintain backward compatibility. On the other hand, I've not looked at GraphicsMagick, do they use the same names for includes, include-dirs, modules, module-dirs, libraries? If not, I can definitely see this as a PITA if you are building something which depends on the original names, since you'd have to tell it the new names and such. However, if it does use the same names, then inevitably there are going to be many who get confused and unintentionally (or perhaps intentionally) install both versions of the this software. When dll hell starts to set in, they probably aren't going to e-mail either of you personally, rather they are going to flood our already high-volume main list with false bug reports and what not. Plus, what if I or anyone else decide to package something which depends on the ImageMagick libraries? Then we'd have to tell people to make sure they uninstall the author's version to be able to use my package, even if they preferred the author's version. You can see where I'm going with this and the picture isn't pretty. Cheers, Nicholas
[BUG] Cygwin dll (cvs): subdirs of the root dir of a managed mount do not inherit the ability to create files using reserved names
Hi All, This is using a dll compiled from the latest cvs source. The problem occurs in newly created subdirs of a managed mount's rootdir. For illustration purposes, /usr/src is the mountpoint and /usr/src/temp is the newly created directory. Here's how to reproduce: 1)mount /usr/src as managed. 2)create the dir /usr/src/temp. 3)cd /usr/src/temp. 4)try running `touch aux.c` (this should fail). 5)cd .. 6)try running `touch aux.c` (this should succeed). I ran strace on both operations and observed that the problem may be rooted in conv_to_win32_path(). I haven't had much time to thoroughly dig into the source, so I might be wrong. For your reference I've attached a brief summary of my observations as well as the relevant differences between the two straces. Cheers, Nicholas This is the mount: C:\Cygnus\cygwin\usr\src on /usr/src type system (binmode,managed) CYGWIN=ntsec ntea tty binmode codepage:oem server check_case:strict export ** Program name: C:\Cygnus\cygwin\bin\touch.exe (1964) App version: 1005.0, api: 0.88 DLL version: 1005.6, api: 0.109 ^ DLL build:2003-12-17 20:17 OS version: Windows NT-5.0 Heap size:1073741824 Date/Time:2003-12-21 19:33:36 ** Please note that I have bumped the minor 107-109 because of ongoing work to add some of the resolver catgets stuff. Otherwise, it is a stock dll with a stock touch. To be clear, items preceded by minus (-) signs are the differences from the strace of `touch aux.c` run in the subdir (/usr/src/temp), while the items preceded by plus (+) signs are the differences from the strace of `touch aux.c` run in the root of the managed mount (/usr/src). You'll most likely be interested in the content at (@@ -355,55 +350,78 @@), which is where I note that the logic path between the two traces first diverges. It would seem to me that the problem happens in conv_to_win32_path(), as this seen in the following: -[main] touch mount_info::conv_to_win32_path: conv_to_win32_path (/usr/src/temp/aux.c) -[main] touch set_flags: flags: binary (0x2) -[main] touch mount_info::conv_to_win32_path: src_path /usr/src/temp/aux.c, dst C:\Cygnus\cygwin\usr\src\temp\aux.c, flags 0x80A, rc 0 +[main] touch mount_info::conv_to_win32_path: conv_to_win32_path (/usr/src/aux.c) +[main] touch set_flags: flags: binary (0x2) +[main] touch mount_info::conv_to_win32_path: src_path /usr/src/aux.c, dst C:\Cygnus\cygwin\usr\src\%61ux.c, flags 0x80A, rc 0 --- strace.resname.subdir.1 2003-12-21 19:38:03.453125000 -0500 +++ strace.resname.topdir.1 2003-12-21 19:38:48.859375000 -0500 @@ -40,22 +40,17 @@ [main] touch environ_init: 0x10200ED8: MSSDK=C:\Program Files\Microsoft SDK\. [main] touch environ_init: 0x10200F08: MSTOOLS=C:\Program Files\Microsoft SDK\. [main] touch environ_init: 0x10200F38: NUMBER_OF_PROCESSORS=2 -[main] touch environ_init: 0x10200F58: OLDPWD=/usr/src -[main] touch environ_init: 0x10200F70: OS2LIBPATH=C:\WINNT\system32\os2\dll; -[main] touch environ_init: 0x10200FA0: OS=Windows_NT +[main] touch environ_init: 0x10200F58: OLDPWD=/usr/src/cygwin-src +[main] touch environ_init: 0x10200F78: OS2LIBPATH=C:\WINNT\system32\os2\dll; +[main] touch environ_init: 0x10200FA8: OS=Windows_NT [main] touch getwinenv: can't set native for PATH= since no environ yet [main] touch normalize_posix_path: src . -[main] touch mount_info::conv_to_posix_path: conv_to_posix_path (C:\Cygnus\cygwin\usr\src\temp, no-keep-rel, no-add-slash) -[main] touch normalize_win32_path: C:\Cygnus\cygwin\usr\src\temp = normalize_win32_path (C:\Cygnus\cygwin\usr\src\temp) -[main] touch mount_info::conv_to_posix_path: /usr/src/temp = conv_to_posix_path (C:\Cygnus\cygwin\usr\src\temp) -[main] touch cwdstuff::get: posix /usr/src/temp -[main] touch cwdstuff::get: (/usr/src/temp) = cwdstuff::get (0x22F598, 260, 1, 0), errno 0 -[main] touch normalize_posix_path: /usr/src/temp = normalize_posix_path (.) -[main] touch mount_info::conv_to_win32_path: conv_to_win32_path (/usr/src/temp) -[main] touch set_flags: flags: binary (0x2) -[main] touch mount_info::conv_to_win32_path: src_path /usr/src/temp, dst C:\Cygnus\cygwin\usr\src\temp, flags 0x80A, rc 0 -[main] touch symlink_info::check: not a symlink -[main] touch symlink_info::check: 0 = symlink.check (C:\Cygnus\cygwin\usr\src\temp, 0x22F258) (0x80A) +[main] touch mount_info::conv_to_posix_path: conv_to_posix_path (C:\Cygnus\cygwin\usr\src, no-keep-rel, no-add-slash) +[main] touch normalize_win32_path: C:\Cygnus\cygwin\usr\src = normalize_win32_path (C:\Cygnus\cygwin\usr\src) +[main] touch mount_info::conv_to_posix_path: /usr/src = conv_to_posix_path (C:\Cygnus\cygwin\usr\src) +[main] touch cwdstuff::get: posix /usr/src +[main] touch cwdstuff::get: (/usr/src) = cwdstuff::get (0x22F598, 260, 1, 0), errno 0 +[main] touch normalize_posix_path: /usr/src = normalize_posix_path (.) [main] touch mount_info::conv_to_win32_path:
[FYI] Cygwin dll: mv'ing non-managed dirs to managed mounts also fails
Hi all, I gather this isn't going to be fixed, which is fine by me, since cp -a -preserve=all works equally as well. However, I would like to note for the record and the archives that `mv` is also experiencing problems when moving non-managed folders to managed mounts as was hypothesized by CGF in: http://sources.redhat.com/ml/cygwin/2003-09/msg01122.html The symptom is that, after the folder is moved, ls is only able to see files/dirs with all lowercase, returning ENOENT for any file/dir with a capital letter in its name. I know that patches are gratefully accepted, but I would suggest a two-tier approach to solving this. First, add a new routine and flag to mount which would allow the user to make mount walk the dir tree of the source and do what magic is needed to bring the items under managed mode. The second part would be to modify mv friends to check for this attribute on the source and dest if copying between mounts, taking appropriate action as necessary. I don't think this is all that foreign to file-utils, since it somewhat analogous to manipulating files between ALC/EA-aware fs's and those fs's which are non-ACL/EA aware. Cheers, Nicholas -- 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: [ITP] xemacs: A powerful, highly customizable open source text editor and application development system
Charles Wilson wrote: Nicholas Wourms wrote: Charles would expect...an X-only drag-n-drop wouldn't be that helpful. Why not? We have other X11 packages which could utilize this. Plus, Harold's on a mission to knock the number of X11 packages sky-high, so undoubtly we'll see many more applications which will utilize this. XEmacs speaks the following two dragndrop dialects: CDE, and Offix. Not the opendesktop one, nor the KDE one, nor the Gnome one. So, of Harold's new packages, which ones support CDE or Offix style dragndrop? None, but as I mention later on, I had heard that it supported other dnd protocols. (Now, I believe the GTK-XEmacs build sprechen se Gnome/opendesktop dragndrop -- but GTK-XEmacs isn't under discussion. (At least, not until we get a glib, atk, pango, and gtk package.) The last time I heard, Xemacs also spoke the official X11 XDnD and Motif/Lesstif DnD protocols. Even if not fully supported yet, I'm pretty sure there was some support for those protocols. We can make an xemacs-extra package, but there's still the conflict with the ctags package. Are the source code differences mutually exclusive or is one a subset of the other. Perhaps merging the changes into the other packages might be the way to go? AFAIK, ctags and friends don't depend on any emacs-specific share libs, right? I dunno. The point is, that on Mandrake at least, these conflicting files were moved into a separate package so that one could install both Emacs / XEmacs / Ctags / etc. That is, if there are conflicts, minimize and segregate them. As I'm sure you know, RPM handles conflicts gracefully while setup mostly does not. Therefore, this makes things more complicated on Cygwin, since conflicting packages can actually lead to conflicting files not being installed at all. I would *strongly* urge that we not intentionally allow any conflicts at all (at least not at this point), as it can lead to all sorts of problems. IIRC from the last ctags/emacs fiasco, Corinna made her stance on conflicting ctags known: she would have none of that. However, since these conflicts all share a similar, albeit forked, codebase, wouldn't it be better, in the long run, if we just merged them into a single package? Since I'm the one asking, I'll check out the sources later on and see if this is possible. If nothing else, I'm pretty good at merging code from forks :-). Not necessarily, those aren't your only options. If he's using it statically, then all that is really needed is to provide the source in the xemacs tarball and have the build script build it. There is no need to ITP the whole thing if all that you want is the client library part. This is done by a couple of other packages which use external static libs. Sure. Personally, I view that as even MORE work than just ITP'ing LDAP. I'm curious as to why you think this is so? Surely providing a small portion of the script for compiling, but not installing, a static openldap client lib is going to be much easier in the long run? Otherwise, you'd have to package the full development libraries, not to mention the server itself, and you'd have to be willing to provide support, as well. I'm not trying to doubt the capabilities or motivations of Dr. Zell, but why advocate he volunteer to maintain the entire kitchen sink when all he needs is water? If Dr. Zell actually wants to provide and support the entire package, then more power to him. Otherwise, I see OpenLDAP as being at least as much, if not more, of a maintenance burden as Apache currently is. Thus, it would be much more work in the long-run supporting it rather then building it as an internal static client lib. Cheers, Nicholas
Re: [ITP] xemacs: A powerful, highly customizable open source text editor and application development system
Dr Volker Zell wrote [SNIP] I'll try if it works. It should now since the latest X11 has fixed libXt so that a shared Xaw3d works... Charles that. I also suspect that --with-dragndrop won't work with an X-based Charles build of XEmacs on cygwin (at least, not in the way we Windows denizens Charles would expect...an X-only drag-n-drop wouldn't be that helpful. Why not? We have other X11 packages which could utilize this. Plus, Harold's on a mission to knock the number of X11 packages sky-high, so undoubtly we'll see many more applications which will utilize this. Charles FWIW, on my Mandrake system, the following files are in an Charles xemacs-extras package: Charles /usr/bin/b2m Charles /usr/bin/ctags Charles /usr/bin/etags Charles /usr/bin/ootags Charles /usr/bin/rcs-checkin Charles /usr/share/doc/xemacs-extras-21.4.12 Charles /usr/share/doc/xemacs-extras-21.4.12/README Charles /usr/share/man/man1/ctags.1.bz2 Charles /usr/share/man/man1/etags.1.bz2 We can make an xemacs-extra package, but there's still the conflict with the ctags package. Are the source code differences mutually exclusive or is one a subset of the other. Perhaps merging the changes into the other packages might be the way to go? AFAIK, ctags and friends don't depend on any emacs-specific share libs, right? Charles There's a problem with your proposed distribution: you *MUST* distribute Charles all relevant source code, including libraries. It's not acceptable for Charles us to provide an xemacs binary which is linked against a static LDAP Charles library yet not also provide the source for that LDAP library. Charles I'm afraid you'll either need to turn off LDAP support, or ITP an LDAP Charles package. I think I go for an LDAP package... Not necessarily, those aren't your only options. If he's using it statically, then all that is really needed is to provide the source in the xemacs tarball and have the build script build it. There is no need to ITP the whole thing if all that you want is the client library part. This is done by a couple of other packages which use external static libs. Cheers, Nicholas
Re: [ITP] xemacs: A powerful, highly customizable open source text editor and application development system
Dr Volker Zell wrote: Hi I would like to contribute and maintain the xemacs package: * http://xemacs.org/ (Homepage) * http://ftp.us.xemacs.org/ftp/pub/ (Download location) Hi Dr Zell, FYI, the emacs provided via setup is Xemacs, not GNU emacs. So this is already provided by the emacs-* packages and is maintained by Joe Buehler. I'm not sure if the elisp packages it provides is as all-inclusive as the sumo version, so he'd be the guy to talk to regarding that. Cheers, Nicholas
Re: An ImageMagick review (partial) [Was Re: [ITP - Ready for review] ImageMagick]
Chuck wrote:
So, maybe you *shouldn't* revert back to -release versioning. I'd ask
Bob F. what he was thinking...because 'strings cygMagick-6.dll' (or
'strings libMagick-5.5.x.so' on linux) shows that the
/usr/lib/ImageMagick-X.Y.Z/modules-Q16/coders/ path is compiled into the
DLL, which means that the interface really really DOES change with every
release, so you might as well use -${MAJ}-${MIN}-${MIC} to name the
shared library!
While you're at it, ask them what they were on when they created two
files in the guide dir which have the same name, but different case.
They really ought to know better...
Cheers,
Nicholas
Re: [ITP] ImageMagick
[EMAIL PROTECTED] wrote:
David,
Billinghurst, David (CALCRTS) wrote:
I have built ImageMagick-5.5.3 as a shared library. It worked for me
some time in July 2003.
I indended to contribute the package myself, but (insert usual
excuses). I am travelling on business, but I have one of my old build
script with me. See below.
Thanks. Can you justify the following flags you passed:
--disable-largefile --without-frozenpaths \
--with-magick-plus-plus --without-perl -without-wmf
--without-perl is required because the PerlMagick build fails.
Getting it to support a vendor installdir is actually not that
difficult. OOTB, it isn't DESTDIR friendly. However, all it requires
is, post configure, switching to the perl dir and rerunning perl
Makefile.PL with the appropriate MakeMaker args to get it to work.
--without-wmf is detected automatically.
--with-magick-plus-plus is detected automatically.
I see no reason why we shouldn't support Magick++, it built fine for me
a year ago.
--without-frozenpaths is a mystery to me. I don't know what it does.
Additionally, configure.ac looks for convert:
AC_PATH_PROG(ConvertDelegate, $ConvertDelegateDefault,
$ConvertDelegateDefault)
On Windows, it finds:
checking for convert... /cygdrive/c/WINDOWS/system32/convert
Not out of the box, but you could do what I do, which is to add a script
to profile.d which sanitizes my $PATH of unnecessary entries. Or you
could set the PATH inside the build script and restore it after it
finishes. Or, if you are feeling bold my friend, you could rewrite the
macro based on the source from the m4 file in global autoconf share dir.
You'd need to change the name of the macro (i.e. AC_CYG_PATH_PROG),
edit it so that it sanitizes the $PATH of /cygdrive/* before beginning
the actual check, and then drop the macro into acinclude or
configure.{in,ac} itself.
Cheers,
Nicholas
Re: [ITP] ImageMagick
Harold wrote:
Nicholas Wourms wrote:
Harold wrote:
David,
Billinghurst, David (CALCRTS) wrote:
I have built ImageMagick-5.5.3 as a shared library. It worked for me
some time in July 2003.
I indended to contribute the package myself, but (insert usual
excuses). I am travelling on business, but I have one of my old
build script with me. See below.
Thanks. Can you justify the following flags you passed:
--disable-largefile --without-frozenpaths \
--with-magick-plus-plus --without-perl -without-wmf
--without-perl is required because the PerlMagick build fails.
Getting it to support a vendor installdir is actually not that
difficult. OOTB, it isn't DESTDIR friendly. However, all it requires
is, post configure, switching to the perl dir and rerunning perl
Makefile.PL with the appropriate MakeMaker args to get it to work.
I ran 'perl Makefile.PL' but it complained about not being able to find
some X libs. Any clue as to what the appropriate MakeMaker args would
be? I have no idea what MakeMaker is let along what args it needs.
Oh yeah, that's right! Dumb MakeMaker is screwing up because it only
tries to look for libname.a on Cygwin and won't recognize dll.a's by
themselves. Gerrit fixed this problem upstream after the 5.8.1 perl
release. Let me check an make sure that the latest perl (rather then
just CVS) has the fix... Ah yes, it was fixed in 6.20. Can you update
to Gerrit's test release of perl 5.8.2 via setup.exe? According to my
installation of 5.8.2, it has MakeMaker 6.21, so you should be good to go.
Now, as for how to do the DESTDIR installation. This is what RedHat
does, and it works for me in most cases:
perl Makefile.pl
make OPTIMIZE=$CFLAGS
make manifypods
make install PREFIX=/destdir/usr
where destdir is the *full* canonical path to the .inst/ dir.
Please be sure to remove any perllocal.pod files in the destdir, as they
will clobber the installer's installed-module list (in the same manner
as texinfo's dir entry file).
--without-wmf is detected automatically.
--with-magick-plus-plus is detected automatically.
I see no reason why we shouldn't support Magick++, it built fine for
me a year ago.
I think you read that wrong: --with- is detected automatically. That
is, it defaults to yes.
Ooops, indeed I did read wrong.
--without-frozenpaths is a mystery to me. I don't know what it does.
Additionally, configure.ac looks for convert:
AC_PATH_PROG(ConvertDelegate, $ConvertDelegateDefault,
$ConvertDelegateDefault)
On Windows, it finds:
checking for convert... /cygdrive/c/WINDOWS/system32/convert
Not out of the box, but you could do what I do, which is to add a
script to profile.d which sanitizes my $PATH of unnecessary entries.
Could you send in that snippit for me? I had to clean the path by hand
this time.
This is what I use to get rid of a dumb path with spaces (which causes
all sorts of mayhem on my box):
#Get rid of annoying spaces in $PATH
NEWPATH=`echo ${PATH} | sed -e s:\/cygdrive\/c\/Program\
Files\/Symantec\/Norton\ Ghost\ 2003\/\:::g`
export PATH=/usr/cygwrappers:${NEWPATH}
I just put it in path.sh, dropped it in my profile.d, and was good to
go. Obviously, you can add more path expressions by passing additional
strings of ' -e s:expr::g ' to the pipeline. Be sure to get 'em
inside the tick marks, if you do add on.
Cheers,
Nicholas
Re: Possible bug with __attribute__((alias)) in gcc-3.3
Danny Smith wrote:
Nicholas wrote:
One problem is that you (or gcc) need to tell ld that 'foo' is function, not
data.
I'll be the first to admit that I'm almost totally w/o a clue when it
comes to assembly. I'm afraid the gas manual is not very helpful in my
effort to alleviate this :-(.
Adding this to file foo.c (after the alias declaration):
__asm__ (.def _foo; .scl 2; .type 32; .endef\n);
would do that.
That fixes the testcase on mingw anyway.
Yes! Thanks, this helps a ton! I can confirm it works in native
Cygwin, too.
I'm testing a patch now that would make gcc do that too (for aliased
functions).
Cool deal, I look forward to trying it.
I only wish gas could better handle converting what I assume to be ELF
syntax. This is often the case in other projects, for example from
MySQL's strings-x86.s:
.globl bmove_allign
.type bmove_allign,@function
bmove_allign:
...
asm stuff
...
.end:
.size bmove_allign,.end-bmove_allign
Yes, this wish is pure laziness, but it would save time and make more
asm code work OOTB if gas could deal with it.
However, in general,when you do dllexport with code written in straight
assembler, you will need to add a function directive like the one above
so that the linker does the right thing.
For the archives and in case anyone was curious, here's what I've
devised (until your patch to gcc gets in) for {weak,strong}_alias macros:
#define weak_alias(name, aliasname) strong_alias(name, aliasname)
#define strong_alias(name, aliasname) \
extern __typeof__(name) aliasname __attribute__((__alias__(#name))); \
__asm__(.def \_ #aliasname \; .scl 2; .type 32; .endef\n);
After your patch gets in, I'll drop the third line.
Again, I'm in uncharted territory, but... If you think it looks ok, I
would like to add these compatibility macros to Cygwin's sys/cdefs.h.
This is assuming that the values in .scl and .type remain static for
PE-32bit. Feel free to add them to MingW, as well, if you want.
Why should we have them, one might ask? Frankly, because having to type
out all that crap for each project takes too long and too much effort.
I imagine this is why GNU BSD put them in system headers in the first
place. Bind is just one example of what happens when you don't have
these macros. Just #define'ing the aliases in headers won't cut it
because this will break some autoconf scripts or builds if the function
is implicitly used by them (which I believe is the case for AC_CHECK_LIB).
(BTW, you've just reminded me of a similar problem in libffi assembly code
that needs to be fixed. Thanks )
No problem, glad to help ;-).
Cheers,
Nicholas
--
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: Possible bug with __attribute__((alias)) in gcc-3.3
Nicholas Wourms wrote: [SNIP] #define strong_alias(name, aliasname) \ extern __typeof__(name) aliasname __attribute__((__alias__(#name))); \ __asm__(.def \_ #aliasname \; .scl 2; .type 32; .endef\n); ^^ ^^ Sorry, Ack, I pasted an older version of the macro, which was over quoted. This should be the one that works: #define strong_alias(name, aliasname) \ extern __typeof__(name) aliasname __attribute__((__alias__(#name))); \ __asm__(.def _ #aliasname ; .scl 2; .type 32; .endef\n); Cheers, Nicholas -- 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: [Review - Good to go] suite3270 [Needs 1 more vote]
Corinna wrote: On Tue, Dec 02, 2003 at 12:26:24AM -0500, Daniel Reed wrote: That being said, I will list you as voting pro for suite3270. The suite3270 proposal is now only one vote away, as you stated. No, it's not. I voted already pro inclusion, right after Peter's first proposal. I say pro, too! Cheers, Nicholas
Re: [PATCH]: Add flock syscall emulation
Corinna wrote: On Sun, Nov 30, 2003 at 12:57:48PM -0500, Nicholas Wourms wrote: Corinna wrote: I've run indent on flock.c since its formatting was non-GNU. I can understand why you did it in this case (the tabs were out of control), but can we make an exception for bsd/isc-derived code? I think that enforcing this rule strictly on written-from-scratch source is ok, but doing it on derived source reduces the overall transparency of changes against the upstream version. I see. Is that necessary for flock? It's not BSD derived and will not likely need another external update. Oh, I think I was unclear. I was trying to say is that I agree with your formatting changes to the flock code. I just wanted to see if I could have an exception from this policy in certain cases where the source was derived. However, we have a problem here, which I just saw when looking into the flock code another time. The newlib defintion of `struct flock' isn't 64 bit aware and it doesn't adhere to the SUSv3 definition. :-( It uses 'long' as datatypes for l_start and l_len but these should be off_t. So we need to define flock32 and flock64 structs and change the fcntl interface to accept both. Sic. Hmm, I see what you mean. While I've been mulling over the problem, it seems you've already solved it. Thanks for catching that oversight on my part. Cheers, Nicholas
Re: [PATCH]: Add flock syscall emulation
[EMAIL PROTECTED] wrote: On Sun, Nov 30, 2003 at 12:01:04AM +0100, Corinna Vinschen wrote: Is there any reason this can't be a .cc rather than a .c ? I was just following what was done with other pure C source files, such as fnmatch.c. However, I'll make a note to use .cc in the future. Cheers, Nicholas
Re: [PATCH]: Add flock syscall emulation
Corinna wrote: On Thu, Nov 27, 2003 at 02:51:10PM -0500, Nicholas Wourms wrote: Hi All, Here is a patch to add the flock() syscall to Cygwin. I've noticed that some Applied with changes. I've run indent on flock.c since its formatting was non-GNU. I can understand why you did it in this case (the tabs were out of control), but can we make an exception for bsd/isc-derived code? I think that enforcing this rule strictly on written-from-scratch source is ok, but doing it on derived source reduces the overall transparency of changes against the upstream version. Indent in GNU mode will practically rewrite every line in just about any BSD source file out there, since their formatting style is clearly different. I'd argue, however, that the BSD style is just as clear and readable as the GNU style. For instance, because DJ didn't run localtime.cc through indent, resolving the changes in the latest tzdata sources is like 50x easier. I've removed the _DEFUN, since it's nowhere else used in Cygwin. I've added a change message to include/sys/file.h according to the licensing terms in include/sys/copying.dj. The _DEFUN was leftover from when I had been debating about whether to add it to newlib or cygwin, but clearly cygwin was the proper choice. Thanks for catching that DJ licensing thing, though. I removed the _flock from cygwin.din. This should in future really only be used if newlib expects a new syscall. As I said, it was mostly an afterthought. As a side note, I noticed that sys/file.h was from DJGPP. Will DJ allow us to use code from DJGPP in Newlib/Cygwin? If so, I noticed some code in the DJGPP libc which I could port and use in future contributions. This is a question you should ask DJ. AFAIK, DJGPP is GPLd. This would mean that its code isn't suitable for use in Cygwin itself. Ok, I'll ask him, though I find it curious that there is DJGPP libc code in Cygwin despite this. I'll also see if he's interested in the changes I made. Thanks for cleaning it up. Cheers, Nicholas
Re: tin-1.6.2-1 patch to fix charset dotlock issues
Alexey Volkov wrote: Hello everybody. Here is some kind of a [proposed] patch to fix charset(1) and dotlocking(2) issues in the tin-1.6.2-1 [SNIP] diff -urbN tin-1.6.2-1/src/Makefile.in tin-1.6.2-1-patched/src/Makefile.in --- tin-1.6.2-1/src/Makefile.in 2003-08-10 19:27:36.0 +0600 +++ tin-1.6.2-1-patched/src/Makefile.in 2003-11-28 00:20:36.0 +0500 @@ -65,6 +65,9 @@ INTL_LIBS = @INTLLIBS@ PCRE_LIBS = @PCREDIR_LIBS@ @PCREDIR_MAKE@ -L../pcre -lpcre LIBS = $(PCRE_LIBS) $(CANLIB) @LIBS@ @INN_NNTPLIB@ $(INTL_LIBS) +ifeq (@host_os@,cygwin) +LIBS = $(PCRE_LIBS) $(CANLIB) @LIBS@ @INN_NNTPLIB@ $(INTL_LIBS) -lkernel32 Adding -lkernel32 is not necessary because gcc's collect2 automatically passes this as an argument to ld during the link stage when building a native cygwin binary. See the *lib: line after invoking `gcc -dumpspecs` to see the libraries gcc automatically links in. Cheers, Nicholas -- 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: New package: tzcode-2003d-1
[EMAIL PROTECTED] wrote: The package 'tzcode' is now available with the Cygwin distribution. o http://www.twinsun.com/tz/tz-link.htm (Homepage) o ftp://elsie.nci.nih.gov/pub/ (Download location) I know the train has already left the station, but I do have a few nitpicks about the package (other then my earlier ones). Aren't zoneinfo data alternatives supposed to go in /usr/share/zoneinfo/alternative name? Having three zoneinfo dirs in Top-Level /usr/share doesn't seem right and is definitely not FHS compliant. I don't know if this is relevant, but I also noticed that glibc has no leaps dir but it does have a right dir. Is this going to be a problem? I would like to resolve this so that I can submit a patch for zoneinfo.cc and tzfile.h so that they correctly locate the zoneinfo tree and various other files (currently they look in /usr/local/etc/zoneinfo by default). While I'm at it, I also plan to update the code to the latest source provided by this package (since it appears DJ just copied the source from there in the first place). This way, it will save you the trouble of maintaining an additional, unneeded static lib. Plus, it will cut down on the size of the binaries since that static lib contains duplicate code already contained in the dll. Cheers, Nicholas
Re: [PATCH]: Add flock syscall emulation
cgf wrote: On Thu, Nov 27, 2003 at 02:51:10PM -0500, Nicholas Wourms wrote: And, the employee was...? Your reasoning may be correct but it isn't possible to know for sure without details. Chris, Ooops, sorry about that! I meant to fill it in after I finished and had a chance to look up his name, but I guess I forgot. Anyhow, according the the spec's ChangeLog, the author is Nalin Dahyabhai nalin at rh com. This name is also consistant with the RCSId that appears in the header comments of flock.c. Cheers, Nicholas
Re: Bash wait indefinitely
news.gmane.org wrote: I'm running in concurrences 5 complex bash batch, and sometimes (2 times on 3) one or more (very rarely) batch stop to do something. I've put a lot of trace to see where is the problem, but seems rarely arrived at the same line of code. I've also tried to use strace tool, but strace hang rapidly. For the last few weeks I've been experiencing the same, and the offenders always seem to be either bash (not ash) or make. It is important to note that I track cygwin's CVS head, so I had chalked it up to the on-going signal work. I've found that running deep `make`s or running the autotools in succession (such as in the case of triggering the AM_MAINTAINER_MODE routines) often triggers this problem for me on my Dual Athlon MP 2400+ Win2K box :-(. I've been extremely busy working on other things, I just grumble, kill the deadlocked process and its children, then restart the parent. Attempting to debug gdb/strace, as you've discovered, is quite fruitless. Cheers, Nicholas -- 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/
[PATCH]: Add flock syscall emulation
Hi All, Here is a patch to add the flock() syscall to Cygwin. I've noticed that some of our mailer apps are using this syscall and have encountered a number of other apps which do as well. In most cases, they will provide an emulation of flock using fcntl() in the case that flock() is absent from the system's libc. I've also noticed that some Linux distributions, Red Hat in particular, do not trust the Linux kernel's implementation of flock and thus prefer to emulate it in a similar manner. Rather then duplicate the numerous varieties of emulated flock out there, I decided to port this particular version of flock emulation from a patch written by a Red Hat employee for use in Red Hat's IMAPd RPM. I tried contacting the individual listed in the spec's ChangeLog, but got no response. IANAL, but since there was no notice of copyright at the top of the file and since this code was created for Red Hat by a Red Hat employee, I'm assuming that Red Hat owns the rights to this code? This is based on the assumption that Red Hat employees sign a similar copyright assignment to the one that we do. If this isn't so, please let me know and I'll go back to the drawing board. So, I tweaked the code and formatting for use by Cygwin and have updated the sys/file.h header to support the operations provided by this syscall. I based that off of the header from FreeBSD, which also resulted in the other changes. IMHO, I found that the comments and the way in which the alternative whence values were defined in the BSD header seemed to add more clarity. So if there are no objections, I thought I'd add those changes as well. Also, I added an underscore symbol in the case that some program was looking for the BSD syscall. It was mostly done as an after-thought, so feel free to dump that if you are inclined to do so. Lastly, for testing purposes, you can build the flock source as an executable. This is just a very small test to prove basic flock() functionality. I've tested successfully using some of the tests in the LTP. Also, I've been running programs using this implementation for months now, with no adverse side-effects. As a side note, I noticed that sys/file.h was from DJGPP. Will DJ allow us to use code from DJGPP in Newlib/Cygwin? If so, I noticed some code in the DJGPP libc which I could port and use in future contributions. Cheers, Nicholas2003-11-27 Nicholas Wourms [EMAIL PROTECTED] * Makefile.in: (DLL_OFILES): Add flock.o. * cygwin.din: Export flock _flock. * flock.c: New file. * include/sys/file.h: Include sys/cdefs.h. Add function prototype for flock(). Add some comments from BSD's header for further clarity. (L_SET, L_CURR, L_INCR, L_XTND): Redefine as the macros SEEK_SET, SEEK_CUR, SEEK_CUR, SEEK_END respectively. (LOCK_SH,LOCK_EX,LOCK_NB,LOCK_UN): New macros for flock(). * include/cygwin/version.h: Bump API minor number. Index: Makefile.in === RCS file: /cvs/src/src/winsup/cygwin/Makefile.in,v retrieving revision 1.143 diff -u -3 -p -r1.143 Makefile.in --- Makefile.in 27 Oct 2003 13:06:56 - 1.143 +++ Makefile.in 27 Nov 2003 18:42:44 - @@ -126,8 +126,8 @@ DLL_OFILES:=assert.o autoload.o bsdlib.o fhandler_random.o fhandler_raw.o fhandler_registry.o fhandler_serial.o \ fhandler_socket.o fhandler_tape.o fhandler_termios.o \ fhandler_tty.o fhandler_virtual.o fhandler_windows.o \ - fhandler_zero.o fnmatch.o fork.o getopt.o glob.o grp.o heap.o init.o \ - ioctl.o ipc.o iruserok.o localtime.o malloc_wrapper.o miscfuncs.o \ + fhandler_zero.o flock.o fnmatch.o fork.o getopt.o glob.o grp.o heap.o \ + init.o ioctl.o ipc.o iruserok.o localtime.o malloc_wrapper.o miscfuncs.o \ mmap.o msg.o net.o netdb.o ntea.o passwd.o path.o pinfo.o pipe.o \ poll.o pthread.o regcomp.o regerror.o regexec.o regfree.o registry.o \ resource.o scandir.o sched.o sec_acl.o sec_helper.o security.o \ Index: cygwin.din === RCS file: /cvs/src/src/winsup/cygwin/cygwin.din,v retrieving revision 1.104 diff -u -3 -p -r1.104 cygwin.din --- cygwin.din 19 Nov 2003 18:50:20 - 1.104 +++ cygwin.din 27 Nov 2003 18:32:19 - @@ -504,6 +517,8 @@ finitef _finitef = finitef fiprintf _fiprintf = fiprintf +flock +_flock = flock floor _floor = floor floorf Index: flock.c === RCS file: /cvs/src/src/winsup/cygwin/flock.c,v retrieving revision 1.0 diff -u -3 -p -r1.0 flock.c --- flock.c 1970-01-01 01:00:00.0 +0100 +++ flock.c 2003-11-27 13:22:48.0 -0500 @@ -0,0 +1,80 @@ +/* One of many ways to emulate flock() on top of real (good) POSIX locks. + * + * This flock() emulation is based upon source taken from the Red Hat + * implimentation used in their imap-2002d
Possible bug with __attribute__((alias)) in gcc-3.3
Hi All,
Gerrit and I were discussing this off-list, but I thought it appropriate
that I move it to the main list since he has confirmed the problem.
Here's the problem, programs are segfaulting when the are linked to a
symbol which was aliased using __attribute__((alias)) in a dll. Here is
a small testcase:
foo.c:
#include stdio.h
int __foo (void) {
printf(foo\r\n);
return 0;
}
int __attribute__ ((alias(__foo))) foo (void);
bar.c:
#include stdio.h
extern int foo (void);
int main (void) {
foo();
return 0;
}
Then compile as:
gcc -shared -o cygfoo.dll foo.c -Wl,--out-implib=libfoo.dll.a
gcc -o bar.exe bar.c -L. -lfoo
Then run:
./bar
Which should return:
Segmentation fault (core dumped)
Running this same test, modifying the compiler args as needed, on Linux
results in success. Of course, Linux is ELF, so you really can't draw
any strong conclusions from this exercise.
However, Danny's message to the gcc mailing list:
http://gcc.gnu.org/ml/gcc-patches/2003-10/msg01281.html
seems to indicate that __attribute__((alias)) is supposed to work for
32bit PE targets. In fact, Danny's message is about a presumably
unrelated MinGW problem with that same function attribute. Gerrit
says he's going to give the patch in that message a try (I'm low on
space so I can't build a new toolchain) and see if it helps in any way.
What I'd like to know is if this function attribute is supposed to work
on native cygwin targets? If so, is there something wrong with how I'm
going about it? I can only speculate that the auto-import warning I get
might have something do with it? It doesn't seem like a situation where
auto-import ought to be necessary, but I could be wrong.
In case people were curious, my thoughts were to setup faux weak-alias
support for Cygwin by implementing the weak-alias macro glibc uses with
this attribute. The only difference being that there would be no
__attribute__((weak)) and no LD_PRELOAD support, since neither are
currently support for 32bit PE's. However, it would paper over an
aggravating problem caused by elf-centric software. Software which
insists on making global functions as weak references to underscored
functions with other software expecting both symbols to be present in
the shared library. The nice part of this method is that it wouldn't
require inserting nasty ifdefs or fiddling with def files, rather using
a macro which is already present in the offending source.
Cheers,
Nicholas
--
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: [Review 2 - Good to go] gd: A graphics library for fast image creation
[EMAIL PROTECTED] wrote: Gareth == Gareth Pearce [EMAIL PROTECTED] writes: Hmm... just noticed that you have libgd2 and libgd2-devel... I was under the impression that you should stick the DLL version in the libgd package name, which you did, but I thought that the DLL version number was *not* included in the -devel package name. It seems to me that the devel package should be called: libgd-devel Anyone care to comment on this? Gareth It would be nice to say that versioned devels are never necessary, but Gareth unless the internals of the package are designed so as to be able to coexist Gareth with future version devels (like libgd2 would be), there isn't any point Gareth versioning them, and hence should not be so. Volker, I think the best way to determine this is whether or not the package installs versioned includes and static/import libs. Also, the naming of the libraries include dirs is important. In the case of freetype, freetype-1 is libttf whereas freetype2 is libfreetype. Even if it doesn't, it pays to check out the Mandrake/RedHat/Debian packages to see how they are doing it. Sometimes it may be necessary to make a package have co-existing versions, especially in the case of databases where src API's can change, causing some existing sources not to compile/work. Also, it is pretty much a given that most GNOME libraries are going to need to be versioned. The key is to plan ahead now, before you are stuck providing kludges or empty-package work-arounds. Cheers, Nicholas
Re: minires-0.95 - a new package ready for review
[EMAIL PROTECTED] wrote:
On Wed, Nov 19, 2003 at 01:23:05PM -0500, Pierre A. Humblet wrote:
Does linux use a recent bind adding underscores (grep res_query resolv.h)?
Yes.
Does OpenSSH's configure behave OK there? If so, why?
Apparently, on Linux the shared lib libresolve.so defines not only a
text symbol __res_query, it also defines something called a weak
symbol named res_query:
$ nm libresolv.so | grep res_query
6640 T __res_query
6880 T __res_querydomain
6640 W res_query
6880 W res_querydomain
While minres doesn't do the same:
$ nm /usr/lib/libresolv.dll.a | grep res_query
T ___res_querydomain
I __impres_querydomain
T ___res_query
I __impres_query
Does ld on Cygwin support weak symbols? Or is it possible to
define __imp__res_query additionally to __impres_query?
No, the current pe bfd doesn't support the weak attribute. I believe
only elf targets support it at this time (maybe some aout as well?).
However, the kludge I use to get around this is to just do this in the
source file:
#define foo __foo
int
__foo {
}
Or you can use a typedef if your symbol is a struct or similar.
Cheers,
Nicholas
Re: minires-0.95 - a new package ready for review
Pierre Humblet wrote:
Nicholas Wourms wrote:
[snip]
However, the kludge I use to get around this is to just do this in the
source file:
#define foo __foo
int
__foo {
}
Or you can use a typedef if your symbol is a struct or similar.
I am not sure if this addresses the problem at hand.
There IS and include file with #define foo __foo
but configure runs in a problem when it calls foo() without including
said include file. Thus we would like to have both __foo and foo.
Noo, you have to do it in the library source file, not the header,
that way the symbol is properly generated in the library dll. This is
quite similar to the way cygwin.din maps some symbols to underscore
aliases (or visa-versa).
Cheers,
Nicholas
Re: minires-0.95 - a new package ready for review
Pierre Humblet wrote: Corinna Vinschen wrote: [SNIP] Btw, could cygwin use weak symbols instead of newsym? I suspect this would take quite a bit of doing. In addition to being aliases, weak symbols are also supposed to be weak. That is, if locally controlled source redefines the symbol, that local symbol is supposed to override the global one. I think this is really only used in situations such as LD_PRELOAD, where one library's functions are supposed to override the system's libraries without having to relink against that other lib. Cheers, Nicholas
Re: minires-0.95 - a new package ready for review
Pierre Humblet wrote:
Nicholas Wourms wrote:
I am not sure if this addresses the problem at hand.
There IS and include file with #define foo __foo
but configure runs in a problem when it calls foo() without including
said include file. Thus we would like to have both __foo and foo.
Noo, you have to do it in the library source file, not the header,
that way the symbol is properly generated in the library dll. This is
quite similar to the way cygwin.din maps some symbols to underscore
aliases (or visa-versa).
Yep, but the bind people have already done it in the header.
(not sure why).
I could simply add #ifdef __CYGWIN__ to remove that feature.
But then I will loose binary compatibility between versions.
Is there a perfect solution?
Pierre,
Sorry for the noise, I was wrong. I had a brainfart and forgot that ld
doesn't actually export the #define'd symbols in sourcefiles to dlls.
Ironically, this will compile:
int __foo {
printf(foo\r\n);
return 0;
}
int foo __attribute__ ((alias(__foo));
and produce a dll exporting both `__foo` and `foo`.
Unfortunately, however, any exe compiled against it will auto-import
_foo and segfault in crt0 when run :-(. Oh well...
Cheers,
Nicholas
Kudos for Corinna!
Corinna, I just pulled from cvs a few minutes ago, and I was suprised by what came down in the winsup dir. If it hasn't already been said, many thanks for what looks like a huge effort on your part to extend Cygserver's fuctionality. It seems like it might be poised to replace cygipc. Lemme send you 3 virtual beers for a job well done! :-) Cheers, Nicholas -- 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: [Review 1 - No pass] gd: A graphics library for fast image creation
[EMAIL PROTECTED] wrote:
Nicholas Wourms wrote:
[EMAIL PROTECTED] wrote:
Volker,
I tried to build the package and got the following from the prep step:
aclocal: configure.ac: 46: macro `AM_ICONV' not found in library
I have updated all of my packages to the latest curr releases.
Were you setting a non-default PKG_CONFIG_PATH before running the
script? Here is what my env var has:
PKG_CONFIG_PATH=:/usr/X11R6/lib/pkgconfig
Err... PKG_CONFIG_PATH probably has nothing to do with this.
In any case, please advise as to why the build script fails.
Harold,
That error implies aclocal is unable to locate the m4 macro package
containing AM_ICONV. In this instance it refers to a missing gettext
m4 macro in the iconv.m4 file. I haven't checked, but are there any
other .m4's in the src pkg/patch besides {aclocal,acinclude}.m4? If
so, they may be in a subdir, which requires -I subdir be passed to
aclocal (ex. if config/*.m4, `aclocal -I config`).
It is probably easier if you just install gettext-devel, which should
install iconv.m4 into /usr/share/aclocal, which is automatically
scanned by aclocal. However, this file *should* be distributed with
the sources, which is why the earlier procedure is preferred (since
the macros change between gettext releases, bogus or unexpected
results can happen during configure if a newer macro is used for a
package gettextized with an older gettext).
Cheers,
Nicholas
Did you mean to send this to cygwin-apps? It should probably be
public.
Oops, yes. Anyhow, I've come up with a solution so that you don't have
to have gettext-devel by adding the macros to acinclude.m4 (since they
aren't included individually). I'm preparing to send Volker an update
as we speak.
Cheers,
Nicholas
Re: [ITP] tzcode: The time zone package
[EMAIL PROTECTED] wrote: Hi I would like to contribute and maintain the timezone package: * http://www.twinsun.com/tz/tz-link.htm a public-domain time zone database which contains code and data that represent the history of local time for many representative locations around the globe. This package contains the zic time zone compiler, the zdump timezone dump routine, and various timezone library routines. These functions deal with variations in the time zone rules in the world. Actually, cygwin uses most of the library code from the package directly in the dll. So, instead of making a new library, perhaps updating the existing cygwin source files would be the way to go? I'd even go as far to say that the timezone utils (which are very small) ought to also be in the utils distributed with the cygwin dll since this is how it is done with glibc. The tzdata, however, could remain a separate package. Whatever the decision, I think this would make a fine addition. I vote yes. Cheers, Nicholas
Re: Please update links, mod_php4, mod_ssl, wget (was: [mark@openssl.org: [OpenSSL Advisory] Denial of Service in ASN.1 parsing])
[EMAIL PROTECTED] wrote: On Tue, Nov 04, 2003 at 02:40:20PM +0100, Corinna Vinschen wrote: May I again ask the package maintainers of packages, which still use openssl-0.9.6, to update their packages to use openssl-0.9.7? These packages are - linksSami Tikka - mod_php4 Stipe Tolj - mod_ss Stipe Tolj ^^^ - wget Hack Kampbjorn If we don't get a response within a week, then, IMO, maintainership of these packages is up for grabs. Any objections to this? Umm... Stipe's already responded to cygwin-apps regarding these two. He said that new versions would be ready for upload soon. I should think that's sufficient enough response? Cheers, Nicholas
Re: your Cygwin packages need to be updated
[EMAIL PROTECTED] wrote: Daniel Reed wrote: http://cygwin.com/ml/cygwin-apps/2003-11/msg00068.html * From: Corinna Vinschen vinschen at redhat dot com * To: cygwin-apps at cygwin dot com * Date: Tue, 4 Nov 2003 14:40:20 +0100 * Subject: Please update links, mod_php4, mod_ssl, wget (was: [EMAIL PROTECTED]: [OpenSSL Advisory] Denial of Service in ASN.1 parsing]) May I again ask the package maintainers of packages, which still use openssl-0.9.6, to update their packages to use openssl-0.9.7? These packages are - links Sami Tikka - mod_php4 Stipe Tolj - mod_ssStipe Tolj - wget Hack Kampbjorn Stipe, Are you going to update to the newer version of apache-1.3? I also noticed that more things can be #defined since a good deal of new functionality has been added to the dll. Cheers, Nicholas
Re: Should --sysconfdir=/etc/defaults/etc/?
[EMAIL PROTECTED] wrote: On Thu, Oct 30, 2003 at 08:43:31AM -0600, Gary R. Van Sickle wrote: Current packaging instructions at http://cygwin.com/setup.html#package_contents indicate that --sysconfdir should be set to /etc. Should this perhaps be changed to /etc/defaults/etc, with the subsequent instruction that if your package actually has anything in sysconfdir, it should conditionally copy it to /etc if it doesn't already exist with a postinstall script[1]? No. If you set --sysconfdir to something else than /etc, a big bunch of packages will search their config files in the wrong directory. Keep in mind, that the sysconfdir setting might get hardcoded into a tool on compile time. Better create a package script which moves the files from /etc to /etc/defaults/etc after calling `make install DESTDIR=...'. Or even do it by hand. RedHat does `make install DESTDIR=.. sysconfdir=..` for packages where they want the target sysconfdir be something other then the default set at compile time. Cheers, Nicholas
Re: Updated: lesstif-0.93.91-4
Harold L Hunt II wrote: Noted. I am not sure that I can do anything about that. Doesn't seem like it would be worth looking into at the moment. I would gladly accept a tip or patch from anyone. I don't know how, but I think this is my fault. I modified the install script to bzip the manpages, but that should happen *after* the make install portion. And, yes, I did turn on fontconfig support, and I'm not the least bit ashamed to admit it. It was badly needed IMNSHO. For those who want to know, here's a real easy way to make sure your apps get built right: CFLAGS/CXXFLAGS=`pkg-config --cflags xft` LDFLAGS=`pkg-config --libs xft` But most libtool apps will get the depends right anyhow. If someone *really* wanted to get artsy-craftsy, they could make a package-config file for lesstif, which would ensure all the correct libs were used. Cheers, Nicholas
Re: Add PAGE_SIZE, PAGE_SHIFT, PAGE_MASK to sys/param.h
[EMAIL PROTECTED] wrote: [SNIP] 2003-10-28 Nicholas Wourms [EMAIL PROTECTED] * include/sys/param.h: Define some page counting macros. (PAGE_SHIFT): Define. (PAGE_SIZE): Define. (PAGE_MASK): Define. Tidy tab/whitespace formatting from last patch. Sorry, but I have several problems with this patch: - The formatting of the ChangeLog entry (no TABS). That proves my later concerns, as I did put TABS in the ChangeLog entry. Unfortunately, this was a bug in Mozilla about the time NS-7.1 was released against that code base (Those on the LKML will recall the problems ppl had with Mozilla stripping tabs). See my later comments on this. - The ChangeLog and your above description are missing the fact, that you also added a NBPW definition. D'oh, sorry I forgot about that one. - The definition of PAGE_MASK is... a problem. Your definition is the BSD definition (PAGE_SIZE-1), while Linux defines it as the negation thereof, (~(PAGE_SIZE-1)). I don't know what way to follow here. I guess it's all one, considering that we don't use it in Cygwin so far. While we once decided that, if SUSv3 fails to lend us a hand, we would try to map the Linux behaviour, the sys/param.h file is a header for mostly BSD definitions. I know, but I couldn't find this defined like that in any other OS. I felt guilty enough by casting the bitvector, I was worried about be accused of stealing GPL'ed code. Thus I thought it better to stick with the BSD definition. Interestingly enough, Wine's `memory/virtual.c' has `PAGE_SHIFT' defined to `12' and PAGE_MASK defined to 0xfff or 4095 (4096-1). log2(4096) gives a float answer of 12. Also Doug Lea's malloc defines PAGE_MASK as (PAGE_SIZE-1) and then negates it where necessary. OTOH, I found that dlltool from binutils-2.7 used to define it as a negation. Since you are more of an expert on mmap then I, I'll leave it others to decide. If you want to leave it out for now, that would be ok, too. Primarily, I was after PAGE_SHIFT PAGE_SIZE but decided to add PAGE_MASK since it was clustered with the others in all the headers I looked at. - Neither BSD nor Linux define these highly machine dependent values in sys/param.h. What about adding a asm/param.h file and include that in sys/param.h? I wasn't sure what to do, so if you think asm/param.h is better, that will be fine. Of course bsd/linux has it in a machine dependent asm dirs, so now that I think about it that would make sense. - Don't attach gzipped patches, please. Mozilla doesn't scramble text attachments, AFAIK. Unfortunately, as stated previously, it seems that NS-7.1 does. I have to use this to read my netscape mail if I don't want to use the web interface. However, I'll resend the patch with your suggested improvements using pine to see if that works. Cheers, Nicholas
Add PAGE_SIZE, PAGE_SHIFT, PAGE_MASK to sys/param.h
Hi, I'm not sure how this would be taken... The only problem I see in doing this is if we ever decided to start supporting ia64/x86_64. However, at that point we'd have to change a *ton* of other machine-dependant macros as well, so it seems like a rather trivial addition. These macros seem to be fairly standard in both the linux and bsd worlds, so it would be very beneficial if we went ahead and defined them. The reason I would like them is merely as a convienience factor in some socket work I'm doing. I'm assuming that the windows default page shift, 12[*], will be an acceptable value that we can agree on? This macro defines the base value upon which the aother macros calculate their values. Based on that, I have attached a patch with those macros defined and some whitespace/tab cleanup cause by my last patch. Because I'm not sure about my MUA, I've gzipped the patch to preserve formatting. Cheers, Nicholas * This is the same value used by Linux/ia32, *BSD/ia32, Wine, and the Windows DDK in the cvs repo. 2003-10-28 Nicholas Wourms [EMAIL PROTECTED] * include/sys/param.h: Define some page counting macros. (PAGE_SHIFT): Define. (PAGE_SIZE): Define. (PAGE_MASK): Define. Tidy tab/whitespace formatting from last patch. cygwin-page-macros.patch.txt.gz Description: GNU Zip compressed data
Re: Patch to generic-build-script for listing package files
[EMAIL PROTECTED] wrote:
}
+list() {
+ (cd ${instdir} \
+ find . -name * ! -type d | sed 's/\.\/\(.*\)/\1/' )
+}
pkg() {
(cd ${instdir} \
tar cvjf ${bin_pkg} * )
@@ -173,6 +177,7 @@
check) check ; STATUS=$? ;;
clean) clean ; STATUS=$? ;;
install) install ; STATUS=$? ;;
+ list)list ; STATUS=$? ;;
strip) strip ; STATUS=$? ;;
package) pkg ; STATUS=$? ;;
pkg) pkg ; STATUS=$? ;;
What about find . -type f -o -type l? This is what I use along with a
similar sed script.
Cheers,
Nicholas
Re: Question about gcc-mingw package renaming
[EMAIL PROTECTED] wrote: [SNIP] See above. I think that's an it depends. If I was looking for gcc and knew about mingw, I might expect to find a gcc-mingw package. No argument here. But along the same lines, mingw-zib should probably be changed to zlib-mingw. Cheers, Nicholas
Re: fltk-1.1.4-1: take 2
censored wrote: SNIP Nicolas wrote: First off, you have /usr/share/doc/fltk /usr/share/doc/fltk-1.1.4. Done Second, where are the include files? Building fltk apps will definitely need those. yep, included now Third, you can ditch /etc/postinstall since you aren't using a script. Done On the subject of shared libraries Nicholas wrote: Not really, you could always cheat by using the --whole-archive method of converting a static archive into a dll. i.e.: I used this method to add dlls and import libraries. Nicholas also made some (optional) suggestions about an xpm -nox like lay-out in anticipation of a future parallel xfree86 version. I think these are good suggestions, but for the time being I'd like to leave it in the current form. I suppose this is ok, as long as we can negotiate renaming the exe's and relocating the include/libraries out of the deafult search dirs when the X11 port is to be included. Looks good otherwise... Cheers, Nicholas
Re: Updated Berkeley DB to 4.1.25, please upload
[EMAIL PROTECTED] wrote: Hallo, I have updated the Sleepycat Berkeley DB to the latest release which is 4.1.25. To continue what was started once, please put db4.1 in its own subdirectory under release/db/db4.1/. Thanks for doing this Gerrit. Did you include the post-install scripts? (I don't want to eat up all your bandwidth just to check). Cheers, Nicholas
inetutils packaging problem
Corinna,
In the inetutils -25 package which just showed up on ftp, your tarball
contains paths with .\ prefixes. I suspect that your source
argument for tar was a . instead of *. Unfortunately setup doesn't
handle this case right for cygwin-style bind mounts and ends up
putting contents intended for /usr/{bin,lib} in C:\Cygwin\usr\{bin,lib}
instead of properly mapping /usr/{bin,lib} to C:\Cygwin\{bin,lib}.
Cheers,
Nicholas
P.S. - I'll take a look at what Gerrit's got so far, but it should
probably be ok.
Re: ncurses, call for assistance
[EMAIL PROTECTED] wrote: On Wed, 3 Sep 2003, Charles Wilson wrote: Are you sure you didn't use .gz back then? ;-) Try ftp://ftp.ics.kiev.ua/pub/mirror/sourceware.cygnus.com/pub/cygwin/contrib/ncurses/ncurses-5.2-1-src.tar.gz. Igor Three cheers for the Ukrainians! Cheers, Nicholas
Re: [ITP] lftp
[EMAIL PROTECTED] wrote: On Sat, 23 Aug 2003, Igor Pechtchanski wrote: Another *very* minor issue -- empty directories (etc/postinstall and usr/lib/lftp/2.6.6). They don't hurt, but I couldn't find the purpose of usr/lib/lftp/2.6.6 anywhere in the documentation. Igor, That directory holds the various shared protocol modules which are dlopened as needed, should you build lftp that way. In other words, it serves the same purpose as /usr/lib/apache does for httpd. However, I'm assuming he built the lftp protocol modules static, thus leaving the module dir empty. As a side note, it is possible to build lftp on Cygwin with shared protocol modules (I've done so myself). However, it requires a lot of ugly hacking to the autotool stuff. If the maintainer is interested, I can send him my modifications. Cheers, Nicholas
Re: a2ps compile problem against 1.5.2
[EMAIL PROTECTED] wrote: On Mon, Aug 18, 2003 at 12:05:39PM -0400, Christopher Faylor wrote: On Mon, Aug 18, 2003 at 11:00:22AM -0500, Robert McNulty Junior wrote: I had the same problem. My solution was to get rid of -lm.\ This is not a solution. It is a workaround. Ok. I see the problem. I'm still puzzling over how to fix it. I think it is arguably a bug in ld but that's really not a big help to know. I have to fix it either way. Perhaps a refresh of the latest binutils against 1.5.2 might be a good idea anyways. Ditto for gcc. Cheers, Nicholas
Questions and a RFC [was Re: Assignment from Nicholas Wourms arrived]
[EMAIL PROTECTED] wrote:
FYI,
your copyright assignment form has been received by Red Hat. Patch away!
Any outstanding issues besides argz/envz?
Not yet, I've got a few things I'd like to contribute to newlib first.
However, I do have a few questions...
1)Did my MUA strip the tabs from the patch? The only reason I ask is
because I had formatted the code with tabs and now it looks like they
were all converted to spaces. [BTW, sorry about NBBY, I had been
meaning to send a follow up since I realized that I forgot that I had it
globally defined in another header :-(].
2)I assume that my assignment covers me for Newlib contributions?
3)I'm still trying to figure out how to use lstat in newlib source code,
since apparently the function declaration is hidden when building
newlib/cygwin. So far, any attempt to use it results in undefined
references to _lstat when linking the dll. I tried adding a definition
to _syslist.h, but that didn't work. I hate to sound clueless, but if
someone could nudge me toward the right header or magic, that would be
great.
4)Corinna, I've been working on porting some of the missing
SUSv3/c99/bsd functions from the *bsd libc. I noticed that the libutil
which you distribute with inetutils contains some of the functions I
thought belonged in libc, or at least the headers of newlib would have
me believe this. Specifically, I was wanted to work on adding instances of:
endusershell()
setusershell()
getusershell()
ruserok()
iruserok()
Why would I want to do this you ask? Well some of the specific
implementations of the other code I'm tying to port use these functions.
I suppose I could just use internal, static versions, but these
functions really ought to be reusable and in sync with the global
header. Do you have any objections to this, provided you find my code
sound?
5)This is meant as a general RFC based on something I noticed while
researching the freebsd libc.
What would people think about adding another member to the FILE
structure which would allow for future additions without
incompatibilities? I noticed that freebsd has addressed their growing
FILE ABI by using adding a new member struct, *_extra, to allow for
additional members without causing incompatibilities. As I was working
on porting fwide(), I ran across this feature in freebsd. Here's how
it's done:
In the public header, stdio.h:
--
struct __sFILEX;
...
typedef struct __sFILE {
...
int (*_write)(void *, const char *, int);
/* separate buffer for long sequences of ungetc() */
struct __sbuf _ub; /*ungetc buffer */
struct __sFILEX *_extra; /*additions to FILE to not break ABI*/
int _ur;/*saved _r when _r is counting ungetc*/
...
};
--
Then from private header, local.h, located in the stdio/ dir:
-
struct __sFILEX {
unsigned char *_up; /*saved _p when _p is doing ungetc data*/
pthread_mutex_t fl_mutex; /* used for MT-safety */
pthread_t fl_owner; /* current owner */
int fl_count; /* recursive lock count */
int orientation;/* orientation for fwide() */
#ifdef notdef
/*
* XXX These are not used yet -- they will be used to store the
* multibyte conversion state for writing and reading when
* stateful encodings are supported by the locale framework.
*/
mbstate_t wstate; /* write conversion state */
mbstate_t rstate; /* read conversion state */
#endif
};
-
Planning ahead for future possibilities is always a good thing, so in
that respect this seems like a sound idea. Since we are already dealing
with ABI breakage, I thought I'd float this now to see what people
think. Would a change like this be of benefit to Cygwin?
Cheers,
Nicholas
[PATCH]: Add some interoperability macros to sys/param.h
Hi, This patch adds 11 new macros to Cygwin's sys/param.h. They include: setbit(a,i) clrbit(a,i) isset(a,i) isclr(a,i) howmany(x, y) rounddown(x, y) roundup(x, y) roundup2(x, y) powerof2(x) MIN(a,b) MAX(a,b) I find some to be very useful for many mundane routines (esp. MIN/MAX). It should be noted that I chose to add all 11 of them (as opposed to just the ones I use) because this subset of macros seems to be common across all *bsd and linux distributions. In doing so we improve our interoperability and make porting easier. Although I peeked at the param.h header on my linux box to see if they were all defined, the macros I used were copied verbatim from the freebsd cvs src/sys/sys/param.h. Furthermore, I didn't actually check the definition expression in the linux header, so I feel confident that I have violated no licenses. I have an assignment pending, but I was hoping this change would be small enough to go in before then. Cheers, Nicholas 2003-08-07 Nicholas Wourms [EMAIL PROTECTED] * include/sys/param.h (setbit): Add new bitmap related macro. (clrbit): Likewise. (isset): Likewise. (isclr): Likewise. (howmany): Add new counting/rounding macro. (rounddown): Likewise. (roundup): Likewise. (roundup2): Likewise. (powerof2): Likewise (MIN): Add macro for calculating min. (MAX): Add macro for calculating max. Index: cygwin/include/sys/param.h === RCS file: /cvs/src/src/winsup/cygwin/include/sys/param.h,v retrieving revision 1.2 diff -u -3 -p -r1.2 param.h --- cygwin/include/sys/param.h 30 May 2003 08:39:02 - 1.2 +++ cygwin/include/sys/param.h 7 Aug 2003 17:03:14 - @@ -53,4 +53,23 @@ #define NULL0L #endif +/* Bit map related macros. */ +#definesetbit(a,i) ((a)[(i)/NBBY] |= 1((i)%NBBY)) +#defineclrbit(a,i) ((a)[(i)/NBBY] = ~(1((i)%NBBY))) +#defineisset(a,i) ((a)[(i)/NBBY] (1((i)%NBBY))) +#defineisclr(a,i) (((a)[(i)/NBBY] (1((i)%NBBY))) == 0) + +/* Macros for counting and rounding. */ +#ifndef howmany +#definehowmany(x, y) (((x)+((y)-1))/(y)) +#endif +#definerounddown(x, y) (((x)/(y))*(y)) +#defineroundup(x, y) x)+((y)-1))/(y))*(y)) /* to any y */ +#defineroundup2(x, y) (((x)+((y)-1))(~((y)-1))) /* if y is powers of two */ +#define powerof2(x)x)-1)(x))==0) + +/* Macros for min/max. */ +#defineMIN(a,b)(((a)(b))?(a):(b)) +#defineMAX(a,b)(((a)(b))?(a):(b)) +
Re: Questions and a RFC [was Re: Assignment from Nicholas Wourmsarrived]
[EMAIL PROTECTED] wrote: Nicholas Wourms wrote: Planning ahead for future possibilities is always a good thing, so in that respect this seems like a sound idea. Since we are already dealing with ABI breakage, I thought I'd float this now to see what people think. Would a change like this be of benefit to Cygwin? Hell no. I am irrevocably and unalterably opposed to implementing this change before 1.5.2 goes gold. We've already had THREE ABI breakages in the last month. Now, you want to add another one -- to avoid one in the future. Here's an idea: lets wait until the NEXT scheduled ABI breakage to do yours; then we'll get two for the price of one. Right now, cygwin-1.5.x is overdue by several months. It NEEDS to go out the door; we can continually add more ABI breakages forever and never release a new version...but that's rather silly IMO. That's perfectly fine with me, you point is well made. Cheers, Nicholas
Re: perl -MCPAN -e shell crashes w98se
Steve Coleman wrote: Graham Lamont wrote: perl -MCPAN -e shell Anybody experience similar ? I've been having problems with the latest version of Perl (5.8.0-3) while running/installing from CPAN on WinME. Using the previous version (5.6.1-2) seems to work fine for me when installing from CPAN. I'm not sure about what is causing your problems but mine were from dll's having errors, and 'rebaseall' did not seem to help any. I just reverted to the older version until someone can figure this out or a new version comes out with the 64 bit stuff. If I find the time I will try building perl myself and look into this further, unfortunately my WinME system is 'remote' and one 'hang' means try again tomorrow You can message me off line if there are any specific questions on this. Steve, You might want to give Gerrit's 5.8.1-RC4 a try, it *seems* to be working better then 5.8.0. It still freezes when building some modules, but at least automake/autoheader/autoupdate work. Also, it now seem to not freeze gdb anymore, so executing a perl command should allow you to trace. However, wait until he announces the new version which has a few bug fixes. Cheers, Nicholas -- 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/
inittypes.h
I asked this off list, but I really should be asking it on list. Posted here for the archives and if anyone cares to comment. Cheers, Nicholas [EMAIL PROTECTED] wrote: On Wed, Aug 13, 2003 at 07:44:43PM -0400, Nicholas Wourms wrote: Corinna, I can't really find any history on inttypes.h, but I noticed that you were the one who committed it to cvs. I would like to know how you derived the values for the macros. One of the widechar functions I've been working on uses the handy function, strtoimax... so subsequently I did a port for it and the other inttypes it as well. During this process, I noticed that there seems to be a disconnect between how you've defined some of the 32bit macros and how i386 glibc/mingw/bsd have defined them. For example, looking at int32_t(PRId32): The bsd's: d Glibc: d MingW: d Cygwin: ld Am I missing something here? I searched the archives, w/o any luck. But before I submit an rfc to the main list (not to have it go in, just to get people to test), I need to know if the macros are accurate. Being that these functions are heavily asm dependant, I assume that winsup/cygwin is the most appropriate place to dump 'em? I don't understand the problem. ld is as correct as d for 32 bit int types. I didn't use any foreign source to create the macros but only the description in SUSv3: http://www.opengroup.org/onlinepubs/007904975/basedefs/inttypes.h.html -- 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: ftw()
Christopher Faylor wrote: On Tue, Aug 05, 2003 at 10:37:53PM -0400, Samuel Thibault wrote: Le lun 04 ao? 2003 20:05:45 GMT, Nicholas Wourms a tapot? sur son clavier : That being said, My suggestion to Samuel would be to investigate the FreeBSD cvs repo to see if they have implimented ftw() in their libc, since they have a more free license and aren't GPL-infected. It seems to be still worked on, and not available in their cvs :/ What is with the selective reading style in this thread? Not caring, maybe I was cranky... I saw that a referenced LGPL license is unacceptable for cygwin. Gerrit responds with a pointer to a BSD licensed version. Asks if it is acceptable. I say probably but you'd have to ask the newlib mailing list. Nicholas responds eight hours after this interchange. He opines that I probably don't know about the Red Hat employees who run the glibc project and offers that somebody should find a BSD licensed version of ftw. My point was that it wouldn't hurt to ask. I'm well aware that you know who these people are. Now, a day later, we find that Gerrit's email has again been ignored and the Wourms plan is unworkable. I saw his email, but that version looked more like a kludge then anything else. When I mentioned FBSD, it was because their C99/SUSv3 standards page indicated they had a working verion being developed. Obviously, this version is being worked on privately. IMHO, the correct way to do it is the OBSD way, by making ftw a wrapper around fts. Although not currently a set standard in the scope of the SUSv3, fts was supposed to have been adopted. Apparently, they can't come to any consensus @ the Austin group to get it ratified, so it seems to have been put in permanent limbo. Since Gerrit suggested using OpenBSD in his follow up, I decided to go that route. Anyhow, I've been working on it over the last couple of days, and I've almost got it compiling. There will still be some issues, since the BSD opendir2 implimentation is more robust, thus leaving some missing macros and structs which need to be worked around. I'll post a patch later if people are curious or want to help out. Currently, I'm stuck with an undefined reference to _lstat error, which makes very little sense since I have it defined in _syslist.h, but it still gives me the same undefined error when linking the dll. I also have an update for my param.h patch, as I forgot to add the global definition for NBBY. Cheers, Nicholas -- 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/
Typo [guile-devel-1.6.4-11]: guile-config compile returns a bogusinclude directory
Hi Jan, Just thought I'd alert you to the fact that `guile-config compile` returns a bogus include dir (it uses the dir you passed to mknetrel). While not an overt bug, this could cause trouble if, for example, a configure script tried to check to see if this dir actually existed. Cheers, Nicholas P.S. - I've been meaning to ask, how about a Cygwin port of yodel? -- 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/
