Re: Bogus hostname forcing in RedHat source RPMS

Re: Bogus hostname forcing in RedHat source RPMS

[Earnie Boyd]

--- "Charles S. Wilson" <cwilson@ece.gatech.edu> 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:
> 

I would like to also add that discussions of RPM is OT for this list.

Cheers,

=====
Earnie Boyd
mailto:earnie_boyd@yahoo.com

---         < http://earniesystems.safeshopper.com >         ---
--- Cygwin: POSIX on Windows < http://gw32.freeyellow.com/ > ---
---   Minimalist GNU for Windows < http://www.mingw.org/ >   ---

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Bogus hostname forcing in RedHat source RPMS

[Stephen C. Biggs]

On 18 Dec 2000, at 5:57, Earnie Boyd wrote:

> --- "Charles S. Wilson" <cwilson@ece.gatech.edu> 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:
> > 
> 
> I would like to also add that discussions of RPM is OT for this list.

I agree, but this isn't about RPM, rather RPM as it relates to porting 
it to cygwin, and that IS on topic for this list, no?

> 
> Cheers,
> 
> =====
> Earnie Boyd
> mailto:earnie_boyd@yahoo.com
> 
> ---         < http://earniesystems.safeshopper.com >         ---
> --- Cygwin: POSIX on Windows < http://gw32.freeyellow.com/ > ---
> ---   Minimalist GNU for Windows < http://www.mingw.org/ >   ---
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of Products.
> http://shopping.yahoo.com/



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Bogus hostname forcing in RedHat source RPMS

[Stephen C. Biggs]

On 18 Dec 2000, at 20:28, Evan McLean wrote:

> 
> On Sun, 17 Dec 2000 18:36:25 -0800, Stephen C. Biggs wrote:
> >Why can't cygwin be Unix??
> 
> How much windows programming have you done?  :-)

Not enough to know better, and too much to ever feel clean again ;-)
> 
> Perhaps the statement "Cygwin is not Unix" could be more accurately 
> expanded to "Cygwin is a close to a Unix-like environment that is possible 
> under Microsoft Windows, but no more so."
> 
> As a reasonably seasoned programmer on both, I find the Cygwin developers' 
> (of which I am not one) success in inveigling windows rather impressive.
> 
> (Not to mention their patience on the mailing lists, which I personally 
> find remarkably impressive.)
> 
> And if that is not enough, consider the following quote (source unknown):
> 
> "You can't let people get away with shoddy service.  It starts with 
> overcooked meat and ends with Microsoft."
> 
> E. (Trying to help put things in perspective.)
> 
> 
> --
> 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

Re: Bogus hostname forcing in RedHat source RPMS

[Earnie Boyd]

--- "Stephen C. Biggs" <s_c_biggs@bigfoot.com> wrote:
> about are strictly Linux, or hopefully POSIX compatible, then the 
> _WIN32 ifdefs shouldn't be an issue... if they are, then, oh well.
> 

CC='gcc -mno-win32' configure ... will cause _WIN32 to be undefined.

Cheers,

=====
Earnie Boyd
mailto:earnie_boyd@yahoo.com

---         < http://earniesystems.safeshopper.com >         ---
--- Cygwin: POSIX on Windows < http://gw32.freeyellow.com/ > ---
---   Minimalist GNU for Windows < http://www.mingw.org/ >   ---

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Bogus hostname forcing in RedHat source RPMS

[Evan McLean]

On Sun, 17 Dec 2000 18:36:25 -0800, Stephen C. Biggs wrote:
>Why can't cygwin be Unix??

How much windows programming have you done?  :-)

Perhaps the statement "Cygwin is not Unix" could be more accurately 
expanded to "Cygwin is a close to a Unix-like environment that is possible 
under Microsoft Windows, but no more so."

As a reasonably seasoned programmer on both, I find the Cygwin developers' 
(of which I am not one) success in inveigling windows rather impressive.

(Not to mention their patience on the mailing lists, which I personally 
find remarkably impressive.)

And if that is not enough, consider the following quote (source unknown):

"You can't let people get away with shoddy service.  It starts with 
overcooked meat and ends with Microsoft."

E. (Trying to help put things in perspective.)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Bogus hostname forcing in RedHat source RPMS

[Stephen C. Biggs]

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

Re: Bogus hostname forcing in RedHat source RPMS

[Charles S. Wilson]

"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.

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'.)

--Chuck

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Bogus hostname forcing in RedHat source RPMS

