From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12600 invoked by alias); 24 Jun 2002 14:16:00 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 12588 invoked from network); 24 Jun 2002 14:15:58 -0000 Received: from unknown (HELO katrina.ibb.gatech.edu) (128.61.131.14) by sources.redhat.com with SMTP; 24 Jun 2002 14:15:58 -0000 Received: from ece.gatech.edu (ibb-429.ibb.gatech.edu [128.61.133.79]) by katrina.ibb.gatech.edu (8.11.6/8.11.6) with ESMTP id g5OEEre14740; Mon, 24 Jun 2002 10:14:53 -0400 (EDT) Message-ID: <3D17299B.9020801@ece.gatech.edu> Date: Mon, 24 Jun 2002 10:01:00 -0000 From: Charles Wilson 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 CC: cygwin@cygwin.com Subject: Re: usr/include/ndbm.h duplicate in cygwin-1.3.11-2 References: <20020624110004.31704.qmail@web21001.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg01227.txt.bz2 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/