Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <3B5384C0.903@ece.gatech.edu>
Date: Mon, 16 Jul 2001 20:20:16 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0
MIME-Version: 1.0
To: Jason Tishler <Jason DOT Tishler AT dothill DOT com>
CC: gvv AT techie DOT com, cygwin AT cygwin DOT com
Subject: Re: rpm 4.0.2 Build Problem (was Re: Installing Berkeley DB 3.2.9)
References: <20010716165559 DOT I614 AT dothill DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

[side note: CC'ed to Gary Vaughn because there's a short listing of 
cygwin-related errata in the goat book at the bottom of this email.]

Jason Tishler wrote

> On Fri, Jul 13, 2001 at 03:15:26PM -0400, Charles S. Wilson wrote:
> 
>> Jason Tishler wrote:
>> 
>>> Note that the current version does the same thing that your 2.7.7 did.
>>> 
>>> Unfortunately, the rpm source has hardcoded constructs such as:
>>> 
>>>     #include <db3/db.h>
>> 
>> Since rpm is more-or-less maintained by Red Hat, I wouldn't be surprised 
>> if the official rpm source code depended on the installed structure of 
>> the db3/db2/db1 libraries under Red Hat's "harmonization".
>> 
>> 
>>> I was able to workaround this problem with mkdirs and symlinks, but I did
>>> this after configure.  Possibly by not having the environment "correct"
>>> before I ran configure caused rpm to configure itself improperly.
>> 
>> Absolutely.  If you rearrange your directory structure between 
>> "configuring" and "making" stuff will definitely break.
> 
> 
> I followed your advice and read the spec file from the Red Hat db 3.2.9
> RPM.  I used the information gleaned to post process make install to
> match the harmonization mentioned above.  Then I reran configure on rpm.
> Finally, after some head banging I managed to "build" rpm.

Wow.  That's great -- and a lot of work, I'll bet.  Muchas gracias.

 
> It appears that the rpm (4.0.2) package is very Linux centric. 

Yep.  More Red Hat-edness, I think.

> I will
> entertain posting a patch once I figure out the right way to correct all
> of the issue.  I guess that it is time to learn automake.  Sigh...

See the goat book: http://sources.redhat.com/autobook/ if you haven't 
already done so. Chapter 25: Using GNU Autotools with Cygnus Cygwin is 
especially interesting (if slightly out-of-date (*)).

 
> BTW, the test suite also seems very Linux centric -- hardcoded paths,
> expected output such as "ld-linux.so.2", etc.  Did you every try to run
> the test suite for your rpm 3.0.3 package? 

Nope.  (Did rpm-3.x HAVE a test suite?) My testing was empirical:
   a) build an rpm
   b) install the rpm
    Q: manually check and see that everything got installed to the right 
place, and that pre/post-install scripts were run.
   c) erase the rpm
    Q: manually check that everything got removed, and that 
pre/post-uninstall scripts were run.
   d) randomly try a few interdependent rpm's.  Make sure dependencies 
work properly.  do a bunch of 'rpm -q' stuff.

That's all I ever did.  Remember, I built cygwin-rpm for a VERY narrowly 
defined purpose: I wanted the users of my cygwin-perl to be able to 
install RPM's of perl modules independently.  Since perl modules have 
interdependencies, I couldn't just do tarballs.  So: rpm.

That is, the purpose for which I built and provided rpm "back in the 
day" was not very taxing.  It didn't use many of the more esoteric 
features of rpm -- and it was based on the simpler 3.x rpm program/format.

--Chuck

(*) e.g. the goat book was current as of cygwin-1.1.1, which was 
released on May 14, 2000.  Many things have changed (for the better) 
since then.
   1) -mno-cygwin now links against msvcrt.dll, not crtdll.dll
   2) cygutils.netpedia.net is defunct; it died without warning during 
December 2000 and the domain sold off to "elipse communications".  I 
couldn't even log in; fortunately I keep backups.  The new location is 
http://www.neuro.gatech.edu/users/cwilson/cygutils/  -- but it isn't 
necessary to go there for perl, since perl can now be downloaded from 
the normal cygwin mirrors using setup.exe.  Ditto autoconf.  Ditto ditto 
automake.
   3) HOWEVER -- since automake, autoconf, and libtool all share the 
same ac-local directory, and since the "official" cygwin versions of 
automake and autoconf now install under /usr (not /usr/local), your 
libtool must also be built to install into /usr if it is to interoperate 
with the official auto[make|conf] packages.  (The older cygutils 
versions of those packages installed into /usr/local, so the goat book 
sez to install libtool into /usr/local.  This is now incorrect.)
   4) CYGWIN=binmode doesn't do what the goat book sez it does.
   5) mount output now looks different.
   6) I don't even want to discuss the DLL stuff.  It's changing 
rapidly, anyway.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/