[Stephen C. Biggs]

Trying to install (rpm --rebuild) libtool from source rpm downloaded 
from ftp.redhat.com bombs because it looks like the SPEC file is 
trying to force an invalid host type (i386-pc-cygwin_nt-4.0 when it 
SHOULD be i686-pc-cygwin) if it sees CYGWIN.

Going to the source directory of the installed code and running 
./configure (with everything but the hostname) and make/make 
install works just fine.

This seems to be the case for all of the source rpms (?) (I tried two, 
libtool and grep).

I really know nothing about how to use RPM except for the basic 
stuff, so if there is a way to override this host name forcing, please 
advise.

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.

Output from my attempt.

$ rpm --rebuild libtool-1.3.5-8.src.rpm
Installing libtool-1.3.5-8.src.rpm
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.70003
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd /usr/src/redhat/BUILD
+ rm -rf libtool-1.3.5
+ /bin/gzip -dc /usr/src/redhat/SOURCES/libtool-1.3.5.tar.gz
+ tar -xf -
+ STATUS=0
+ [ 0 -ne 0 ]
+ cd libtool-1.3.5
+ /bin/id -u
+ [ 500 = 0 ]
+ /bin/id -u
+ [ 500 = 0 ]
+ /bin/chmod -Rf a+r,g-w,o-w .
+ echo Patch #1 (libtool-1.2f-cache.patch):
Patch #1 (libtool-1.2f-cache.patch):
+ patch -p1 -s
+ echo Patch #2 (libtool-1.3.5-mktemp.patch):
Patch #2 (libtool-1.3.5-mktemp.patch):
+ patch -p1 -s
+ echo Patch #3 (libtool-1.3.5-nonneg.patch):
Patch #3 (libtool-1.3.5-nonneg.patch):
+ patch -p1 -s
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.56589
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd libtool-1.3.5
+ CFLAGS=-O2 -march=i386 -mcpu=i686
+ export CFLAGS
+ CXXFLAGS=-O2 -march=i386 -mcpu=i686
+ export CXXFLAGS
+ FFLAGS=-O2 -march=i386 -mcpu=i686
+ export FFLAGS
+ [ -f configure.in ]
+ /bin/true --copy --force
+ ./configure i386-pc-cygwin_nt-4.0 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/usr/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/usr/var --shareds
tatedir=/usr/com --mandir=/usr/man --
infodir=/usr/info
configure: warning: i386-pc-cygwin_nt-4.0: invalid host type
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking whether the C compiler (gcc -O2 -march=i386 -mcpu=i686 ) works... yes
checking whether the C compiler (gcc -O2 -march=i386 -mcpu=i686 ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for ranlib... ranlib
checking host system type... Invalid configuration `i386-pc-cygwin_nt-4.0': machine `i386-pc-cygwin_nt' not recognized

checking build system type... Invalid configuration `i386-pc-cygwin_nt-4.0': machine `i386-pc-cygwin_nt' not recognized

checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking for mawk... no
checking for gawk... gawk
updating cache ./config.cache
creating ./config.status
creating Makefile
creating doc/Makefile
creating tests/Makefile
configuring in libltdl
running /bin/sh ./configure  i386-pc-cygwin_nt-4.0 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/usr/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/us
r/var --sharedstatedir=/usr/com --mandir=/u
configure: warning: i386-pc-cygwin_nt-4.0: invalid host type
loading cache .././config.cache
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... (cached) gcc
checking whether the C compiler (gcc -O2 -march=i386 -mcpu=i686 ) works... yes
checking whether the C compiler (gcc -O2 -march=i386 -mcpu=i686 ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for working const... yes
checking for inline... inline
checking host system type... Invalid configuration `i386-pc-cygwin_nt-4.0': machine `i386-pc-cygwin_nt' not recognized

checking build system type... Invalid configuration `i386-pc-cygwin_nt-4.0': machine `i386-pc-cygwin_nt' not recognized

checking for ranlib... (cached) ranlib
checking for ld used by GCC... (cached) /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... (cached) yes
checking for BSD-compatible nm... (cached) /usr/bin/nm -B
checking whether ln -s works... (cached) yes
updating cache .././config.cache
loading cache .././config.cache within ltconfig
ltconfig: you must specify a host type if you use `--no-verify'
Try `ltconfig --help' for more information.
configure: error: libtool configure failed
configure: error: ./configure failed for libltdl
Bad exit status from /var/tmp/rpm-tmp.87149 (%build)

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple