delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2002/06/24/10:16:47

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3D17299B.9020801@ece.gatech.edu>
Date: Mon, 24 Jun 2002 10:15:55 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Nicholas Wourms <nwourms AT yahoo DOT com>
CC: cygwin AT cygwin DOT com
Subject: Re: usr/include/ndbm.h duplicate in cygwin-1.3.11-2
References: <20020624110004 DOT 31704 DOT qmail AT web21001 DOT mail DOT yahoo DOT com>

Nicholas Wourms wrote:

> It looks to me like it is db-1, not db-3...  There are /way/ too few
> source files for it to be the latter.  This is, of course, highly
> annoying.  Most linuxs come with the berkeley db, and now Cygwin does as
> well. 


Not really.  The routines are there, and the header file -- but since 
the cygwin DLL doesn't export the routines, they effectively do not 
exist.  Which means there's no need for cygwin to ship the headers at all.

> It doesn't make sense for them to clobber an existing db.h, it
> should be segregated in a libc-only header folder.


Probably, and then distribution managers can symlink or copy as 
necessary; perhaps the newlib folks would agree to something like this. 
  However, we (cygwin) have a distributed set of distribution managers 
-- so we, collectively, have to decide which db.h gets put into 
/usr/include -- the one from newlib/cygwin (which seems rather pointless 
unless the DLL begins exporting the necessary symbols) or the symlink 
magic from your family of berkeley db packages.

>  Either that, or like
> glibc, keep db as an external dependancy. 


I doubt they will revert to that -- it is valuable on embedded systems 
to have database routines, like the POSIX(?) db(3) family, in the 
runtime.  And since newlib is primarily targetted at embedded systems...

> *Sigh*, Chuck I guess I'll have
> to figure out a new strategy for releasing the other Berkely DB's... 


Don't panic.  Let's see what cgf has to say about the issue, esp. with 
regards to cygwin exporting/not-exporting the db symbols in the future.

> If
> some kind soul who works for the crimson hat might confer with the newlib
> folks regarding this situation, it would be most appreciated.  Meanwhile,
> be aware that the db-2 packages will clobber cygwin-1.3.11 files and
> vis-versa...


Hopefully Chris will release 1.3.11-4 *without* /usr/include/db.h as a 
short-term, interim fix.

You know, we *really* need a package linter that checks for file 
conflicts -- of course, it wouldn't have caught the db.h problem, since 
db.h is created by a symlink during postinstall in your berkeley db 
packages...

--Chuck


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


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019