This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Bogus hostname forcing in RedHat source RPMS


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]