Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com> List-Archive: <http://sources.redhat.com/ml/cygwin/> List-Post: <mailto:cygwin AT sources DOT redhat DOT com> List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs> Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com From: "Stephen C. Biggs" <s_c_biggs AT bigfoot DOT com> To: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>, cygwin <cygwin AT cygwin DOT com> Date: Sun, 17 Dec 2000 18:36:25 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Bogus hostname forcing in RedHat source RPMS Reply-to: s_c_biggs AT bigfoot DOT com Message-ID: <3A3D07A9.11940.D6F24F@localhost> In-reply-to: <3A3D6FC7.F616BB82@ece.gatech.edu> X-mailer: Pegasus Mail for Win32 (v3.12c) On 17 Dec 2000, at 21:00, Charles S. Wilson wrote: > "Stephen C. Biggs" wrote: > > > > This is a real shame, if there is no way to override the bogus > > hostname, because, with my port for RPM 4.0, cygwin users can > > rebuild and use almost all of the nifty Linux tools that redhat has. > > I hate to burst your bubble, but cygwin is not linux. The only packages > for which your statement is true, are those that have already been > ported to work with cygwin, or you get lucky (see below). It just ain't > as simple as: > > Oh look, a 'foobar' package. > download. > unpack > ./configure > make > make install > > (which is basically what rpm will do when you use it to rebuild a > package based on some random linux-ish spec file.) > > This will only work if: > > a) the program doesn't run afoul of any of the windows-isms in cygwin > b) and doesn't attempt to use linux-ish functions that have not yet been > implemented in cygwin > c) doesn't have any extraneous '#ifdef _WIN32' blocks that REALLY maen > 'true windows-native' but get tripped by cygwin's use of that #define. > > Now, you *might* get lucky and satisfy these requirements with some new, > random package -- but probably not. If it attempts to use a Linux-ish function, then it shouldn't build because it won't be in the library, or if it is and is not implemented properly then it is a cygwin bug... Since the packages I am talking about are strictly Linux, or hopefully POSIX compatible, then the _WIN32 ifdefs shouldn't be an issue... if they are, then, oh well. I believe that I have gotten "lucky" because I was able to compile the vanilla apache-1.3.14 tarball out of the box with only one minor change (they were using #ifndef h_errno (??) and I just placed an #ifndef __CYGWIN__ block around the extern int h_errno), and it seems to run... I can get web hits, and I verified it from someone at a different site with their Internet connection. A really really pretty cool verification of the tools. I also seem to be able to compile, install and use bind-8.2.2- patchlevel-7 out of the box... with, again, some very minor changes and a porting directory for cygwin. I am going to try to do the same for INN and see if I, again, get lucky :) > > So you shouldn't be surprised that some packages fail to build with a > simple 'rpm --rebuild' With regards to the particular package you > reference, libtool, note that there is ongoing work to cygwin-ify > libtool, and get it to work with dll's and the latest cygwin > gcc/binutils -- search the cygwin mailing list archives for 'Gary > Vaughan'.) Ok... but it seems to me, the statement "cygwin is not Unix" notwithstanding, that cygwin IS Unix to a very great degree... Libtool seems to run on my machine, altho it, of course, won't deal with dlls since Unix never heard of them... It seems to me that a lot of this porting is unneeded effort if you have the basic (and not so basic) POSIX emulation in place... You should be able to plug and play vanilla POSIX compatible packages. Why go to all the effort of using dll's at all? Once you have the basic cygwin emulation dll in place, all else can run as if it was on a Unix box (except for bogosities in Win98, etc... I am running NT 4.0 workstation, so I don't have this issue...) Why can't cygwin be Unix?? > > --Chuck > > -- > Want to unsubscribe from this list? > Check out: http://cygwin.com/ml/#unsubscribe-simple > -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple