Mail Archives: cygwin/2001/07/16/20:20:53
[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/
- Raw text -