This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [ITP] man-db
- From: "Chris J. Breisch" <chris dot ml at breisch dot org>
- To: cygwin-apps at cygwin dot com
- Date: Mon, 02 Jun 2014 11:36:02 -0400
- Subject: Re: [ITP] man-db
- Authentication-results: sourceware.org; auth=none
- References: <537B8560 dot 1030607 at breisch dot org> <20140521084704 dot GJ2357 at calimero dot vinschen dot de> <67e0aaacd3c8cef9628de6425fc07169 at xs4all dot nl> <537D44B4 dot 7060901 at breisch dot org> <53889412 dot 2060000 at breisch dot org> <5388C0A9 dot 7040301 at users dot sourceforge dot net> <538BBDCF dot 3070407 at users dot sourceforge dot net>
I replied to this off-list accidentally.
Yaakov (Cygwin/X) wrote:
> On 2014-05-30 12:32, Yaakov (Cygwin/X) wrote:
>> I started reviewing this, see inline.
>
> My modifications can be found here:
>
> https://sourceforge.net/p/cygwin-ports/man-db/
>
>> On 2014-05-30 09:22, Chris J. Breisch wrote:
>>> Still, I've put up a new set of files, now. I eliminated the library
>>> package for a few reasons.
>>> 1) The libraries can't be compiled into DLL's without some effort.
>>> They appear to have unresolved references.
>>
>> I'm looking into this.
>
> There are two issues here:
>
> 1) The "undefined symbols not allowed in $host shared libraries" warning
> just means that you need to add -no-undefined to *_la_LDFLAGS. In fact,
> that's the only issue with making libman shared. (See my
> 2.6.7-shared-libman.patch)
>
> 2) OTOH, libmandb also depends on two global variables which are meant
> to be defined by executables. In order to make this shared, the global
> declarations need to be moved to libmandb itself, while the executables
> still define their values, making for a somewhat larger patch. (See my
> 2.6.7-shared-libmandb.patch)
Yes, it figures. I had looked into libmandb, not libman. And had noticed
this, so I never went any farther.
>
> This latter patch may be harder to carry from one version to the next,
> and if another executable is added which depends on libmandb and you
> forget to adapt it accordingly, it will crash. So I'm actually going to
> suggest that you NOT use the latter, and leave libmandb static (which is
> the smaller of the two anyway).
Makes sense to me.
>
>>> 2) There's no simple set of include files related to just the
>>> libraries. I could put out all of the includes, but it looks to me
as if
>>> that would get messy rather quickly.
>>
>> These libraries are private, that's why no headers are installed. The
>> libraries are shared just to save space by not duplicating the same
>> objects in all the binaries.
>
> This stands; there should be neither a -libs nor -devel subpackage.
>
>>> I also updated the postinstall and preremove scripts to handle creation
>>> and removal of the database.
>
> I made some changes to these, but I'm wondering if we need a special
> _update-mandb package (similar to _update-info-dir) to manage this
> instead. Thoughts?
Possibly. It would not be a bad idea for the database to updated when
new packages are installed. However, it looks like to me that
update-info-dir wipes and recreates the info files. It's rather time
consuming to create the initial mandb database, and I'd be hesitant
about doing that every time someone installs something. Perhaps I'm
misunderstanding what you're suggesting.
>
>>> This being my first attempt, I'm sure I've done something wrong. Just
>>> let me know what it is and I'll fix it promptly (and it actually should
>>> be promptly this time as my crisis is now under control).
>
> Other changes I made:
>
> * Use explicit --with-browser and --with-pager flags to not be affected
> by builder's environment (e.g., on my system BROWSER=epiphany , and
> added these to REQUIRES.
Ok.
>
> * po4a is a build requirement for localized manpages of man itself; I
> just added this to the 64-bit distribution, and will attempt to do so
> soon for the 32-bit distribution as well.
>
Ok
> Please review the changes I made in my .cygport, let me know if you have
> any questions.
>
I think this looks good. I'll see about producing another build in the
morning using these patches. I'm away from the machine I've been
building from at the moment.
>
> Yaakov
>
Thanks, Yaakov. This has been a big help.
--
Chris J. Breisch