Re: naim review (was Re: Pending package status (14 Jul 2003))
I noticed that the release directory from mirrors.rcn.net is empty just now. Earnie. Daniel Reed wrote: On 2003-07-16T09:31+0100, Max Bowsher wrote: ) Daniel Reed wrote: ) Any headway on this? I see naim's version listed as 0.11.5.9-cyg1-1 now, ) still get the same behaviour. Off the top of my head, I'm wondering if the ) symlinks in the tarball could be confusing something. If I try ftp://mirrors.rcn.net/ now, when it gets to the Downloading... stage it immediately displays a dialog box stating Download Incomplete. Try again? If I try a mirror like ftp://archive.progeny.com/, I still have the Nothing needed to be installed message.
Re: [PATCH] Setup: Fix erroneous quoting of __LINE__ and __FILE__
Christopher Faylor wrote: On Fri, Jul 11, 2003 at 09:23:06PM -0400, Igor Pechtchanski wrote: If you want them, fill out the form at http://sources.redhat.com/ and use 'cygwin-apps' for the project. cgf I can commit to cygrunsrv under cygwin-apps. Does that mean I have commit rights to the whole of cygwin-apps? Yes. It's one category on sources.redhat.com. Sorry. I should have remembered that you already had login access. Have you thought about using cvs_acls.pl to control who has update rights to which modules? Earnie.
Re: [UPDATE] Pending package status (11 Jul 2003)
Christopher Faylor wrote: On Fri, Jul 11, 2003 at 02:23:16PM -0400, Nicholas Wourms wrote: [EMAIL PROTECTED] wrote: I think it would make sense for there to be a limitation on how long a package exists in this table with no votes. I think that after two months of no votes the package should fall off the list. I respectfully disagree, especially now that we have someone who is actively tracking them. What's the harm? An ever growing package list containing packages that no one wants. And that list should be documented so that someone else doesn't try porting it. Perhaps should be moved to a short list at the bottom, and documented on the apps web page? Earnie.
Re: minires-0.95 - a new package ready for review
Corinna Vinschen wrote: On Thu, Jun 12, 2003 at 01:20:21PM -0400, Pierre A. Humblet wrote: Corinna Vinschen wrote: It works on my antique Win95 and on my CYGWIN_NT-4.0. There the Windows functions return an error and minires falls back to resolv.conf Of course LoadLibrary/GetProcAddres would work too. Personally I think it's cleaner to use LoadLibrary/GetProcAddress. But if it doesn't hurt... FWIW, I agree. Most likely the function resolution is faster using LoadLibrary/GetProcAddress as well; but, that is only speculative. Earnie.
Re: Repairing erroneous move of setup-200303 branch tag
Robert Collins wrote: No, I used: $ cvs -z4 tag -Fb setup-200303 in a setup-200303-troubleshooting working dir. Which intuitively says ...? This should not have updated the cvs repository. It would have been commits at a later date that would have updated the repository. The ``tag'' updates the working directory with the ``rtag'' updates the cvs repository with the tag. Earnie.
Re: Make a snapshot with set_default_sec disabled?
Pavel Tsekov wrote: What about a setup which has debugging information in it. So one can use Dr. Mingw to get a useful stack trace. Installing Dr. Mingw is not hard at all. You can get it and other utilities in http://prdownloads.sf.net/mingw/mingw-utils-0.2.tar.gz Earnie.
Re: Make a snapshot with set_default_sec disabled?
Max Bowsher wrote: (Before I had to reinstall, and can no-longer reproduce) Oh, so it's the reboot to correct the issue method that is the solution! ;) Earnie.
Re: setup (ini.cc) vs CVS mingw-runtime
Robert Collins wrote: On Mon, 2003-03-31 at 20:01, Max Bowsher wrote: However, the redefinition of fprintf in ini.cc, is as far as I can see, totally unused, and can be removed. Robert: Can you confirm this, and approve me to delete it from ini.cc ? Well, fprintf *is* used in setup. The fprintf in ini.cc is used to pop fprintf(stderr, ...) into a messagebox. And, fprintf (stderr, ...) is used in setup. Ergo, this will be a problem when the next mingw-runtime comes out. Danny, if you have a patch for either mingw or setup, that'd be great. Does what you are suggesting impose any limitations on setup ? There would be no limitation to setup, it would just be slightly slower in performance. To build a snap release of mingw-runtime, just issue ``make snapshot'' in the winsup/mingw build directory and a snapshot tarball will be created. Earnie.
Re: setup (ini.cc) vs CVS mingw-runtime
Max Bowsher wrote: I confirm your ICE. Did you try -mno-fun-dllimport? Earnie.
Re: Bin/Src checkboxes in setup.exe
Charles Wilson wrote: Christopher Faylor wrote: Or even a separate Sources category... I like this... I don't particularly. Something along the lines of a directory tree structure would be nice though. + foo + bar The user clicks the + foo and gets - foo + foo-1.0-1.tar.bz2 + foo-1.0-1-src.tar.bz2 + foo-1.1-1.tar.bz2 + foo-1.1-1-src.tar.bz2 + bar The user can then choose just which to [] download, [] install, [] uninstall Earnie.
Re: Pending packages status (10 Mar 2003)
Max Bowsher wrote: Volker Quetschke wrote: Hi! 1. grace date : 25 Nov 2002 version: 5.1.12-1 status : updated package available for review notes : http://www.cygwin.com/ml/cygwin-apps/2002-11/msg00322.html reviews: http://www.cygwin.com/ml/cygwin-apps/2003-03/msg00254.html votes : 2 (Lapo and Robert) url: http://www.scytek.de/cygwin/grace-5.1.12-1.tar.bz2 http://www.scytek.de/cygwin/grace-5.1.12-1-src.tar.bz2 http://www.scytek.de/cygwin/setup.hint Max did a review in: ~ http://cygwin.com/ml/cygwin-apps/2003-03/msg00267.html and all proposed changes are applied to the packages at the url mentioned above. OK, I've completed the review I began there. I have the following notes: - The warning about gracerc and gracerc.user being overwritten on reinstall is in the README. I'm not sure very many people will read that. I suggest putting it in the comments actually in the files themselves. IIRC, this is a major flaw. Package configuration files are to not be overwritten upon reinstall. You need to use postinstall scripts to install initial configuration files and not overwrite exsiting configuration files. - You could do change doc to /usr/grace/doc in the README file. This would make it more clear to grace newbies where to find the installed documentation. Uhm, you mean /usr/doc/grace or do you mean /usr/doc/Cygwin/grace.README? Neither of these are critical - the current packages could be released as-is - but both of the above are minor improvements that should be considered. Not following these conventions are critical IMNSHO. Earnie.
Re: someone to take over cURL maintenance?
Max Bowsher wrote: curl-7.10.3 uses libtool-1.4.2 - I'm not surprised it didn't manage to make a DLL. The on the horizon 1.5.0 release of libtool will handle building both shared and static versions of the libraries appropriately. Earnie.
Re: Unusual request: get bison 1.35 back as prev version
Volker Quetschke wrote: Hi! (This request is directed to the bison maintainer, propably Christopher) The reason why I would like to get back access to the old bison 1.35 version is, that it is a prerequisite for the build of OpenOffice 1.0.2. And you're uncapable of building this version from source? Earnie.
Re: nfs-server - status request for information
Robb, Sam wrote: A workaround is to create a regular directory, mount the Windows drive at that directory, and then export the directory. For example: $ mkdir -p /exports/c $ mount -f -s -b c:/ /exports/c $ echo /exports/c (ro,all_squash) /etc/exports Would another possible workaround be just a simple ``mkdir -p /cygdrive/c/cygwin/cygdrive/c'' (this assumes cygwin is installed in c:\cygwin)? Earnie.
Re: nfs-server - status request for information
Christopher Faylor wrote: On Tue, Jan 21, 2003 at 07:39:26AM -0500, Earnie Boyd wrote: Robb, Sam wrote: A workaround is to create a regular directory, mount the Windows drive at that directory, and then export the directory. For example: $ mkdir -p /exports/c $ mount -f -s -b c:/ /exports/c $ echo /exports/c (ro,all_squash) /etc/exports Would another possible workaround be just a simple ``mkdir -p /cygdrive/c/cygwin/cygdrive/c'' (this assumes cygwin is installed in c:\cygwin)? I'd actually appreciate it if someone would actually fix the problem in cygwin rather than providing workarounds. But workarounds are useful until then. My suggestion, if it works, will avoid adding an entry into the mount table. Earnie.
Re: Building /etc/passwd from setup.exe
No, I was using cached profile. There is no Domain Controller available. John Morrison wrote: Sorry for going back to this, Earnie, are you logg'ed into a domain to give the information below? Thanks, J. From: Earnie Boyd Question: have you a known situation where $USERDOMAIN != hostname and you weren't logged into a domain? BoydE@DU216771 ~ $ hostname du216771 BoydE@DU216771 ~ $ echo $USERDOMAIN LCI BoydE@DU216771 ~ $ type hostname hostname is hashed (/c/WINNT/system32/hostname) BoydE@DU216771 ~ $ echo $HOSTNAME DU216771
Re: Setup vertical scrollbar doesn't display
Max Bowsher wrote: There is no other way. (Well, of course, it is possible, but please trust me - it's too complicated.) Too complicated!?!? What's complicated about using tar in the root ``/'' directory? Oh, yea, it's the meta package control that can't be easily duplicated. The postinstall scripts would need to be manually executed. The setup control data would need to be populated; but, if you don't use setup to upgrade that shouldn't matter. Other, automagical stuff that is executed by setup would be ignored or even unknown. Making statements that give the impression of ``you really don't want to understand what setup does'' is just asking to have you explain what setup does that can't be done manually. ;) Earnie.
Re: cmake and emacs package updates announcements
Pavel Tsekov wrote: Sorry, for the noise. This seems to be some strange kind of spam. They have two seperate message headers Received: (qmail 4935 invoked from network); 17 Dec 2002 12:53:14 - Message-ID: [EMAIL PROTECTED] Received: (qmail 27022 invoked from network); 17 Dec 2002 16:34:05 - Date: Tue, 17 Dec 2002 12:40:26 -0500 Message-Id: [EMAIL PROTECTED] It appears that one message routed through two smtp? Earnie.
Re: cmake and emacs package updates announcements
Christopher Faylor wrote: On Tue, Dec 17, 2002 at 08:38:48PM +0100, Pavel Tsekov wrote: Sorry, for the noise. This seems to be some strange kind of spam. Hmm. Let me check the cygwin-announce subscriber list... Do you, by any chance, have either of the two original messages, Pavel? I'd like to check the headers but I deleted them. The pieces of the headers I posted were the only differences. Earnie.
Re: /tmp
Christopher Faylor wrote: On Mon, Dec 09, 2002 at 01:53:43PM -0500, Earnie Boyd wrote: Wrong list, redirected. Please remove [EMAIL PROTECTED] from the distribution when responding. Jim wrote: Would be really really nice if /tmp existed as a link that a directory /tmp weren't created after running setup... Actually since this is a setup design issue, I think this is the right list. Sorry, I was going on the fact that this was a desire and not a discussion of setup or a proposal on correcting the issue with a desire to help fix it, that this was the wrong list. Earnie.
Re: /tmp
Matthew Smith wrote: I assume you mean as a link to a windows temp directory somewhere. However, what if that gets changed by someone? Suddenly a lot of stuff starts breaking, and people start posting here asking why application foo isn't working. The majority of the people are fine with a hardwired /tmp directory. If you're not, make the symlink yourself. His request was to _not_delete_a_symlink_he_made_himself and replace it with a directory named /tmp. Earnie.
Re: /tmp
Wrong list, redirected. Please remove [EMAIL PROTECTED] from the distribution when responding. Jim wrote: Would be really really nice if /tmp existed as a link that a directory /tmp weren't created after running setup...
Re: Building /etc/passwd from setup.exe
Pierre A. Humblet wrote:
# if USERDOMAIN isn't empty and
#USERDOMAIN isn't the hostname then we are in a domain
if [ ! -z $USERDOMAIN ] [ $USERDOMAIN != `hostname` ] ; then
# domain user
type=-d
fi
# Should we append rather than replace?
if [ ! -e /etc/passwd ] ; then
/bin/mkpasswd ${type} /etc/passwd
fi
if [ ! -e /etc/group ] ; then
/bin/mkgroup ${type} /etc/group
fi
**
That file has no effect if it runs after passwd-grp.bat, because
then the passwd file already exists. I have observed that order,
I don't know if it's deterministic.
So that's why domain users are not included, and why they are included
if they delete /etc/passwd and rerun /etc/postinstall/passwd-grp.sh.done
after setup, as has been suggested on the list.
This ``$type'' should only poll for the current user in the domain. I
and my company would be very upset if I polled for 10's of thousands of
users.
Earnie.
Re: cygwin apache https fork error - need rebase cmd info
Wrong list, redirected. Please remove [EMAIL PROTECTED] from the distribution in your responses. [EMAIL PROTECTED] wrote: Greetings, When I try to start Apache with the httpd.conf file configured for both http https, I receive the following error after the command: $ ./apachectl start C:\cygwin\usr\sbin\httpd.exe: *** unable to remap C:\cygwin\bin\cygssl.dll to same address as parent(0xB1) != 0xB2 ./apachectl start: httpd could not be started Hopefully there is a rebase command to fix this problem? Please send me info to resolve this issue if possible! Thxs! I am running the following apps with no problems telnet, ftp, http and here are the installed software and hardware being used: Cygwin 1.3.16-1 Apache 1.3.24-5 Apache-mod_ssl 2.8.8-1.3.24-1 Microsoft Windows 2000 Server OS, Service Pack 3 IBM x-Server 330 Regards, Paul R1-408-927-2731 [EMAIL PROTECTED]
Re: Request approval to add stuff to .cvsignores
Max Bowsher wrote: D zlib/autom4te.cache M zlib/configure These should be kept in CVS. zlib, like the setup root, is kept ready-to-go. You are correct. CVS won't actually ignore configure, even if it *is* in .cvsignore, because it is under version control. autom4te.cache isn't though, so I would like to add that (but not configure). The autom4te.cache should _never_ go to CVS. It contains data about the autoconf users system and could cause false positives and false negatives for a different maintainer. Earnie.
Re: [patch] Help Option
Max Bowsher wrote:
Earnie Boyd [EMAIL PROTECTED] wrote:
That depends on how it's coded. The -mwindows switch alone doesn't
cause the abscense of stdio.
foo.c
#include stdlib.h
#include stdio.h
#include windows.h
int WINAPI WinMain (
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpszCmdParm,
int nCmdShow
)
{
printf(stdout\n);
fprintf(stderr, stderr\n);
}
/foo.c
build
g++ -o foo foo.C -mwindows
/build
I couldn't get your foo.c to produce any output in a cmd shell. (It does in
a Cygwin shell)
Now, that's strange, try this on for size:
foo 2 err out
type out
type err
So, now the question is, where is the console buffer? Perhaps
WriteConsole will help?
Earnie.
Re: [patch] Help Option
Robert Collins wrote: IIRC -mwindows builds don't get a console, so can't output command line help. That doesn't mean you can't create one. Earnie.
Re: init and agetty packages available for review/upload. (fwd)
I agree with Sergey, but wouldn't /usr/sbin be a better choice of destination? /usr/sbin should not be in the PATH of a typical user. Sergey Okhapkin wrote: Because these scripts are accessible for everyone and may change global configuration settings, these scripts are for for cygwin administrator only. Sergey Okhapkin Somerset, NJ - Original Message - From: Max Bowsher [EMAIL PROTECTED] To: Sergey Okhapkin [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, November 10, 2002 8:20 AM Subject: Re: init and agetty packages available for review/upload. (fwd) Sergey Okhapkin [EMAIL PROTECTED] wrote: I don't feel myself safe with these potentialy dangerous files in the PATH... Why are they dangerous? My proposal is to move these files somewhere else. Well, thats a discussion which will probably require Chris's arbitration. -- Max. - Original Message - From: Max Bowsher [EMAIL PROTECTED] To: Sergey Okhapkin [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, November 10, 2002 8:06 AM Subject: Re: init and agetty packages available for review/upload. (fwd) Sergey Okhapkin [EMAIL PROTECTED] wrote: I don't want to introduce extra files in /bin or /usr/bin. XXX-config scripts should be located somewhere else, not in a path, something like /etc/package-config, the directory should be designated for config scripts only. $ ls /usr/bin/*-config /usr/bin/iu-config /usr/bin/libpng-config /usr/bin/libpng12-config /usr/bin/pcre-config /usr/bin/ssh-host-config /usr/bin/ssh-user-config The convention seems a little bit entrenched by now. Max.
Re: init and agetty packages available for review/upload.
IIRC, the old style symlink wouldn't work with a .exe extention. Earnie. Christopher Faylor wrote: On Fri, Nov 08, 2002 at 07:31:53PM -0500, Sergey Okhapkin wrote: What are the symlink problems? Do you mean a symlink points to the executable name without .exe suffix? Yes. But I was confused. I didn't remember (or maybe didn't know) that a symlink didn't have to contain a .exe when it was linking to a .exe. I think that's arguably a bug but it's probably entrenched enough now to be considered a feature. So, nevermind and sorry for the confusion. cgf
Re: init and agetty packages available for review/upload. (fwd)
Robert Collins wrote: On Sun, 2002-11-10 at 11:05, Sergey Okhapkin wrote: I think a postinstall script that: * sets reasonable defaults * obeys and doesn't overwrite user defined settings should be ok. The postinstall script could always query the user. Earnie.
Re: starting apache - libphp4 error
Wrong list, redirected. Please remove [EMAIL PROTECTED] from the distribution list in your responses. Gary Stainburn wrote: Hi all, I'm trying to start apache for the first time and I'm getting the following error. I've had a look in the archives and found a thread about a similar problem (same conditions, different Win32 error number) which talks about using rebase. I've looked into rebase and I'm totally list. Here's the output gary@ladvent ~ $ /usr/sbin/apachectl start Syntax error on line 236 of /etc/apache/httpd.conf: Cannot load /usr/lib/apache/libphp4.dll into server: dlopen: Win32 error 31 /usr/sbin/apachectl start: httpd could not be started. gary@ladvent ~ $ I'm running on an Advent 5372 laptop running WinME with 128MB RAM and 3GB free. apache 1.3.224-5 mod_php 4.2.0-1
Re: use of DLL without Cygwin/shell environment
Wrong list, redirected. Please remove [EMAIL PROTECTED] from the distribution when responding. gilles BOURGEOIS wrote: hello, from france, (newbie using cygwin), i am wondering about how I could use the DLL API *directly* without prompting with the starting x terminal (bash commands) The fact is I want to use this DLL in order to create a UNIX-C compilation process(makefile + gcc), but I do not want the end-user to enter the CYGWIN/Shell terminal and prompt for make and others unix command. let say this user is a windows one, and it does know anything about the unix world. so I wish I could develop a quick graphical front end, which offers the compilation functionnalities (configuration and launch tool) just with the help of mouse clicks, since this functionnality is running under the CYGWIN.DLL API (the user not even know he is using cygwin...). Thanks for any help. gilles
Re: cygwin-mketc.sh
Wrong list, redirected. Please remove cygwin-patches from the distribution in response. Paul Johnston wrote: Hi, Windows has direct equivalents of some standard unix files: /etc/hosts, services, protocols, networks. It is helpful to have symbolic links from these files in /etc to the windows equivalents. A few weeks ago we talked about this on the main cygwin list. Some of us came up with this postinstall script, which has been tested and hardened against windows 95/98/ME and NT4/2000/XP (not been tested on NT 3.51). Under NT it works with both NTFS and FAT, and it works with strict_case=yes. I think it should go in the main cygwin package and install as /etc/postinstall/cygwin-mketc.sh Paul
Re: updated procps package
Chris January wrote: http://www.doc.ic.ac.uk/~ccj00/procps-010801/procps-010801-2.tar.bz2 http://www.doc.ic.ac.uk/~ccj00/procps-010801/procps-010801-2-src.tar.bz2 http://www.doc.ic.ac.uk/~ccj00/procps-010801/setup.hint Uploaded. Please drop the version field in setup.hint. I changed that on sourceware already. Sorry, I don't understand what you mean by I changed that on sourceware already. Sourceware is the hostname for the redhat.com ftp server. Earnie.
Re: And one more package, astyle Re: New Package: doxygen-1.2.17
The Cygwin net distro isn't sort of a one man show, it's a community effort. It's not Chris and me who are the responsible people for reviewing a package and we are not the only people with the right to upload packages. This is one of the reasons I think that it might be better to: 1) Maintainers only approve the setup.hint file. 2) Upload the new package as test or new and let the Cygwin community as a whole have a say in the package configuration. a) Use cygwin.com for voting for the package with comments area and the form is mailed to [EMAIL PROTECTED] b) The package maintainer has two weeks to work the issues discussed on the [EMAIL PROTECTED] page. c) If the issues aren't fixed the package is pulled. 3) Once x count votes of approval the setup.hint can be adjusted to remove the test/new classification. a) base x on some percentage of the cygwin community population count. b) or base x on some flat number. Earnie.
Re: And one more package, astyle Re: New Package: doxygen-1.2.17
Christopher Faylor wrote: On Tue, Sep 10, 2002 at 09:14:46PM +1000, Gareth Pearce wrote: Just a pro-vote - for both - not that i have had a chance to check them for quality... Corinna says: Why not? ummm because I am a busy boy? :P - barely get a few minutes spare at all these days, let alone next to my cygwin computer. Maybe we need to change the approval process so that people actually have to try the package before saying Aye. I agree, even though in the past I've been one of those who've done this. I can see where the breakdown lies. It seems that since Chuck left for vacation that no one takes on looking at a package. The other method would be to put the package in test mode, announce the test version of the new package, and let the users give their opinion. I think I like this even better. Earnie.
Re: And one more package, astyle Re: New Package: doxygen-1.2.17
Christopher Faylor wrote: On Tue, Sep 10, 2002 at 01:27:05PM -0400, Nicholas Wourms wrote: I agree, even though in the past I've been one of those who've done this. I can see where the breakdown lies. It seems that since Chuck left for vacation that no one takes on looking at a package. [...] Speak for yourself... I was actually going to chime in here and say nobody besides Nicholas. :-) Ok, nobody besides Nicholas, but I've seen much proding from Corinna and that is what I was mainly eluding to. Earnie.
Re: [PATCH] fix bug in autoconf-2.13 that keeps cross gcc from buildingoncygwin
But, development and maintenance of 2.13 is dead for Autoconf proper. There have been
three
or four releases since then. If the developers who use Cygwin want to continue to
support
2.13 that's a different matter and those developers, someone like Dan Kegel, can
create the
patch there. However, I see that any developers time would be better spent in
converting the
buggy configure script to 2.53 format.
Earnie.
Dan Kegel wrote:
It'd be good for Cygwin to apply the patch, yes. Then the gcc FAQ could
have an entry
Q. Why can't I build cross-compilers on Cygwin?
A. Because the configure scripts shipped with gcc are buggy.
Regenerate them all under Cygwin, and it should work.
But frankly, the point of configure scripts is to be portable, so
it makes a fair bit of sense for gcc to ship with configure scripts
that are portable even to systems like cygwin.
- Dan
Earnie Boyd wrote:
I suggest that this issue be dealt with within the Cygwin distribution of
autoconf-2.13.
Earnie.
Dan Kegel wrote:
[repost -- mail system problems]
Building cross gcc's on cygwin fails because autoconf 2.13's AC_TRY_COMPILER
test assumes that it's ok to try to run possibly cross-compiled binaries,
and that if they run, the compiler must not be a cross-compiler.
This assumption fails on Cygwin; see
http://www.oarcorp.com/rtems/maillistArchives/rtems-users/1999/may/msg00075.html
http://gcc.gnu.org/ml/gcc-help/2002-05/msg00165.html
http://sources.redhat.com/ml/crossgcc/2002-08/msg00099.html
The symptom is the build hangs about twenty times waiting for you to click a
dialog box,
and the target directory's ac_cv_prog_cc_cross is improperly set to 'no'.
The problem will likely go away when gcc moves to using autoconf 2.5x, but
that may take a while, and won't help people who need to build oldish
gcc's like 3.0.x. So it's worth fixing autoconf-2.13 if it's a small, safe fix.
Fortunately, the fix does look small and safe:
--- /usr/share/autoconf2.13/acgeneral.m4.orig Thu Aug 22 18:26:58 2002
+++ acgeneral.m4Thu Aug 22 19:03:12 2002
-1510,11 +1510,13
EOF
if AC_TRY_EVAL(ac_link) test -s conftest${ac_exeext}; then
[$2]=yes
- # If we can't run a trivial program, we are probably using a cross compiler.
- if (./conftest; exit) 2/dev/null; then
-[$3]=no
- else
-[$3]=yes
+ if test $[$3] != yes; then
+# If we can't run a trivial program, we are probably using a cross compiler.
+if (./conftest; exit) 2/dev/null; then
+ [$3]=no
+else
+ [$3]=yes
+fi
fi
else
echo configure: failed program was: AC_FD_CC
i.e. after the patch, AC_TRY_COMPILER checks its 3rd parameter,
and if it's already 'yes', it knows not to run the binaries.
After applying this patch to autoconf-2.13 and installing,
you then need to regenerate libiberty/configure,
gcc/configure and fastjar/configure. It might be good if future releases
of gcc that still used autoconf-2.13 were done on machines with an
autoconf-2.13 with this patch applied.
This is only a partial fix; it requires the user to override
ac_cv_prog_cc_cross. A similar bug in ltconfig can be worked around
without a patch by overriding cross_compiling=yes in the same way.
Both overrides should only be done during the build of runtime libraries.
Fortunately, gcc's makefile has pseudotargets that let you do this.
For instance:
make all-gcc
ac_cv_prog_cc_cross=yes cross_compiling=yes make all-target
make install
Users on non-cygwin platforms can ignore this issue, and just do
'make install' as usual. This patch will neither help nor hurt them.
(Note that overriding ac_cv_prog_cc_cross at make time appears to be sufficient.
Although it would be more logical to override them when doing initial
configuration of gcc, that wouldn't let you work around the ltconfig bug.)
Even if future autoconf and gcc releases don't apply this patch, maybe
this post will help people who need to build gcc on cygwin.
- Dan
http://www.kegel.com
Re: [PATCH] fix bug in autoconf-2.13 that keeps cross gcc from buildingon cygwin
I suggest that this issue be dealt with within the Cygwin distribution of
autoconf-2.13.
Earnie.
Dan Kegel wrote:
[repost -- mail system problems]
Building cross gcc's on cygwin fails because autoconf 2.13's AC_TRY_COMPILER
test assumes that it's ok to try to run possibly cross-compiled binaries,
and that if they run, the compiler must not be a cross-compiler.
This assumption fails on Cygwin; see
http://www.oarcorp.com/rtems/maillistArchives/rtems-users/1999/may/msg00075.html
http://gcc.gnu.org/ml/gcc-help/2002-05/msg00165.html
http://sources.redhat.com/ml/crossgcc/2002-08/msg00099.html
The symptom is the build hangs about twenty times waiting for you to click a dialog
box,
and the target directory's ac_cv_prog_cc_cross is improperly set to 'no'.
The problem will likely go away when gcc moves to using autoconf 2.5x, but
that may take a while, and won't help people who need to build oldish
gcc's like 3.0.x. So it's worth fixing autoconf-2.13 if it's a small, safe fix.
Fortunately, the fix does look small and safe:
--- /usr/share/autoconf2.13/acgeneral.m4.orig Thu Aug 22 18:26:58 2002
+++ acgeneral.m4Thu Aug 22 19:03:12 2002
-1510,11 +1510,13
EOF
if AC_TRY_EVAL(ac_link) test -s conftest${ac_exeext}; then
[$2]=yes
- # If we can't run a trivial program, we are probably using a cross compiler.
- if (./conftest; exit) 2/dev/null; then
-[$3]=no
- else
-[$3]=yes
+ if test $[$3] != yes; then
+# If we can't run a trivial program, we are probably using a cross compiler.
+if (./conftest; exit) 2/dev/null; then
+ [$3]=no
+else
+ [$3]=yes
+fi
fi
else
echo configure: failed program was: AC_FD_CC
i.e. after the patch, AC_TRY_COMPILER checks its 3rd parameter,
and if it's already 'yes', it knows not to run the binaries.
After applying this patch to autoconf-2.13 and installing,
you then need to regenerate libiberty/configure,
gcc/configure and fastjar/configure. It might be good if future releases
of gcc that still used autoconf-2.13 were done on machines with an
autoconf-2.13 with this patch applied.
This is only a partial fix; it requires the user to override
ac_cv_prog_cc_cross. A similar bug in ltconfig can be worked around
without a patch by overriding cross_compiling=yes in the same way.
Both overrides should only be done during the build of runtime libraries.
Fortunately, gcc's makefile has pseudotargets that let you do this.
For instance:
make all-gcc
ac_cv_prog_cc_cross=yes cross_compiling=yes make all-target
make install
Users on non-cygwin platforms can ignore this issue, and just do
'make install' as usual. This patch will neither help nor hurt them.
(Note that overriding ac_cv_prog_cc_cross at make time appears to be sufficient.
Although it would be more logical to override them when doing initial
configuration of gcc, that wouldn't let you work around the ltconfig bug.)
Even if future autoconf and gcc releases don't apply this patch, maybe
this post will help people who need to build gcc on cygwin.
- Dan
http://www.kegel.com
[Fwd: GNU emacs 21.2-6 available]
I'm surprised that this announcement was accepted, it's not standard format. Earnie. Original Message Subject: GNU emacs 21.2-6 available Date: Tue, 20 Aug 2002 23:23:31 -0400 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] GNU emacs 21.2-6 has been uploaded. Changes: - fixed missing lisp documentation problem - found and fixed root cause of black-on-black color scheme Joe Buehler
Re: GNU emacs 21.2-3 packages available
Corinna Vinschen wrote: On Mon, Aug 12, 2002 at 06:45:32PM -0400, Joe Buehler wrote: Joe Buehler wrote: New GNU emacs packages are available for upload to sources.redhat.com at: http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs/emacs-21.2-3-src.tar.bz2 http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs/emacs-21.2-3.tar.bz2 http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs/setup.hint http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs-el/emacs-el-21.2-3.tar.bz2 http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs-el/setup.hint http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs-X11/emacs-X11-21.2-3.tar.bz2 http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs-X11/setup.hint This version fixes tty subprocess functionality: telnet, ange-ftp, gnus and the like. Uploaded. Please add a note to your announcement that the deinstallation of the old package will drop ctags exectuables so that a reinstall of that package would be necessary. Would it drop ctags with requires: ctags cygwin in the hint file? Earnie.
Re: [MinGW-dvlpr] Re: [GCC 3.2] dll/exe exceptions patch
Danny Smith wrote: --- Danny Smith [EMAIL PROTECTED] wrote: I have modified the Adriano dos Santos Fernandes patchset somewhat so that it can be used with both cygwin and mingw In absence of feedback on this patch from cygwin developers I will modify so that it only applies to mingw and -mno-cygwin. In absence of feedback on this patch from mingw devlopers I will not apply at all. If you're waiting on me to respond, you're the primary developer, go for it. Earnie.
Re: Skel files
John Morrison wrote: There. Quite long and slightly rambly. However, what do people think; aye or nay? The copy _will_ be done as part of $HOME creation, default files would be a bonus I believe. Some of the files I have on my system which I believe could have defaults... .bashrc No .bash_profile No .login No .logout No .xinit Yes - But should be copied only by the X11 package or perhaps RXVT. .pinerc Yes - But should be copied only by the PINE package .inputrcNo .vimrc Yes - But should be copied only by the VIM package .xserverrc Yes - But should be copied only by the X11 package needing it Earnie.
Re: profile package
John Morrison wrote: There's now a 1.0-2. Added a little more functionality and lots more comments. I've not recieved much feedback wrt this. Come on folks - what do you think? I haven't looked at the package but sdesc: Core common files needed for correct operation of cygwin ldesc: Core common files needed for correct operation of cygwin I don't believe this to be the correct description of the package. category: base Shouldn't there be a dependency on the Cygwin package? Earnie.
Re: profile package
John Morrison wrote: From: Earnie Boyd [mailto:[EMAIL PROTECTED]] John Morrison wrote: There's now a 1.0-2. Added a little more functionality and lots more comments. I've not recieved much feedback wrt this. Come on folks - what do you think? I haven't looked at the package but sdesc: Core common files needed for correct operation of cygwin ldesc: Core common files needed for correct operation of cygwin I don't believe this to be the correct description of the package. Rob supplied the descriptions, I'm sure cygwin will operate without profile, but would just Core common files be sufficient? Debian's description (slightly altered) is: sdesc: Base system miscellaneous files ldesc: This package contains the basic filesystem hierarchy, and several important miscellaneous files Would this be better? No, more like: sdesc: Default environment initialization scripts ldesc: This package contains the default environment initialization scripts for the Cygwin logon process. It also contains skeleton scripts in /etc/skel and other example scripts that you could create in your HOME directory in /usr/doc/Cygwin/examples/. category: base Shouldn't there be a dependency on the Cygwin package? ack :) requires: cygwin Do you think it needs any shells? the Deb package consists of: (relevant to Cygwin) etc/debian_version etc/host.conf etc/inputrc etc/issue etc/issue.net etc/nsswitch.conf etc/profile with a seperate base-passwd which provides the master /etc/passwd and /etc/group files, containing allocated user and group IDs, plus the update-passwd utility to keep them up to date. Note that I'm willing to do this package too :) I don't understand this. I thought that this profile package would do that. It must create the /etc/passwd and /etc/group files if setup isn't going to. Earnie. BTW, I like initscripts for the package name.
Re: profile package
Christopher Faylor wrote: Shouldn't there be a dependency on the Cygwin package? ack :) requires: cygwin I don't see any reason for this to require cygwin. There are no programs there. There would be no point in downloading this file by itself. Therefore, a dependency to cygwin should be mandatory. Earnie.
Re: Skel files
John Morrison wrote: From: Earnie Boyd [mailto:[EMAIL PROTECTED]] Thanks Earnie, response is welcome :) John Morrison wrote: Some of the files I have on my system which I believe could have defaults... .xinit Yes - But should be copied only by the X11 package or perhaps RXVT. By copied I take it you mean packaged as part of a tar? I agree, personally, I'd choose X11. Maybe both. .xserverrc Yes - But should be copied only by the X11 package needing it Agreed. .pinerc Yes - But should be copied only by the PINE package Agreed. .vimrc Yes - But should be copied only by the VIM package Agreed. I'm attempting (with this mail) to raise the profile (if you'll forgive the pun) of the skel capabilities. I _definitely_ want them to be part of the appropriate package! :) You can create the /profile/skel for these and the package could copy if they exist or provide it's own default. .bashrc No .bash_profile No .inputrcNo .login No .logout No Why no? Not even comments and example usage? I (as a *nix newbie) didn't know these files existed, uses of or anything for ages. I found them out either by accident or by viewing somebody elses system. Even just a place holder with a comment as to what the file is for I would have considered useful. Examples are fine. Forcing the user to have them would be a pain, IMO. It complicates the install process beyond what is needed. These files are for the user to modify there environment to their specific need, not what someone else dreams up as a standard user environment. The standard environment should only be controlled by the /etc/profile, etc. files. Yes, you could argue that about the other files as well. However, the other files aren't as common and are more tool specific rather than environment specific. Earnie
Re: ITP: profile
Harold L Hunt II wrote: Earnie, The reply-to address for the mailing list is now [EMAIL PROTECTED] Yes, I set it that way myself. In light of this, maybe you should reevaluate whether your default action should be to hit ``reply'' or ``reply-to-all''. I will not be adjusting my actions. Earnie.
Re: rebase problem for cygcurl-2.dll still existing?!
Nicholas Wourms wrote: Jason Tishler wrote: Is that a deficiency of cygwin as a whole, or just related to the way my DLL was built?) Cygwin's fork() attempts to load DLLs in the child in the same location as in the parent. If it fails, then the child aborts. Other than the lack of someone writing the code, is there any reason why fork() can't automagically try another location? Is this even possible? Or does it go against the way Cygwin/Windows works? The correct answer to this question is Use the source, Luke (tm). Earnie.
Re: mknetrel: two small fixes
Jan Nieuwenhuizen wrote: diff -purNX.cvsignore ../foo . then, the CVS directories may show up.] So `diff -purNX.cvsignore -xCVS ../foo .' Earnie.
Re: [PATCH]: mknetrel builds Guile #2: debug
Jan Nieuwenhuizen wrote: Btw: A very silly question, but I can't seem to get `cvs diff' to respect your (Cygwin's?) wishes of excluding the ChangeLog from the diff. It doesn't grok -X,--exclude options, most annoying. How do you manage? Remove the ChangeLog diff from the patch. Copy the text from the ChangeLog to the top of the diff file. Patch is smart enough to ignore the non-diff text in the front of the file. Earnie.
Re: [PATCH]: mknetrel builds Guile #2: debug
Jan Nieuwenhuizen wrote: Earnie Boyd [EMAIL PROTECTED] writes: Btw: A very silly question, but I can't seem to get `cvs diff' to respect your (Cygwin's?) wishes of excluding the ChangeLog from the diff. It doesn't grok -X,--exclude options, most annoying. How do you manage? Remove the ChangeLog diff from the patch. Copy the text from the ChangeLog to the top of the diff file. Patch is smart enough to ignore the non-diff text in the front of the file. Hrmm. If you're going to have nonstandard requests, it would be handy if these somehow would be handled automagically. How dead is CVS development, maybe they would take a patch? This has nothing to do with CVS. It has to do with standards set by the development teams and the fact that your changes to ChangeLog often (most likely) cause merge conflicts. Earnie.
Re: ITP: Guile 1.5.6
--- Jan Nieuwenhuizen [EMAIL PROTECTED] wrote: Hi List, Last night, I've eventually succeeded in building guile-1.5.6, with shared object libraries for Cygwin. I'm in favor of this package, although I haven't review them yet. With this package autogen (autogen.sf.net) should build as well. Earnie. __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: OS emulators - OT [WAS: Re: Need a teTeX-beta maintainer]
Nicholas Wourms wrote: You might want to try http://bochs.sourceforge.net/ instead of vmware. Earnie. Very cool Earnie, I didn't know this project was still going on... Looks like it's made huge progress since I last checked... Can you give any first-hand testimonials? No, it is suggested by the ReactOS team though, which is how I knew about it. Earnie.
Re: new setup.exe crashes with kde's setup.ini
John Marshall wrote: Yes. They've been screwed by the download mirror system Sourceforge introduced on 2002-05-03. As I wrote when I changed prc-tools's .htaccess to deal with this: Update the redirect to cope with Sourceforge's new download mirror system. You'd think they could have implemented that without breaking all the old URLs, but no... They need to tell people to use http://us.dl.sourceforge.net/sourceforge/kde-cygwin/setup.ini (or similar) instead. The direct ftp server is ftp://ftp1.sourceforge.net/pub/sourceforge/kde-cygwin Earnie.
Re: mingw and other gotchas in gcc 3.1
Christopher Faylor wrote: I'm finishing up on the release of gcc 3.1 and I have a few gotchas that I'd like to discuss: 1) I was going to take Red Hat's cue and release the new version of gcc as gcc3. However, this will require manual deinstallation of gcc (2.95.3-whatever) so this is probably a bad thing. Somehow, I just think that if we don't still make the older version of gcc available, there will be many This used to build on gcc 2.95.3!!! messages. So, maybe I should rename the old version to gcc2 or release a version of 2.95.3 that names the binaries (i686-pc-cygwin-gcc2) differently. Any thoughts? I think the gcc2 idea should be acceptable. 2) I'm trying to remove most of the spec file magic that dealt with mingw and I think I've actually been pretty successful. However, my new scheme relies on changing the machine name from i686-pc-cygwin to i686-pc-mingw. That means that the new layout looks like this: /usr/i686-pc-mingw/: total 0 lrwxrwxrwx1 cgf None 122 Jun 23 23:41 bin - ../i686-pc-cygwin/bin lrwxrwxrwx1 cgf None 125 Jun 23 23:42 include - /usr/include/mingw lrwxrwxrwx1 cgf None 113 Jun 23 23:42 lib - /usr/lib/mingw /usr/lib/gcc-lib: total 0 drwxr-xr-x4 cgf None0 Dec 25 2000 i686-pc-cygwin lrwxrwxrwx1 cgf None 108 Jun 23 23:48 i686-pc-mingw - i686-pc-cygwin Ideally, the include, lib stuff in /usr/i686-pc-mingw should not be a symbolic link but should, instead, be the actual directories that they reference. However, coordinating this will be tricky. I'm thinking that I should just add a postinstall script that will try to do the right thing if /usr/i686-pc-mingw doesn't have the right stuff. However, I'd like to confirm with Earnie/Danny that this new layout makes sense. FWIW, I think this is the way I should have laid stuff out originally. It should be i686-pc-mingw32. You also may wish the target to be stated only as mingw32 instead of i686-pc-mingw32 in order to be consistent with the MinGW version and to ward off confusion in the list. Otherwise it's fine with me. 3) The above layout has a problem. It works ok generating mingw binaries but, with gcc-3.1, I've configured things using --enable-threads=posix. So, some binaries don't link successfully. That means that the libgcc.a library is inappropriate for mingw. So, the above directory layout can potentially become a little trickier since I'll need to build a libgcc.a (and libstdc++.a, I guess) for mingw. This seems like a lot of duplication of effort, though, so maybe I'll try to figure out some way to download the bits that I need from sourceforge or something. Or,... The sourceforge ftp directory is ftp1.sourceforge.net/pub/sourceforge/mingw/ if you wish to take that direction. Or, Danny... 4) Since mingw is becoming so logically separated from gcc, it is possible that it could become a separate package. So, if someone was willing to supply a gcc-mingw package, it would actually be helpful. I don't think I could stand the pain of making this optional, so the gcc package would rely on the gcc-mingw package rather than the other way around. This would allow updating libgcc.a and libstdc++.a without requiring a new release of gcc. Hmm. I wonder if I should break libstdc++.a out of the gcc package. Urgh. Any suckers (cough) want to contribute a separate package? Or would a --host=cygwin --build=cygwin --target=mingw be better for the gcc-mingw cygwin package? Earnie.
Re: winsup/mingw CVS HEAD
Earnie Boyd wrote: Danny has merged his branch into the CVS HEAD. The MinGW runtime now supplies many C99 compliances. I will be uploading a mingw-runtime-2.0 version shortly. In the meantime the HEAD is to be considered frozen until I get out the release, hopefully today. If you wish to use the C99 extensions (extensions to the MSVCRT) then you must add -lmingwex to the build line. Release is complete. You may now update the HEAD. Earnie.
Re: New setup.exe snapshot 2.249.2.2
Robert Collins wrote: Hmm, well it's definitely a bug, but how to fix? The workaround will (setting non-UNICODE programs to English) will have to do for now. Perhaps a #define UNICODE before #include windows.h would help? Earnie.
Re: New setup.exe snapshot 2.249.2.2
Robert Collins wrote: -Original Message- From: Earnie Boyd [mailto:[EMAIL PROTECTED]] Sent: Monday, 10 June 2002 11:20 PM To: Robert Collins Cc: [EMAIL PROTECTED] Subject: Re: New setup.exe snapshot 2.249.2.2 Robert Collins wrote: Hmm, well it's definitely a bug, but how to fix? The workaround will (setting non-UNICODE programs to English) will have to do for now. Perhaps a #define UNICODE before #include windows.h would help? We can't rely on the MS layer for unicode on win9x. Doesn't the above require that? I hesitate to look at multiple binaries either :[. If you wish to continue supporting W9x, and I suppose you do, perhaps an alternative binary would suffice, I.E.: A binary with UNICODE and a binary without UNICODE? Earnie.
Re: URL paths in setup.exe
Robert Collins wrote: I'd like to formalise what file:// and cygfile:// schemes mean. file:// is a native filesystem URL handler - whatever the OS may be. cygfile:// is a handler that only makes sense on mingw platforms, and access's the cygwin mount table. cygfile:// makes no sense at all on my MinGW platforms. What mingw are you talking about? cygfile:// to me only makes sense in Cygwin land. This means that: file:///foo/bar.txt is /foo/bar.txt on posix, and Current drive:\foo\bar.txt on mingw. I don't see that working natively, so it doesn't work on my MinGW, what mingw are you talking about? I tried both Netscape and IE, they both understand file://c:/temp/foo.txt, though. However, file:///temp/foo.txt wasn't found. As for file:// + d: + \foo\bar.txt, can we normalise that as file://d|/foo/bar.txt - that is what MS do, and will be less confusing for users of the codebase (IMO). As I've already stated file://c:/foo/bar.txt also works. Earnie.
Re: URL paths in setup.exe
Robert Collins wrote: How would this confuse them ? I don't think with file://d|/foo/bar.txt is better thatn file://d/foo/bar.txt. There is a method which converts d:\foo\bar to file URL - isn't it enough ? There is also a method whic gets the parsed URL as path. Btw see the attached program. It is a test for the URL parser. file://d/foo/bar.txt isn't clear whether it's absolute or not. file:///d/foo/bar.txt is on posix, and file://d|/foo/bar.txt is on win32. file:///d/foo/bar.txt on Cygwin should work as well depending on the cygdrive value. ;) file:///d:/foo/bar.txt should be the win32 mechanism. file://d/foo/bar.txt is definitely relative to the current working directory. Earnie.
Re: URL paths in setup.exe
Pavel Tsekov wrote: file://d|/foo/bar.txt is on win32. Ok I understand this. The d| or d: is useful so we can understand that the path is not on some remote machine. EB file:///d/foo/bar.txt on Cygwin should work as well depending on the EB cygdrive value. ;) EB file:///d:/foo/bar.txt should be the win32 mechanism. Why the extra slash infront of d ? Bad typing. that should be file://d:/foo/bar.txt EB file://d/foo/bar.txt is definitely relative to the current working EB directory. I don't understand why it is relative ? mkdir -p d/foo touch d/foo/bar.txt It's relative to the working directory. Earnie.
Re: URL paths in setup.exe
Robert Collins wrote: -Original Message- From: Earnie Boyd [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 07, 2002 9:50 PM cygfile:// makes no sense at all on my MinGW platforms. What mingw are you talking about? cygfile:// to me only makes sense in Cygwin land. In cygwin land, file:// can access posix paths via the standard C library and C++ library calls. In MinGW land how do you access cygwin posix paths? Answer: create your own library to read the cygwin mount table (which setup has), and then wrap your C++ and C lib calls via that (which is what cygfile:// does). Fine, but that's still a Cygwin library and doesn't exist in MinGW land. I'm making a fuss for search engine sake. So, please, let's find a different way to reference it or I'll be getting questions of Where can I find the cygfile library? on my MinGW list. This means that: file:///foo/bar.txt is /foo/bar.txt on posix, and Current drive:\foo\bar.txt on mingw. I don't see that working natively, so it doesn't work on my MinGW, what mingw are you talking about? I tried both Netscape and IE, they both understand file://c:/temp/foo.txt, though. However, file:///temp/foo.txt wasn't found. Ok, well sounds like MS only do absolute paths (which the spec requires). And, that is a good thing, IMO. As for file:// + d: + \foo\bar.txt, can we normalise that as file://d|/foo/bar.txt - that is what MS do, and will be less confusing for users of the codebase (IMO). As I've already stated file://c:/foo/bar.txt also works. Sure. Try file://c|/foo/bar.txt. You'll find that that works too - and that is conformant URI syntax, whereas file://c:/foo/bar.txt is not. I'll agree. Earnie.
Re: URL paths in setup.exe
Robert Collins wrote: On Tue, 2002-05-07 at 22:24, Earnie Boyd wrote: Robert Collins wrote: -Original Message- From: Earnie Boyd [mailto:[EMAIL PROTECTED]] Fine, but that's still a Cygwin library and doesn't exist in MinGW land. I'm making a fuss for search engine sake. So, please, let's find a different way to reference it or I'll be getting questions of Where can I find the cygfile library? on my MinGW list. Huh? It's mingw code designed for mingw, and using mingw calls. It won't build with -mnowin32 on cygwin, and it won't build on posix systems. It's also not a library per se - it's the io_streams_cygfile.cc and .h files in the setup source. It isn't visible anywhere else. No user should - ever - see cygfile:// as a reference. It's purely for internal use to differentiate between user entered paths and paths we *know* belong in the cygwin file system that we are creating as we do the install. I'm open to ideas for renaming, but ... posix:// is wrong (it's not a posix provider per se - it's a cygwin mounted structure provider). (And posix:// is the most obvious alternative to cygfile:// for me.) The cygfile:// is fine, it's the reference to MinGW land which exists at www.mingw.org that will confuse some search engine user that I'm concerned with. You don't have a library for MinGW land. You have methods that you use use mingw to build or more precisely you use -mno-cygwin to build, correct? Earnie.
Re: rebasing new packages?!
Jason Tishler wrote: Rob, On Tue, May 07, 2002 at 12:55:49AM +1000, Robert Collins wrote: From: Jason Tishler [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 07, 2002 12:57 AM If the attached patch is accepted, can I start using STL in setup.exe now? You can start using STL now, but if you get errors... fix em first. See the following: http://cygwin.com/ml/cygwin/2002-05/msg00311.html What now? This is a header fix, all that needs to happen is a repackage of the current binary release with the fixed header file. The same could be done with the src package. I don't see this as a major stumbling block. If nothing else, post the patch to the header on the instructions to build setup page. Earnie.
Re: new cygwin package: cgoban
Charles Wilson wrote: (*) counter argument: gtk+ on cygwin currently uses X. However, the code is THERE to use native MS windowing -- because there is a native MS port (on a separate CVS branch). It might be possible, some time in the future, to have TWO different gtk+ builds on cygwin: and X one and an MS one (it is not CURRENTLY possible to do that). But, in that eventuality, you could then have a whole SLEW of cygwin ports of gtk+-based programs that could be compile as X apps or as native MS windowing apps -- depending on which version of the gtk+ libs they were linked against. But should we borrow trouble against something that may never happen? (Tor Lilqvist, maintainer of the windows port of gtk+, doesn't seem too enthusiastic about refactoring to separate his native-windowing stuff from his msvcrt-not-glibc-runtime stuff; it's all #if _MSWIN ...). Ah, now the point at which I was trying to drive home at. Yes, IMO, we should borrow trouble as that trouble is most likely to happen. It's much like the MinGW libraries where the headers and libraries need to be segregated, so will these apps. Earnie.
Re: new cygwin package: cgoban
Robert Collins wrote: -Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 5:04 AM Volker Zell agreed. Nobody else responded. I kinda like it, but FHS has moved away from that; now on Red Hat systems it appears that ONLY those programs specifically part of XFree86 are included there -- or programs whose purpose is to manipulate XFree86 itself (like third-party Xconfigurators and such). I'm agnostic on this one, I don't use X enough to really care. However, Earnie has pointed out that extra path elements have a lamentable performance impact, so perhaps we should be avoiding that? I see it's time for me to chime in. We the cygwin-apps developers must insist that all X11 packages use --prefix=/usr/X11R6 because it's possible for an X11 package to be both Win32 and X11, E.G.: rxvt. And I the user could want to use either depending on the moode (spelling intentional) I'm in. Earnie.
Re: new cygwin package: cgoban
Charles Wilson wrote: Earnie Boyd wrote: I see it's time for me to chime in. We the cygwin-apps developers must insist that all X11 packages use --prefix=/usr/X11R6 because it's possible for an X11 package to be both Win32 and X11, E.G.: rxvt. And I the user could want to use either depending on the moode (spelling intentional) I'm in. Bad example, Earnie. The current rxvt package is, itself, in a single binary, BOTH Win32 AND X11. It is fine right where it is (--prefix=/usr). No, it's a good example. And you're correct the existing rxvt package is fine right where it is. It's the one that uses the Xsever displays that'll need to be in /usr/X11R6/bin. Now, if you want to distinguish between, say, and XEmacs that is built using native MS windowing only (which should go into --prefix=/usr) and an XEmacs built using X11 windowing (which, depending on how this discussion ends, MIGHT go into --prefix=/usr/X11R6), then that's a different issue. Well, yes, it's the same principal. Or do you mean that rxvt as is will execute on either X11 WM or Win32 WM? However, even in that case, I'm not sure I agree with you. Suppose there WERE two tentative XEmacs packages. Should a user be able to install both at the same time? Why not, it should be the users choice, depending on the moode (see the P.S. for definition). Then he would be duplicating all 50Meg of the elisp code -- which is identical -- in /usr/share/xemacs/ and /usr/X11R6/share/xemacs/. The two packages would have to have different names -- XEmacs-MS- and XEmacs-X- ? Or should these two packages be coordinated -- XEmacs-MS- (which contains binary and libs), XEmacs-X (ditto), and a separate XEmacs-elisp (which both use, and installs the 50M of elisp into --prefix=/usr.) But in that case, the XEmacs-X package isn't really --prefix=/usr/X11R6 -- it's --prefix=/usr --bindir=/usr/X11R6/bin --libdir=/usr/X11R6/lib. This is a messy issue. Messy issue correct, but could be covered by varying startup scripts and which path is listed first in the path list. I.E.: If I want to default to X11 binaries I have a PATH similar to /usr/X11R6/bin:/bin and if I want to default to Win32 binaries I have a PATH similar to /bin:/usr/X11R6/bin. Basically, what I am getting at is you are raising a whole nother can of worms: (1) programs that can exist in EITHER native or X forms. Yes. That is a different issue than (2) programs which are simultaneously, within the same binary, BOTH native and X (e.g. your rxvt example) and it is a different issue than (3) programs that exist ONLY in X form. Ok, so you are saying that the current rxvt package can execute in either mode, wasn't aware of that. Let's limit this discussion to group (3), okay? No, we need to make the decision based on (1) and (3). I agree that (2) goes to prefix=/usr. On group (1), anybody want to check how Red Hat separates/enables coexistence of packages that are either X or SVGAlib, and take that to a different thread? We already know that (group 3) almost all X programs (with very few exceptions) go into --prefix=/usr on RHL. How does that matter? If I have a GUI application that I want either Win32 or X11 depending on moode and it doesn't do it automagically? Earnie. P.S.: moode - The mode of operation depending on the mood of the person executing the process based upon the mode of the environment which itself is dependant of the mood of the person initializing the environment.
Re: rebasing new packages?!
Robert Collins wrote: -Original Message- From: Jason Tishler [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 11:52 PM As long as the required dependencies are easily satisfied: a) STL headers + any libs for gcc on cygwin (i.e. OOTB build for developers). Isn't a) already satisfied? Possibly. I'm simply setting expectations. b) STL headers + any libs for gcc -mno-cygwin (i.e. how I build, and the documented release build on Is b) satisfied by the following? http://www.colomsat.net.co/freehost/ngiraldo/cppcygwin.html b) is an alternative approach to what I've already documented here. So it covers libstc++ aka libg++-3. I don't know how much of the STL that includes (see my earlier email). http://sources.redhat.com/cygwin-apps/setup.html). c) STL headers + any libs for a linux hosted cross-chain targeting mingw. I.e. how I expected Chris builds. I don't know how to satisfy c). If a b are satisfied with the libg++-3 library and headers, then c) is trivial.If not then someone needs to check it is doable. As long as rules a b are followed in rule c then c is doable. Earnie.
Re: Error in configuring setup.
Robert Collins wrote: -Original Message- From: Earnie Boyd [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 02, 2002 3:52 AM To: Jan Nieuwenhuizen Cc: [EMAIL PROTECTED] Subject: Re: Error in configuring setup. Required AUTHORS and NEWS files are missing. Required by what? It was required by some instance of automake execution. It's possible you fixed it. I wasn't aware there was a separate cygwin-apps-cvs list so I don't know if you fixed that. I'm now subscribed to cygwin-apps-cvs. Earnie.
Re: [MinGW-dvlpr] [w32api] : Move anonymous struct/union defines out of windows.h
Fine by me. Earnie. Danny Smith wrote: Hello Can any one see any problems with moving this block of defines: #ifdef __GNUC__ #ifndef NONAMELESSUNION #if __GNUC__ 2 || (__GNUC__ == 2 __GNUC_MINOR__ = 95) #define _ANONYMOUS_UNION __extension__ #define _ANONYMOUS_STRUCT __extension__ #else #if defined(__cplusplus) #define _ANONYMOUS_UNION __extension__ #endif /* __cplusplus */ #endif /* __GNUC__ 2 || (__GNUC__ == 2 __GNUC_MINOR__ = 95) */ #endif /* NONAMELESSUNION */ #elif defined(__WATCOMC__) #define _ANONYMOUS_UNION #define _ANONYMOUS_STRUCT #endif /* __GNUC__/__WATCOMC__ */ #ifndef _ANONYMOUS_UNION #define _ANONYMOUS_UNION #define _UNION_NAME(x) x #define DUMMYUNIONNAME u #define DUMMYUNIONNAME2 u2 #define DUMMYUNIONNAME3 u3 #define DUMMYUNIONNAME4 u4 #define DUMMYUNIONNAME5 u5 #define DUMMYUNIONNAME6 u6 #define DUMMYUNIONNAME7 u7 #define DUMMYUNIONNAME8 u8 #else #define _UNION_NAME(x) #define DUMMYUNIONNAME #define DUMMYUNIONNAME2 #define DUMMYUNIONNAME3 #define DUMMYUNIONNAME4 #define DUMMYUNIONNAME5 #define DUMMYUNIONNAME6 #define DUMMYUNIONNAME7 #define DUMMYUNIONNAME8 #endif #ifndef _ANONYMOUS_STRUCT #define _ANONYMOUS_STRUCT #define _STRUCT_NAME(x) x #define DUMMYSTRUCTNAME s #define DUMMYSTRUCTNAME2 s2 #define DUMMYSTRUCTNAME3 s3 #else #define _STRUCT_NAME(x) #define DUMMYSTRUCTNAME #define DUMMYSTRUCTNAME2 #define DUMMYSTRUCTNAME3 #endif #ifndef NO_STRICT #ifndef STRICT #define STRICT 1 #endif #endif from windows.h to windef.h, which is the first w32api header that windows.h includes. Thus anything that includes windows.h to get these defines will still get them through windef.h Why? Often (specifically, in g++-v3 header gthr-win32.h, which is included by STL userland headers to get inlined TLS functions) user only needs the windef.h, winnt.h and winbase.h w32api declarations and defines. Doing this: #include stdarg.h #include windef.h /* includes winnt.h and winerror.h */ #include winbase.h #ifdef __cplusplus extern C #endif DWORD WINAPI GetLastError(void); /* from winuser.h */ is much preferable to: #include windows.h, even if we do the sort of MEANER_AND_LEANER dance that winsup.h does. The anonymous union/structure business is needed in winnt.h and elsewhere. I can't find any MSDN documnetation that says they should be in windows.h, though Danny http://messenger.yahoo.com.au - Yahoo! Messenger - A great way to communicate long-distance for FREE!
Error in configuring setup.
Upon Robert's insistance I've installed the autotools. :( Now after about 10 iterations of aclocal, libtoolize, autoconf I: mkdir bld cd bld ../configure And toward the configure ends with: configure: configuring in libgetopt++ configure: running /bin/sh ../cfgaux/configure 'CFLAGS=-O0 -g' 'CXXFLAGS=-O0 -g' --cache-file=/dev/null --srcdir=../../libgetopt++ ../cfgaux/configure: Can't open ../cfgaux/configure: No such file or directory configure: error: /bin/sh ../cfgaux/configure failed for libgetopt++ sed: can't read confdefs.h: No such file or directory Earnie.
Re: Error in configuring setup.
Required AUTHORS and NEWS files are missing. Earnie. Jan Nieuwenhuizen wrote: Earnie Boyd [EMAIL PROTECTED] writes: Upon Robert's insistance I've installed the autotools. :( Now after about 10 iterations of aclocal, libtoolize, autoconf I: And toward the configure ends with: s/toward// configure: configuring in libgetopt++ Yes, it seems something strange is going on here. It would be very nice too, if the libgetopt++ directory had a pregenerated ./configure. Also, after checking out setup: cvs -d :pserver:[EMAIL PROTECTED]:/cvs/cygwin-apps co setup I also get setup/libgetopt++, setup/cfgaux (and zlib and, bzlib, of course), but after removing setup/libgetop++ and setup/cfgaux and doing an cvs update -d in ./setup, libgetopt++ and cfgaux are not fetched from cvs. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Error in libgetopt++ from the setup build directory [WAS: Re: Error in configuring setup.]
Earnie Boyd wrote: Upon Robert's insistance I've installed the autotools. :( Now after about 10 iterations of aclocal, libtoolize, autoconf I: mkdir bld cd bld ../configure And toward the configure ends with: configure: configuring in libgetopt++ configure: running /bin/sh ../cfgaux/configure 'CFLAGS=-O0 -g' 'CXXFLAGS=-O0 -g' --cache-file=/dev/null --srcdir=../../libgetopt++ ../cfgaux/configure: Can't open ../cfgaux/configure: No such file or directory configure: error: /bin/sh ../cfgaux/configure failed for libgetopt++ sed: can't read confdefs.h: No such file or directory Ok, I finally found the bootstrap.sh files in setup/ and setup/libgetopt++ directories and executed them. I successfully configured. However now from the build process for libgetopt++ I get: g++ -DPACKAGE=\setup\ -DVERSION=\0\ -DHAVE_DLFCN_H=1 -DHAVE_ALLOCA_H=1 -I. -I.. -I../bz2lib -I../libgetopt++/include -Werror -Winline -Wall -Wpointer-arith -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wcomments -O0 -g -c -o desktop.o `test -f ../desktop.cc || echo '../'`../desktop.cc In file included from ../libgetopt++/include/getopt++/BoolOption.h:19, from ../desktop.cc:54: ../libgetopt++/include/getopt++/Option.h:25: #error string required make[2]: *** [desktop.o] Error 1 make[2]: Leaving directory `/prjz/cygwin/rt/src/cygwin-apps/setup/bld' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/prjz/cygwin/rt/src/cygwin-apps/setup/bld' make: *** [all] Error 2 It appears that the configure process missed setting HAVE_STRING. Earnie.
Re: Error in libgetopt++ from the setup build directory [WAS: Re: Error in configuring setup.]
BTW, the CVS has a configure file in the setup directory as well as an aclocal.m4. Earnie. Earnie Boyd wrote: Earnie Boyd wrote: Upon Robert's insistance I've installed the autotools. :( Now after about 10 iterations of aclocal, libtoolize, autoconf I: mkdir bld cd bld ../configure And toward the configure ends with: configure: configuring in libgetopt++ configure: running /bin/sh ../cfgaux/configure 'CFLAGS=-O0 -g' 'CXXFLAGS=-O0 -g' --cache-file=/dev/null --srcdir=../../libgetopt++ ../cfgaux/configure: Can't open ../cfgaux/configure: No such file or directory configure: error: /bin/sh ../cfgaux/configure failed for libgetopt++ sed: can't read confdefs.h: No such file or directory Ok, I finally found the bootstrap.sh files in setup/ and setup/libgetopt++ directories and executed them. I successfully configured. However now from the build process for libgetopt++ I get: g++ -DPACKAGE=\setup\ -DVERSION=\0\ -DHAVE_DLFCN_H=1 -DHAVE_ALLOCA_H=1 -I. -I.. -I../bz2lib -I../libgetopt++/include -Werror -Winline -Wall -Wpointer-arith -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wcomments -O0 -g -c -o desktop.o `test -f ../desktop.cc || echo '../'`../desktop.cc In file included from ../libgetopt++/include/getopt++/BoolOption.h:19, from ../desktop.cc:54: ../libgetopt++/include/getopt++/Option.h:25: #error string required make[2]: *** [desktop.o] Error 1 make[2]: Leaving directory `/prjz/cygwin/rt/src/cygwin-apps/setup/bld' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/prjz/cygwin/rt/src/cygwin-apps/setup/bld' make: *** [all] Error 2 It appears that the configure process missed setting HAVE_STRING. Earnie.
cygwin-apps-cvs missing from the Mail Lists page.
FYI. Earnie.
Re: Setup sources updated - cross compile or native OOTB.
Robert Collins wrote: Setup should now reliably cross compile or natively compile OOTB. Can I configure it from CVS without the autotools installed yet? PLEASE, put the autotools created files there! Earnie.
Re: 'redownload' aka download again and cygwin setup
I've used the redownload feature to reget a corrupted downloaded file. Not often, but it's worth saving the functionality. Earnie. Robert Collins wrote: Ok. Time for a straw poll. Please write back (to me or the list, your choice) whether you use the DELIBERATE 'download again' functionality of setup.exe or not. And if so, how often and for what purpose. This is to determine if certain functionality that -in essence- causes the 'accidental' redownloading of files in 'download only' mode. Both positive and negative answers are useful, but in the absence of any significant number of answers, I will assume that no-one uses the functionality. Unless there is a real user need for it, the functionality will be removed in the next setup.exe release. Rob
Re: ITP: netpbm
Corinna Vinschen wrote: On Sat, Apr 27, 2002 at 06:04:55PM -0400, Larry Hall (RFK Partners, Inc) wrote: But everyone will complain if they can't run the package after they install it. I think we should absolutely avoid the latter case. The former we can deal with as required. What's the problem in adding two files to the package: /etc/profile.d/netpbm.sh: PATH=$PATH:/usr/netpbm/bin export $PATH /etc/profile.d/netpbm.csh: set path = ( $path /usr/netpbm/bin ) Because I would `mv /usr/netpbm/bin/* /usr/bin/ rm -rf /usr/netpbm rm -f /etc/profile.d/netpbm*'. The point is, the extra path walks are expensive. Earnie.
Re: 'redownload' aka download again and cygwin setup
Robert Collins wrote: === - Original Message - From: Earnie Boyd [EMAIL PROTECTED] To: Robert Collins [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, April 29, 2002 9:32 PM Subject: Re: 'redownload' aka download again and cygwin setup I've used the redownload feature to reget a corrupted downloaded file. Not often, but it's worth saving the functionality. What sort of corruption? Too short, garbage data? I've never analyzed the corruption, it's fix was to download again. Earnie.
Re: Setup sources updated - cross compile or native OOTB.
Robert Collins wrote: === - Original Message - From: Earnie Boyd [EMAIL PROTECTED] To: Robert Collins [EMAIL PROTECTED] No, I simply want to get the latest versions from CVS and configure and make. I don't want the autotools installed. Why do you want to get these versions from CVS? I'm really trying to understand what you want to achieve that you can't at the moment. (And building from CVS without the autotools is a scenario that may accomplish many other goals, so please describe one of the *other* goals). At the moment, I just get the feeling that we have a philosophical difference on this matter, and that's in and of itself not sufficient cause to change my mind. 1) I want the bleeding edge from CVS. 2) I don't want to have to have autotools to configure it. 3) All the other sources.redhat.net packages do it that way. 4) Chris Faylor, has said that it should be that way. 5) No other answer will do, if you don't someone else will just have to. 6) Just do it, it hurts no one and makes everyone happy. 7) Philosophy has nothing to do with it, it's a psychological state of happiness. 8) What's the big deal with adding a few files to the CVS? Earnie.
Re: ITP: netpbm
Larry Hall (RFK Partners, Inc) wrote: At 07:44 AM 4/29/2002, Earnie Boyd wrote: -8- The point is, the extra path walks are expensive. Quite true. But I would say that Corinna's suggestion, from a strict technical perspective, makes netpbm in a different bin directory usable 'out-of-the-box' under Cygwin. If netpbm were going to be put in it's own bin directory, I would say that adding files like the ones Corinna suggests is an absolute requirement. Yes, but you missed the point. Go ahead, add something to the end of your PATH and execute it with strace. Then see how many times the pathing routines are called to search for a symlink. It's once for each directory listed in PATH and I mean each directory listed in the path name of the path list (E.G.: a PATH of /usr/local/bin:/bin:/usr/bin has six directories in it). And if someone has a symlink in PATH, it's called again to see if the file pointed to by the symlink is a symlink. Note, the coding is necessary for symlink simulation, but it's slows down time it takes to find the binary file to exec. Keep the binaries to the front of the PATH and put them in /bin. Earnie.
Re: ITP: netpbm
Robert Collins wrote: -Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 28, 2002 2:46 AM ... But cygwin is used on both NTFS and FAT... Which is the killer question: is adding a directory to the search path more or less of a performance hog than adding x-100 .exes and/or .dll's to the /usr/bin directory. And will the inevitable 'my dos script can't find netpbm foobar tool' questions be worth it? It be the reason I would want the binaries in /bin. I even remove the /usr/bin from the PATH. Watch how many extra calls to the path methods are generated via an strace output. You really want to avoid extra path walks based on PATH. Well my system32 directory here has 1971 files. Adding a coupla hundred optional files doesn't seem all that bad to me. Not in light of the path walk and path methods. And hey, if FAT is too slow, folk can always install the windows ext2 driver. Or upgrade to XP4HOME, NTFS is the file system. Earnie.
Re: setup changes to build standalone
Charles Wilson wrote:
Robert Collins wrote:
Yes. I even documented all this some time back on
http://www.cygwin.com/ml/cygwin-apps/2001-11/msg00634.html, but
predicatably enough, no patches where forthcoming. Probably due to the
complete lack of a prebuilt bz2lib for mingw (that my cursory searches
have looked for).
https://sourceforge.net/projects/mingwrep/
I don't know if the maintainers of this site are still maintaining it.
Paul Sokolovsky isn't active any longer and Stefan Jahn isn't a MinGW
developer. This is one of those projects that I wish weren't. OTOH,
https//sourceforge.net/projects/mingw/ would be willing to upload any
MinGW package if it followed the --prefix=/mingw --host=mingw32
packaging rules (which unfortunately aren't documented except in the
mingw-dvlpr archives) and that person was willing to maintain the
pacakge (would need a SF account and be listed as a MinGW developer).
I wonder if we need a mingw-libs package.
Yes, please, please, yes. I would really really love it if some of the
common libs (zlib, bz2lib, stdc++) where available in a setup.exe
installable pacakge.
Yes, I like this too -- but I'm nervous about it growing ridiculously
large. What if (eventually) setup.ini turns into XML? Do we put a
mingw build of libxml into 'mingw-libs'? How far does this go?
(visions of full{mingw}.exe)
OTOH, we've already discussed (and discarded, thank g-d) the idea of
(for instance) the zlib maintainer providing both a
cygwin-setup-installable zlib package (/usr/bin/cygz.dll,
/usr/lib/libz.[dll|a]) and a cygwin-setup-installable mingw-zlib package
(/usr/bin/mgwz.dll, /usr/lib/mingw/libz.[dll|a]). Ditto bzip2, libxml,
... we are not a mingw-porting factory.
This is good. IMO, there should be no binaries not dependent on
cygwin1.dll in the /bin a.k.a. /usr/bin and that the /bin and /usr/bin
directories be marked as --cygwin-executable. One reason for doing this
is that it speeds the execution process for spawning by avoiding win32
translations.
2) The above won't work in a cross build environment. You could say
CC='i686-pc-cygwin-gcc -mno-cygwin'..., I guess.
for cross compiles:
../setup/configure --host=i686-pc-mingw32 --build-i686-pc-linux
should do it (assuming a mingw32 cross compiler is present), or a
combination using the CC string you have above with the mingw host will
work too.
whatever happened to the idea of an official cygwin package, that
contained a true cygwin-host, mingw-target cross compiler? Didn't
somebody or other volunteer to provide that?
Oh, I thought about it sometime ago, I've been busy with MSYS and have
decided against my maintaining another package. Perhaps when Danny gets
3.1 up he can provide a Cygwin hosted Mingw32 targeted set of binaries.
I also remember a discussion on one of Cygwin's lists about using
scripts and symlinks to emulate this and may be the smartest way to go
about providing cross build emulation.
(Granted, we still need 'cygwin-gcc -mno-cygwin' for the self-hosting
feature of cygwin1.dll, but there's no real need to *require* cygwin-gcc
-mno-cygwin for setup.exe, now that setup has been moved out of the
winsup tree)
Well, if you had a mingw32-gcc (cygwin hosted, mingw32 targeted) then
you could use that instead of `gcc -mno-cygwin'.
anything that is non-simple. I haven't looked at it in a
while, though, so maybe things have changed.
It really depends on what you want to do. Some stuff it does
spectalularly well, some things it has trouble with. With the 'cross
compiling but not' approach, it would almost certainly have some trouble
:}.
see above, true cross compiler...
Or even the simulated with script and symlink one.
Earnie.
Re: setup changes to build standalone
Robert Collins wrote: d) a --with-cygwin-headers=/path/to/headers and in mount.cc pickup the needed headers. With a default of $(prefix)/include. Earnie.
Re: Minor bugfix for setup.exe - missing call to backslash() in desktop.cc
You can avoid this by attaching a file with a .txt suffix.
Earnie.
Max Bowsher wrote:
This adds a backslash() call to fix strange behaviour when creating the Cygwin
link on the start menu.
Currently, the link is created with name 'Programs/Cygwin/Cygwin Bash
Shell.lnk'. NB: those are slashes in the filename, not directory separators.
It's a minor bug, because once Windows notices this, it interprets the slashes,
and moves it into the intended directory structure - nevertheless, it would be
good to fix it. Accordingly, here are 1-liner patch and changelog. Patch is both
inline and attached for convenience, since it is so small.
My apologies for the ChangeLog not being indented properly - Outlook Express
eats tabs.
Max.
###BEGIN PATCH###
diff -mru cvssetup/desktop.cc setup/desktop.cc
--- cvssetup/desktop.cc Sun Mar 3 17:29:24 2002
+++ setup/desktop.cc Sun Mar 3 17:23:41 2002
@@ -143,7 +143,7 @@
static void
make_link (String const linkpath, String const title, String const target)
{
- String fname = linkpath + / + title + .lnk;
+ String fname = backslash(linkpath + / + title + .lnk);
if (_access (fname.cstr_oneuse(), 0) == 0)
return; /* already exists */
###END PATCH###
ChangeLog:
2002-04-26 Max Bowsher [EMAIL PROTECTED]
* desktop.cc (make_link): Add backslash() for fname, so link is created
in proper directory, rather than with slashes in its name.
Max.
Name: start-menu-shortcut-slashfix.patch
start-menu-shortcut-slashfix.patchType: unspecified type
(application/octet-stream)
Encoding: quoted-printable
Re: ITP: netpbm
Charles Wilson wrote: However, directories other than the root are unlimited in size (except by your patience, and vision) Given that, I think the usual /usr/bin directory should suffice. Earnie.
Re: strange source packaging?
Charles Wilson wrote: Robert Collins wrote: And the GPL requires us to document the changes made - if we have the patch pre-applied, with no reverse patch, then this isn't the case. Asking folk to go elsewhere to get that 'pristine' source puts the onus on the upstream to make that available, which we can't do - for the same reason that folk that ship cygwin1.dll need to host their own copy of the source. At the risk of wading into yet another GPL argument -- I don't think the GPL requires documentation of the entire provenance of changes relative to some external source; it's just the polite thing to do. All the GPL requires is that you distribute THE source that YOU used to build THE binary YOU distribute. That's it. Section 2.a You must cause the modified files to carry prominent notices stating that you chaned the files and the date of any change. /Section 2.a A differences file alone doesn't accomplish. You must state in the file header (a prominent place of notice) that you changed the file. Now how many of us do that? Instead we use a ChangeLog to note the changes to the files. The GPL itself doesn't give exception for this method. However, since the Copyright holder, Redhat, uses the ChangeLog method for file change notification then it can be argued that the Copyright holder gave the exception to the license so it can continue without change as far as Cygwin is concerned. But the FSF is the copyright holder the most of the other packages we distribute, have the changed files been given appropriate prominent notice? Back to the subject at hand, source packaging and the con to Robert's argument. I can in my wisdom download the individual binary and accompaning source. At that point I should be able to rebuild an exacting duplicate from the source package with supplied scripts found within the source package (autoconfiguration). Therefore having setup.exe perform any patches by downloading only the patch doesn't meet the criteria layed out by the GPL. Nice thought, but not workable within the wording of the GPL. Section 3, para. 5 These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. /Section 3, para 5 Earnie. _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: libtool devel package still dll crippled.
Danny Smith wrote: Todo: 2b) set an option like --export-libs=* or something else 2c) identify the libs to export and set an option like --export-libs=lib1,lib2, Do I need to refresh the patch I submitted to binutils many moons ago. It is useful its own right (building dlls without libtool magic). IIRC --export-libs=* won't work becasue of globbing problems. It needs to be something else like --export-libs=ALL Yes, I think so. Earnie. _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: [MinGW-dvlpr] Fwd: Updates to x86-Interix config files
Yes, so go for it. Earnie. Danny Smith wrote: I think that this (return 8 byte structures in registers) should also go in mingw32.h config file for GCC. I'm not sure about cygwin.h ldiv() returns an 8-byte structure. I can't think of any others, but if we're serious about compatability with MS object files, this would seema good thing. Danny --- Richard Kenner [EMAIL PROTECTED] wrote: Date: Fri, 12 Apr 02 15:46:22 EDT From: [EMAIL PROTECTED] (Richard Kenner) To: [EMAIL PROTECTED] Subject: Updates to x86-Interix config files I applied these to the 3.1 branch and the trunk. 2002-04-12 Douglas B Rupp [EMAIL PROTECTED] * config/i386/i386-interix.h (EH_FRAME_IN_DATA_SECTION): Define. (TARGET_ASM_NAMED_SECTION, RETURN_IN_MEMORY) Define. (DEFAULT_PCC_STRUCT_RETURN): Define as 0. * config/i386/t-interix (USER_H): Remove. snip *** config/i386/i386-interix.h16 Dec 2001 15:43:40 - 1.23 --- config/i386/i386-interix.h12 Apr 2002 19:41:42 - *** 422,423 --- 423,432 #define NO_IMPLICIT_EXTERN_C + /* MSVC returns structs of up to 8 bytes via registers. */ + + #define DEFAULT_PCC_STRUCT_RETURN 0 + + #undef RETURN_IN_MEMORY + #define RETURN_IN_MEMORY(TYPE) \ + (TYPE_MODE (TYPE) == BLKmode || \ + (AGGREGATE_TYPE_P (TYPE) int_size_in_bytes(TYPE) 8 )) http://messenger.yahoo.com.au - Yahoo! Messenger - A great way to communicate long-distance for FREE! ___ MinGW-dvlpr mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: libtool devel package still dll crippled.
Is there any real solution to this problem w.r.t. the current -devel version of libtool? Earnie. _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: xfree packages
Let's be real picky: XFree86-xserv-major.minor-portrelease.tar.bz2 is what is required for the binary release. XFree86-xserv-major.minor-portrelease-src.tar.bz2 is what is required for the source release. I've used xserv only as an example scenario and I'm not picking on it specifically. Earnie. Harold Hunt wrote: Yes, we try to keep things regularized around here, so XFree86 is the way that the package names need to be spelled. Also, I request that you keep the XFree86-xserv package, as that will allow us to realize the immediate benefit of being able to release the Test-** server or updates to the stable server as small downloads that everyone can keep up to date with. Thanks for you great work, Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher Faylor Sent: Wednesday, April 10, 2002 1:35 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: xfree packages On Tue, Apr 09, 2002 at 09:40:46PM -0700, Ian Burrell wrote: I finished making some xfree packages. They are distributed binary archives repackaged as cygwin packages. I made a package directory that can be used with setup.exe from a local directory and over the network. I changed my mind about the division of the packages I proposed. I got rid of the multiple doc and fonts packages cause I was having trouble with the naming and directories. Plus, I assumed the people would want to install them together. The packages are now: xfree-base xfree-devel xfree-docs xfree-fonts xfree-xfs xfree-xnest xfree-xvfb xfree-xprt I don't have a machine that people can easily download the full files from. I can post the setup.* files and scripts I used to build the packages. Yes, please post the setup.hint files that you used. I think that these files should be called XFree86-base (or just XFree86), etc. The project is the Cygwin/XFree86 project and I think the package names should reflect that. cgf _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: w32api update?
Charles Wilson wrote: So I just updated my local mirror and discovered that somebody unpacked the entire w32api package onto sourceware: cygwin/latest/w32api/hold/w32api-1.3-2/* What's that all about? Shouldn't that stuff be kept out of the mirrored anonftp area? FWIW, I didn't create this. I'll check the area. Earnie. _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: w32api update?
Earnie Boyd wrote: Charles Wilson wrote: So I just updated my local mirror and discovered that somebody unpacked the entire w32api package onto sourceware: cygwin/latest/w32api/hold/w32api-1.3-2/* What's that all about? Shouldn't that stuff be kept out of the mirrored anonftp area? FWIW, I didn't create this. I'll check the area. So who redid my packages and what was wrong with the originals? Earnie. _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: w32api update?
Christopher Faylor wrote: On Wed, Apr 10, 2002 at 03:08:09PM -0400, Earnie Boyd wrote: FWIW, I didn't create this. I'll check the area. So who redid my packages and what was wrong with the originals? http://sources.redhat.com/ml/cygwin/2002-04/msg00526.html Thanks, Earnie. _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: w32api release anytime soon?
I'm shooting for the end of the week. Earnie. Christopher Faylor wrote: We really need a new w32api release soon. Are there any plans to release one? The last release seems to have been in December of 2001 and there have been many changes since then. cgf _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: Proprietary Software [WAS: Re: SGML/XML packages available for testing]
Stanislav Sinyagin wrote: Hi Markus, I am using these distributions in my propriatory software: Your proprietary software will need to have a GPL license if it uses any library compiled with Cygwin1.dll dependencies. Your proprietary software will need to have a GPL license if it uses any library that is itself covered by the GPL unless special clauses are given such as is in the LGPL. Any LGPL library that incorporates a GPL library is itself covered by the GPL regardless of the stated special clauses. Cygwin has a special use clause that allows you to use any Open Source approved license on your software without causing that source to need to be GPL licensed. That special use clause is not promoted to proprietary software. There may still be a license you can purchase to use with your proprietary software, see http://www.redhat.com for more information on where to find information on how to purchase that license. Earnie. _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: pager in default install
Charles Wilson wrote: Lame followup to my own post: I think we should have A 'more' package for this reason: Q: Where's more? A: In the 'more' package. makes a lot more sense than Q: Where's more? A: Use less instead. It's better. BTW, you'll probably need to set PAGER=less. Oh, and NCFTP_PAGER=less. (Okay, that last one is an exagerration. Actually, the ncftp code has a special cygwin hack so that on cygwin, ncftp uses less by default. Other platforms use more by default. But you get the idea.) And it should be a base package. Earnie. _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: why w32api-1.2-1 is broken in setup 2.194.2.15
Thanks, Chris. I won't be able to take a look at a new package until mid April. Earnie. Christopher Faylor wrote: On Thu, Mar 21, 2002 at 04:59:06PM -0800, Michael A Chase wrote: I've installed all packages except postgres. The only packages I have with the leading './' are opengl and w32api. Thanks for the detective work, everybody. I've repackaged w32api and opengl. I've also reestablished the latest version of setup.exe. This is definitely something that needs to be fixed, though, obviously. cgf _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: Keeping base, adding standard.
Has my vote. Earnie. Christopher Faylor wrote: Now that we have clickable categories, I think we should consider not making Base the default installation, defaulting to something like Standard instead. Standard would include things like: base + bzip2 bash clear tcsh less vim telnet ssh cygrunsrv mutt perl? python? shutdown? ssmtp unzip zip The rationale is that people can still select a minimal install with base but still choose a usable setup with Standard. How does this sound? cgf _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
