Re: usr/include/ndbm.h duplicate in cygwin-1.3.11-2

[Charles Wilson <cwilson@ece.gatech.edu>]

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/