How does Cygwin handle non-Latin1 man pages? (move to UTF-8?)

How does Cygwin handle non-Latin1 man pages? (move to UTF-8?)

[Erwin Waterlander]

Hi,

As far as I see it, on Cygwin it is assumed that man pages are encoded 
in Latin-1 (ISO-8859-1).
For instance the man pages of vim.

/usr/share/man/fr/vim.1.gz is encoded in Latin-1.

$ export LANG=fr_FR.UTF-8
$ man vim

This will show the French man page correctly. Latin-1 is converted to UTF-8.

For the Russian translation of the vim manual I see two files:
/usr/share/man/ru.UTF-8/man1/vim.1.gz
/usr/share/man/ru.KOI8-R/man1/vim.1.gz


When I type
$ export LANG=ru_RU.UTF-8
$ man vim

I get the English man page, instead of the Russian man page.
I think because there is no /usr/share/man/ru/man1/vim.1.gz present.

When I type

$ export LANG=ru_RU.UTF-8
$ export LANGUAGE=ru.UTF-8
$ man vim

The Russian man page is displayed, but all Russian characters are 
wrongly displayed.
I think because it is assumed the man page is in Latin-1.

To get a correct display of the Russian man page I need to change 
/etc/man.config
I change the line with NROFF to:
NROFF         /usr/bin/preconv | /usr/bin/nroff -c -mandoc 2>/dev/null

Now the Russian man page displays correctly, but now all the Latin-1 
pages display wrongly.

So I undo my change in /etc/man.conf


On Linux the trend is to convert all man pages to UTF-8 encoding.
Will Cygwin follow this trend?

regards,

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: How does Cygwin handle non-Latin1 man pages? (move to UTF-8?)

[Erwin Waterlander]

Erwin Waterlander schreef, Op 24-9-2013 22:01:
> Hi,
>
> As far as I see it, on Cygwin it is assumed that man pages are encoded 
> in Latin-1 (ISO-8859-1).
> For instance the man pages of vim.
>
> /usr/share/man/fr/vim.1.gz is encoded in Latin-1.
>
> $ export LANG=fr_FR.UTF-8
> $ man vim
>
> This will show the French man page correctly. Latin-1 is converted to 
> UTF-8.
>
> For the Russian translation of the vim manual I see two files:
> /usr/share/man/ru.UTF-8/man1/vim.1.gz
> /usr/share/man/ru.KOI8-R/man1/vim.1.gz
>
>
> When I type
> $ export LANG=ru_RU.UTF-8
> $ man vim
>
> I get the English man page, instead of the Russian man page.
> I think because there is no /usr/share/man/ru/man1/vim.1.gz present.
>

The problem is here that man looks for the manual in these directories 
in this order:
/usr/share/man/ru_RU.UTF-8
/usr/share/man/ru_RU
/usr/share/man/ru

All three paths are not present on Cygwin.
I could set LANG to ru.UTF-8, but this is not common practice. Normally 
you set LANG to ru_RU.UTF-8. Therefore I think that the non-Latin1 
folders under /usr/share/man have the wrong name.
When I set LANG to ru.UTF-8, man finds the Russian man page, but 
displays it wrongly. Even when I fix the NROFF line in /etc/man.conf.
Moving /usr/share/man/ru.UTF-8 to /usr/share/man/ru_RU.UTF-8 (and fixing 
man.conf) makes the man page display properly. This confirms that the 
non-latin1 directories have the wrong name in Cygwin.

> When I type
>
> $ export LANG=ru_RU.UTF-8
> $ export LANGUAGE=ru.UTF-8
> $ man vim
>
> The Russian man page is displayed, but all Russian characters are 
> wrongly displayed.
> I think because it is assumed the man page is in Latin-1.
>
> To get a correct display of the Russian man page I need to change 
> /etc/man.config
> I change the line with NROFF to:
> NROFF         /usr/bin/preconv | /usr/bin/nroff -c -mandoc 2>/dev/null
>
> Now the Russian man page displays correctly, but now all the Latin-1 
> pages display wrongly.

This can be fixed by adding a coding tag to the first or second line of 
the man page, which is understood by preconv.
When I set LANG to fr_FR.UTF-8, move /usr/share/man/fr.UTF-8 to 
/usr/share/man/fr_FR.UTF-8, and add this tag to vim.1

.\" -*- coding: latin-1; -*-

The French manual displays properly.


>
> So I undo my change in /etc/man.conf
>
>
> On Linux the trend is to convert all man pages to UTF-8 encoding.
> Will Cygwin follow this trend?
>
>

The following needs to be done in Cygwin to have man pages for all 
scripts displayed properly out of the box (assuming an UTF-8 locale and 
use of mintty):

* Rename the non-latin1 directories under /usr/share/man/ to 
fr_FR.UTF-8, ru_RU.UTF-8, and so on.
* Change /etc/man.conf to use preconv:
NROFF         /usr/bin/preconv | /usr/bin/nroff -c -mandoc 2>/dev/null
* Convert all Latin-1 coded man pages to UTF-8, or add a latin-1 coding 
tag on the first line.

regards,

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: How does Cygwin handle non-Latin1 man pages? (move to UTF-8?)

[Erwin Waterlander]

Erwin Waterlander schreef, Op 25-9-2013 21:50:
>
> Erwin Waterlander schreef, Op 24-9-2013 22:01:
>> Hi,
>>
>> As far as I see it, on Cygwin it is assumed that man pages are 
>> encoded in Latin-1 (ISO-8859-1).
>> For instance the man pages of vim.
>>
>> /usr/share/man/fr/vim.1.gz is encoded in Latin-1.
>>
>> $ export LANG=fr_FR.UTF-8
>> $ man vim
>>
>> This will show the French man page correctly. Latin-1 is converted to 
>> UTF-8.
>>
>> For the Russian translation of the vim manual I see two files:
>> /usr/share/man/ru.UTF-8/man1/vim.1.gz
>> /usr/share/man/ru.KOI8-R/man1/vim.1.gz
>>
>>
>> When I type
>> $ export LANG=ru_RU.UTF-8
>> $ man vim
>>
>> I get the English man page, instead of the Russian man page.
>> I think because there is no /usr/share/man/ru/man1/vim.1.gz present.
>>
>
> The problem is here that man looks for the manual in these directories 
> in this order:
> /usr/share/man/ru_RU.UTF-8
> /usr/share/man/ru_RU
> /usr/share/man/ru
>
> All three paths are not present on Cygwin.
> I could set LANG to ru.UTF-8, but this is not common practice. 
> Normally you set LANG to ru_RU.UTF-8. Therefore I think that the 
> non-Latin1 folders under /usr/share/man have the wrong name.
> When I set LANG to ru.UTF-8, man finds the Russian man page, but 
> displays it wrongly. Even when I fix the NROFF line in /etc/man.conf.
> Moving /usr/share/man/ru.UTF-8 to /usr/share/man/ru_RU.UTF-8 (and 
> fixing man.conf) makes the man page display properly. This confirms 
> that the non-latin1 directories have the wrong name in Cygwin.
>
>> When I type
>>
>> $ export LANG=ru_RU.UTF-8
>> $ export LANGUAGE=ru.UTF-8
>> $ man vim
>>
>> The Russian man page is displayed, but all Russian characters are 
>> wrongly displayed.
>> I think because it is assumed the man page is in Latin-1.
>>
>> To get a correct display of the Russian man page I need to change 
>> /etc/man.config
>> I change the line with NROFF to:
>> NROFF         /usr/bin/preconv | /usr/bin/nroff -c -mandoc 2>/dev/null
>>
>> Now the Russian man page displays correctly, but now all the Latin-1 
>> pages display wrongly.
>
> This can be fixed by adding a coding tag to the first or second line 
> of the man page, which is understood by preconv.
> When I set LANG to fr_FR.UTF-8, move /usr/share/man/fr.UTF-8 to 
> /usr/share/man/fr_FR.UTF-8, and add this tag to vim.1
>
> .\" -*- coding: latin-1; -*-
>
> The French manual displays properly.

Actually this is not working. Somewhere the coding tag is lost, although 
preconv seems to do a good job. I reported this three years ago to the 
maintainers of man an groff, but it appears it is still not fixed.

>
>
>>
>> So I undo my change in /etc/man.conf
>>
>>
>> On Linux the trend is to convert all man pages to UTF-8 encoding.
>> Will Cygwin follow this trend?
>>
>>
>
> The following needs to be done in Cygwin to have man pages for all 
> scripts displayed properly out of the box (assuming an UTF-8 locale 
> and use of mintty):
>
> * Rename the non-latin1 directories under /usr/share/man/ to 
> fr_FR.UTF-8, ru_RU.UTF-8, and so on.
> * Change /etc/man.conf to use preconv:
> NROFF         /usr/bin/preconv | /usr/bin/nroff -c -mandoc 2>/dev/null
> * Convert all Latin-1 coded man pages to UTF-8, or add a latin-1 
> coding tag on the first line 

Since the coding tag is not working it is best to convert all man pages 
to UTF-8.

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Cygwin needs a man-db port (was: How does Cygwin handle non-Latin1 man pages? (move to UTF-8?))

[Erwin Waterlander]

Hi,

The major linux distributions have switched for their man system to 
'man-db' (http://man-db.nongnu.org/) in favour of the classic man.

I think that Cygwin should also switch to man-db. man-db is much better 
in handling man pages in different encoding.

Before man-db, libpipeline (http://libpipeline.nongnu.org/) needs to be 
ported, because man-db uses it.

I have tried to port man-db to Cygwin, but I did not succeed. I got 
stuck in libpipeline. Did anyone else succeed?

regards,

Erwin

Op 25-9-2013 22:04 Erwin Waterlander schreef:
> Erwin Waterlander schreef, Op 25-9-2013 21:50:
>>
>> Erwin Waterlander schreef, Op 24-9-2013 22:01:
>>> Hi,
>>>
>>> As far as I see it, on Cygwin it is assumed that man pages are 
>>> encoded in Latin-1 (ISO-8859-1).
>>> For instance the man pages of vim.
>>>
>>> /usr/share/man/fr/vim.1.gz is encoded in Latin-1.
>>>
>>> $ export LANG=fr_FR.UTF-8
>>> $ man vim
>>>
>>> This will show the French man page correctly. Latin-1 is converted 
>>> to UTF-8.
>>>
>>> For the Russian translation of the vim manual I see two files:
>>> /usr/share/man/ru.UTF-8/man1/vim.1.gz
>>> /usr/share/man/ru.KOI8-R/man1/vim.1.gz
>>>
>>>
>>> When I type
>>> $ export LANG=ru_RU.UTF-8
>>> $ man vim
>>>
>>> I get the English man page, instead of the Russian man page.
>>> I think because there is no /usr/share/man/ru/man1/vim.1.gz present.
>>>
>>
>> The problem is here that man looks for the manual in these 
>> directories in this order:
>> /usr/share/man/ru_RU.UTF-8
>> /usr/share/man/ru_RU
>> /usr/share/man/ru
>>
>> All three paths are not present on Cygwin.
>> I could set LANG to ru.UTF-8, but this is not common practice. 
>> Normally you set LANG to ru_RU.UTF-8. Therefore I think that the 
>> non-Latin1 folders under /usr/share/man have the wrong name.
>> When I set LANG to ru.UTF-8, man finds the Russian man page, but 
>> displays it wrongly. Even when I fix the NROFF line in /etc/man.conf.
>> Moving /usr/share/man/ru.UTF-8 to /usr/share/man/ru_RU.UTF-8 (and 
>> fixing man.conf) makes the man page display properly. This confirms 
>> that the non-latin1 directories have the wrong name in Cygwin.
>>
>>> When I type
>>>
>>> $ export LANG=ru_RU.UTF-8
>>> $ export LANGUAGE=ru.UTF-8
>>> $ man vim
>>>
>>> The Russian man page is displayed, but all Russian characters are 
>>> wrongly displayed.
>>> I think because it is assumed the man page is in Latin-1.
>>>
>>> To get a correct display of the Russian man page I need to change 
>>> /etc/man.config
>>> I change the line with NROFF to:
>>> NROFF         /usr/bin/preconv | /usr/bin/nroff -c -mandoc 2>/dev/null
>>>
>>> Now the Russian man page displays correctly, but now all the Latin-1 
>>> pages display wrongly.
>>
>> This can be fixed by adding a coding tag to the first or second line 
>> of the man page, which is understood by preconv.
>> When I set LANG to fr_FR.UTF-8, move /usr/share/man/fr.UTF-8 to 
>> /usr/share/man/fr_FR.UTF-8, and add this tag to vim.1
>>
>> .\" -*- coding: latin-1; -*-
>>
>> The French manual displays properly.
>
> Actually this is not working. Somewhere the coding tag is lost, 
> although preconv seems to do a good job. I reported this three years 
> ago to the maintainers of man an groff, but it appears it is still not 
> fixed.
>
>>
>>
>>>
>>> So I undo my change in /etc/man.conf
>>>
>>>
>>> On Linux the trend is to convert all man pages to UTF-8 encoding.
>>> Will Cygwin follow this trend?
>>>
>>>
>>
>> The following needs to be done in Cygwin to have man pages for all 
>> scripts displayed properly out of the box (assuming an UTF-8 locale 
>> and use of mintty):
>>
>> * Rename the non-latin1 directories under /usr/share/man/ to 
>> fr_FR.UTF-8, ru_RU.UTF-8, and so on.
>> * Change /etc/man.conf to use preconv:
>> NROFF         /usr/bin/preconv | /usr/bin/nroff -c -mandoc 2>/dev/null
>> * Convert all Latin-1 coded man pages to UTF-8, or add a latin-1 
>> coding tag on the first line 
>
> Since the coding tag is not working it is best to convert all man 
> pages to UTF-8.
>


-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin needs a man-db port

[Chris J. Breisch]

Erwin Waterlander wrote:
> Hi,
>
> The major linux distributions have switched for their man system to
> 'man-db' (http://man-db.nongnu.org/) in favour of the classic man.
>
> I think that Cygwin should also switch to man-db. man-db is much better
> in handling man pages in different encoding.
>
> Before man-db, libpipeline (http://libpipeline.nongnu.org/) needs to be
> ported, because man-db uses it.
>
> I have tried to port man-db to Cygwin, but I did not succeed. I got
> stuck in libpipeline. Did anyone else succeed?
>
> regards,
>
> Erwin
>

I downloaded the latest version of libpipeline. It builds fine, but all 
the tests fail with the following error:
/usr/src/ports/check/check-0.9.10-1/src/check-0.9.10/src/check_run.c:431: Error 
in call to timer_create: Invalid argument

So, I downloaded the source for check. The version of check that we have 
is a little out-of-date, but at a first glance, the code for 
timer_create looks okay to me.

Hmmm...I built check using the cygport file and then went into the tests 
folder and did a "make check" there. 5 of 6 tests failed and with that 
exact same error.

The version of check we have is 0.9.10 from April, 2013. The ChangeLog 
for 0.9.11 from November of 2013 contains the following:

	Wed, Nov 4, 2013: Released Check 0.9.11
	  based on r856 (2013-11-04 02:09:21 +0000)

	* Check compiles for Windows using the Cygwin environment, and all unit 
tests pass.

There's also a check 0.9.12 from January of this year.

It appears to me that we should upgrade check to at least 0.9.11, as I'm 
unconvinced that the current version is working.

-- 
Chris J. Breisch

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin needs a man-db port

[Erwin Waterlander]

Op 14-3-2014 13:58 Chris J. Breisch schreef:
> Erwin Waterlander wrote:
>> Hi,
>>
>> The major linux distributions have switched for their man system to
>> 'man-db' (http://man-db.nongnu.org/) in favour of the classic man.
>>
>> I think that Cygwin should also switch to man-db. man-db is much better
>> in handling man pages in different encoding.
>>
>> Before man-db, libpipeline (http://libpipeline.nongnu.org/) needs to be
>> ported, because man-db uses it.
>>
>> I have tried to port man-db to Cygwin, but I did not succeed. I got
>> stuck in libpipeline. Did anyone else succeed?
>>
>> regards,
>>
>> Erwin
>>
>
> I downloaded the latest version of libpipeline. It builds fine, but 
> all the tests fail with the following error:
> /usr/src/ports/check/check-0.9.10-1/src/check-0.9.10/src/check_run.c:431: 
> Error in call to timer_create: Invalid argument
>
> So, I downloaded the source for check. The version of check that we 
> have is a little out-of-date, but at a first glance, the code for 
> timer_create looks okay to me.
>
> Hmmm...I built check using the cygport file and then went into the 
> tests folder and did a "make check" there. 5 of 6 tests failed and 
> with that exact same error.
>
> The version of check we have is 0.9.10 from April, 2013. The ChangeLog 
> for 0.9.11 from November of 2013 contains the following:
>
>     Wed, Nov 4, 2013: Released Check 0.9.11
>       based on r856 (2013-11-04 02:09:21 +0000)
>
>     * Check compiles for Windows using the Cygwin environment, and all 
> unit tests pass.
>
> There's also a check 0.9.12 from January of this year.
>
> It appears to me that we should upgrade check to at least 0.9.11, as 
> I'm unconvinced that the current version is working.
>

It was in October when I tried. I also could get libpipelines and man-db 
compiled, but it did not work properly. I had also failing tests in the 
libpipeline package. In the end I could display a man page in Russian 
and English of Vim, but man-db coredumped on the Fench man page.

I remember there were indeed problems with 'check'. At that time this 
bug, http://sourceforge.net/p/check/bugs/88/, was still open. The author 
of man-db suggested to set CK_FORK=no in the environment. That helped 
for several tests, but the first test of libpipelines kept failing.

I also had a problem that I always got static libraries instead of shared.
Even when I explicitly configure with --enable-static=no 
--enable-shared=yes.

regards,

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin needs a man-db port

[Chris J. Breisch]

Erwin Waterlander wrote:
> Op 14-3-2014 13:58 Chris J. Breisch schreef:
>>
>>
>> There's also a check 0.9.12 from January of this year.
>>
>> It appears to me that we should upgrade check to at least 0.9.11, as
>> I'm unconvinced that the current version is working.
>>
>
> It was in October when I tried. I also could get libpipelines and man-db
> compiled, but it did not work properly. I had also failing tests in the
> libpipeline package. In the end I could display a man page in Russian
> and English of Vim, but man-db coredumped on the Fench man page.
>
> I remember there were indeed problems with 'check'. At that time this
> bug, http://sourceforge.net/p/check/bugs/88/, was still open. The author
> of man-db suggested to set CK_FORK=no in the environment. That helped
> for several tests, but the first test of libpipelines kept failing.
>
> I also had a problem that I always got static libraries instead of shared.
> Even when I explicitly configure with --enable-static=no
> --enable-shared=yes.
>
> regards,
>
I downloaded and built the latest version of check, and it seems to work 
much better. I still have issues with libpipelines tests. It appears 
that there is a 32/64-bit issue somewhere. I'm using Cygwin x64. Many of 
the tests fail with issues similar to the following:

/home/Chris/Stuff/non-GNU/libpipeline/build/tests/../../libpipeline-1.2.6/tests/exec.c:114:(.text+0x121): 
relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`_ck_assert_failed'

I can dig a little deeper into this, and I can also try a 32-bit 
version, but not until later. I don't even have a 32-bit install of 
Cygwin on this box, and I'd have to figure out exactly what packages I'd 
need to build check and libpipeline.

-- 
Chris J. Breisch

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin needs a man-db port

[Erwin Waterlander]

Op 14-3-2014 15:24 Chris J. Breisch schreef:
> Erwin Waterlander wrote:
>> Op 14-3-2014 13:58 Chris J. Breisch schreef:
>>>
>>>
>>> There's also a check 0.9.12 from January of this year.
>>>
>>> It appears to me that we should upgrade check to at least 0.9.11, as
>>> I'm unconvinced that the current version is working.
>>>
>>
>> It was in October when I tried. I also could get libpipelines and man-db
>> compiled, but it did not work properly. I had also failing tests in the
>> libpipeline package. In the end I could display a man page in Russian
>> and English of Vim, but man-db coredumped on the Fench man page.
>>
>> I remember there were indeed problems with 'check'. At that time this
>> bug, http://sourceforge.net/p/check/bugs/88/, was still open. The author
>> of man-db suggested to set CK_FORK=no in the environment. That helped
>> for several tests, but the first test of libpipelines kept failing.
>>
>> I also had a problem that I always got static libraries instead of 
>> shared.
>> Even when I explicitly configure with --enable-static=no
>> --enable-shared=yes.
>>
>> regards,
>>
> I downloaded and built the latest version of check, and it seems to 
> work much better. I still have issues with libpipelines tests. It 
> appears that there is a 32/64-bit issue somewhere. I'm using Cygwin 
> x64. Many of the tests fail with issues similar to the following:
>
> /home/Chris/Stuff/non-GNU/libpipeline/build/tests/../../libpipeline-1.2.6/tests/exec.c:114:(.text+0x121): 
> relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
> `_ck_assert_failed'
>
> I can dig a little deeper into this, and I can also try a 32-bit 
> version, but not until later. I don't even have a 32-bit install of 
> Cygwin on this box, and I'd have to figure out exactly what packages 
> I'd need to build check and libpipeline.
>

I ran it on 32 bit cygwin, I did not try 64 bit. But is should work on 
both of course.

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin needs a man-db port

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]

On Mar 14 10:24, Chris J. Breisch wrote:
> Erwin Waterlander wrote:
> >Op 14-3-2014 13:58 Chris J. Breisch schreef:
> >>
> >>
> >>There's also a check 0.9.12 from January of this year.
> >>
> >>It appears to me that we should upgrade check to at least 0.9.11, as
> >>I'm unconvinced that the current version is working.
> >>
> >
> >It was in October when I tried. I also could get libpipelines and man-db
> >compiled, but it did not work properly. I had also failing tests in the
> >libpipeline package. In the end I could display a man page in Russian
> >and English of Vim, but man-db coredumped on the Fench man page.
> >
> >I remember there were indeed problems with 'check'. At that time this
> >bug, http://sourceforge.net/p/check/bugs/88/, was still open. The author
> >of man-db suggested to set CK_FORK=no in the environment. That helped
> >for several tests, but the first test of libpipelines kept failing.
> >
> >I also had a problem that I always got static libraries instead of shared.
> >Even when I explicitly configure with --enable-static=no
> >--enable-shared=yes.
> >
> >regards,
> >
> I downloaded and built the latest version of check, and it seems to
> work much better. I still have issues with libpipelines tests. It
> appears that there is a 32/64-bit issue somewhere. I'm using Cygwin
> x64. Many of the tests fail with issues similar to the following:
> 
> /home/Chris/Stuff/non-GNU/libpipeline/build/tests/../../libpipeline-1.2.6/tests/exec.c:114:(.text+0x121):
> relocation truncated to fit: R_X86_64_PC32 against undefined symbol
> `_ck_assert_failed'

The "relocation truncated to fit" gcc error message on 64 bit systems is
a red herring.  It's in fact just what it says, there's an undefined
symbol.  Off the top of my head I don't know where ck_assert_failed is
defined, probably some library, but the leading underscore is suspicious.
The 64 bit ABI does not prepend underscores to symbol names as the 32
bit ABI does.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Cygwin needs a man-db port

[Chris J. Breisch]

Corinna Vinschen wrote:
> On Mar 14 10:24, Chris J. Breisch wrote:
>> I downloaded and built the latest version of check, and it seems to
>> work much better. I still have issues with libpipelines tests. It
>> appears that there is a 32/64-bit issue somewhere. I'm using Cygwin
>> x64. Many of the tests fail with issues similar to the following:
>>
>> /home/Chris/Stuff/non-GNU/libpipeline/build/tests/../../libpipeline-1.2.6/tests/exec.c:114:(.text+0x121):
>> relocation truncated to fit: R_X86_64_PC32 against undefined symbol
>> `_ck_assert_failed'
>
> The "relocation truncated to fit" gcc error message on 64 bit systems is
> a red herring.  It's in fact just what it says, there's an undefined
> symbol.  Off the top of my head I don't know where ck_assert_failed is
> defined, probably some library, but the leading underscore is suspicious.
> The 64 bit ABI does not prepend underscores to symbol names as the 32
> bit ABI does.
>
>
> Corinna
>
Oh. Thanks, Corinna. I'll dig more when I get a chance.

-- 
Chris J. Breisch

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin needs a man-db port

[Chris J. Breisch]

Corinna Vinschen wrote:
> The "relocation truncated to fit" gcc error message on 64 bit systems is
> a red herring.  It's in fact just what it says, there's an undefined
> symbol.  Off the top of my head I don't know where ck_assert_failed is
> defined, probably some library, but the leading underscore is suspicious.
> The 64 bit ABI does not prepend underscores to symbol names as the 32
> bit ABI does.
>
>
> Corinna
>
Ok, this was my fault. Not wanting to overwrite the existing install of 
"check" since I was testing, I put it in /usr/local. I then neglected to 
add /usr/local/lib to my LIBRARY_PATH. _ck_assert_failed is the name of 
the function, complete with leading underscore. When I allowed the 
linker to actually link against the correct version of the library, 
things worked much better.

I then ran into the following error:
Running suite(s): Basic
/home/Chris/Stuff/non-GNU/libpipeline/build/tests/./.libs/basic: can't 
execute sh: No such file or directory
87%: Checks: 8, Failures: 0, Errors: 1
../../libpipeline-1.2.6/tests/basic.c:170:E:clearenv:test_basic_clearenv:0: 
(after this point) Received signal 11 (Segmentation fault)

That's the only failure. 6 other tests pass.

I'm not yet sure why it can't find "sh" unless it's not looking in $PATH 
or $PATH has been obliterated somehow.

Still digging...

-- 
Chris J. Breisch

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin needs a man-db port

[Chris J. Breisch]

Erwin Waterlander wrote:
> Hi,
>
> The major linux distributions have switched for their man system to
> 'man-db' (http://man-db.nongnu.org/) in favour of the classic man.
>
> I think that Cygwin should also switch to man-db. man-db is much better
> in handling man pages in different encoding.
>
> Before man-db, libpipeline (http://libpipeline.nongnu.org/) needs to be
> ported, because man-db uses it.
>
> I have tried to port man-db to Cygwin, but I did not succeed. I got
> stuck in libpipeline. Did anyone else succeed?
>

Yes. And I agree this is a good idea.

Dependencies: gdbm, libpipeline

Build dependencies: pkgconfig, check, and the typical build stuff (make, 
gcc, etc.)

As I indicated earlier, I believe the current version of check is not 
working properly.

Check-0.9.12 seems to work out-of-the-box. Configure with --prefix=/usr.

"make check" on check reports all tests passed, despite what appear to 
be some failures. The CHANGELOG says that this version should pass all 
tests on Cygwin. I've just subscribed to the mailing list and will check 
on whether these failures can be ignored or not. Still, it definitely 
appears to work better than the version we have now, which only passes 1 
test in the test suite.

Libpipeline-1.3.0 seems to work out-of-the-box. Configure with 
--prefix=/usr.

Oddly a "make check" for libpipeline-1.3.0 doesn't appear to actually do 
anything. This was not the case for earlier versions of libpipeline. 
Well, that's one way of getting rid of the test failures, I guess.

Man-db-2.6.7 appears to work out-of-the-box.

Configuring man-db is a little harder than the other two.

../man-db-2.6.7/configure --prefix=/usr --disable-setuid 
--docdir=/usr/share/doc/man-db

If you don't add the --disable-setuid, you'll need to add a "man" user 
to your system. If you're not using Corinna's snapshots, you'll need to 
add the user to /etc/passwd as well.

I'm not sure about the --docdir switch. That seemed to be consistent 
with Cygwin, but an actual package maintainer would be a better source 
of info on this.

A couple of warnings are generated:

*** Warning: This system can not link to static lib archive 
/usr/lib/libpipeline.la.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

and a similar one for libman.la.

I do have shared versions of these libraries, so I'm not sure why the 
warnings appear. I seem to recall a thread about something similar 
recently in the Cygwin mailing lists. I may go back and check.

Once installed, you'll want to do a 'mandb -c' to create the database. 
It will report numerous warnings which can generally be ignored. See the 
manpage on mandb. This takes a while.

When new packages are added or updated on your system, you should run 
'mandb -c' again. This seems like something that should be part of 
postinstall.

My 32-bit Cygwin install has a lot of gzipped files and the uncompressed 
versions under /usr/share/man. mandb didn't like that at all. That is 
probably something I did and not a Cygwin problem.

Note that I've done only the most minimal of testing. make check passes 
for man-db and I've opened a few man pages. They seem to work.

Obviously, someone with decision making power should decide if this is 
something we want to add to Cygwin. My vote is yes, but that's just one 
vote. Or maybe even zero. I'm not sure I get a vote. :)

Also obviously, if the decision is to go forward, these three items need 
to be packaged up appropriately and a package maintainer assigned. Check 
is already a Cygwin package, but needs updating.

Somehow I have a feeling about who will be nominated for this task.

What minimal testing I have done has been on both 32-bit and 64-bit 
Cygwin 1.7.29.

-- 
Chris J. Breisch

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin needs a man-db port

[Erwin Waterlander]

op 17-04-14 20:32, Chris J. Breisch schreef:
> Erwin Waterlander wrote:
>> Hi,
>>
>> The major linux distributions have switched for their man system to
>> 'man-db' (http://man-db.nongnu.org/) in favour of the classic man.
>>
>> I think that Cygwin should also switch to man-db. man-db is much better
>> in handling man pages in different encoding.
>>
>> Before man-db, libpipeline (http://libpipeline.nongnu.org/) needs to be
>> ported, because man-db uses it.
>>
>> I have tried to port man-db to Cygwin, but I did not succeed. I got
>> stuck in libpipeline. Did anyone else succeed?
>>
>
> Yes. And I agree this is a good idea.
>
> Dependencies: gdbm, libpipeline
>
> Build dependencies: pkgconfig, check, and the typical build stuff 
> (make, gcc, etc.)
>
> As I indicated earlier, I believe the current version of check is not 
> working properly.
>
> Check-0.9.12 seems to work out-of-the-box. Configure with --prefix=/usr.
>
> "make check" on check reports all tests passed, despite what appear to 
> be some failures. The CHANGELOG says that this version should pass all 
> tests on Cygwin. I've just subscribed to the mailing list and will 
> check on whether these failures can be ignored or not. Still, it 
> definitely appears to work better than the version we have now, which 
> only passes 1 test in the test suite.
>
> Libpipeline-1.3.0 seems to work out-of-the-box. Configure with 
> --prefix=/usr.
>
> Oddly a "make check" for libpipeline-1.3.0 doesn't appear to actually 
> do anything. This was not the case for earlier versions of 
> libpipeline. Well, that's one way of getting rid of the test failures, 
> I guess.
>
> Man-db-2.6.7 appears to work out-of-the-box.
>
> Configuring man-db is a little harder than the other two.
>
> ../man-db-2.6.7/configure --prefix=/usr --disable-setuid 
> --docdir=/usr/share/doc/man-db
>
> If you don't add the --disable-setuid, you'll need to add a "man" user 
> to your system. If you're not using Corinna's snapshots, you'll need 
> to add the user to /etc/passwd as well.
>
> I'm not sure about the --docdir switch. That seemed to be consistent 
> with Cygwin, but an actual package maintainer would be a better source 
> of info on this.
>
> A couple of warnings are generated:
>
> *** Warning: This system can not link to static lib archive 
> /usr/lib/libpipeline.la.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have.
>
> and a similar one for libman.la.
>
> I do have shared versions of these libraries, so I'm not sure why the 
> warnings appear. I seem to recall a thread about something similar 
> recently in the Cygwin mailing lists. I may go back and check.
>
> Once installed, you'll want to do a 'mandb -c' to create the database. 
> It will report numerous warnings which can generally be ignored. See 
> the manpage on mandb. This takes a while.
>
> When new packages are added or updated on your system, you should run 
> 'mandb -c' again. This seems like something that should be part of 
> postinstall.
>
> My 32-bit Cygwin install has a lot of gzipped files and the 
> uncompressed versions under /usr/share/man. mandb didn't like that at 
> all. That is probably something I did and not a Cygwin problem.
>
> Note that I've done only the most minimal of testing. make check 
> passes for man-db and I've opened a few man pages. They seem to work.
>
> Obviously, someone with decision making power should decide if this is 
> something we want to add to Cygwin. My vote is yes, but that's just 
> one vote. Or maybe even zero. I'm not sure I get a vote. :)
>
> Also obviously, if the decision is to go forward, these three items 
> need to be packaged up appropriately and a package maintainer 
> assigned. Check is already a Cygwin package, but needs updating.
>
> Somehow I have a feeling about who will be nominated for this task.
>
> What minimal testing I have done has been on both 32-bit and 64-bit 
> Cygwin 1.7.29.
>
Hi Chris,

Thanks for all the good work! I will see if I can reproduce your work 
and do some testing. First I make a new dos2unix release for Cygwin 
which comes now with several new translations of the man page, all in 
UTF-8. This will break with the standard man configuration of Cygwin. I 
will use it also for testing man-db.

My vote is also yes. Now we have already two votes :)

best regards,

Erwin Waterlander

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin needs a man-db port

[waterlan]

Chris J. Breisch schreef op 2014-04-17 20:32:
> Erwin Waterlander wrote:
>> Hi,
>> 
>> The major linux distributions have switched for their man system to
>> 'man-db' (http://man-db.nongnu.org/) in favour of the classic man.
>> 
>> I think that Cygwin should also switch to man-db. man-db is much 
>> better
>> in handling man pages in different encoding.
>> 
>> Before man-db, libpipeline (http://libpipeline.nongnu.org/) needs to 
>> be
>> ported, because man-db uses it.
>> 
>> I have tried to port man-db to Cygwin, but I did not succeed. I got
>> stuck in libpipeline. Did anyone else succeed?
>> 
> 
> Yes. And I agree this is a good idea.
> 
> Dependencies: gdbm, libpipeline
> 
> Build dependencies: pkgconfig, check, and the typical build stuff
> (make, gcc, etc.)
> 
> As I indicated earlier, I believe the current version of check is not
> working properly.
> 
> Check-0.9.12 seems to work out-of-the-box. Configure with 
> --prefix=/usr.


Hi Yaakov,

Would you like to update check to version 0.9.12?

best regards,

Erwin


> 
> "make check" on check reports all tests passed, despite what appear to
> be some failures. The CHANGELOG says that this version should pass all
> tests on Cygwin. I've just subscribed to the mailing list and will
> check on whether these failures can be ignored or not. Still, it
> definitely appears to work better than the version we have now, which
> only passes 1 test in the test suite.
> 
> Libpipeline-1.3.0 seems to work out-of-the-box. Configure with 
> --prefix=/usr.
> 
> Oddly a "make check" for libpipeline-1.3.0 doesn't appear to actually
> do anything. This was not the case for earlier versions of
> libpipeline. Well, that's one way of getting rid of the test failures,
> I guess.
> 
> Man-db-2.6.7 appears to work out-of-the-box.
> 
> Configuring man-db is a little harder than the other two.
> 
> ../man-db-2.6.7/configure --prefix=/usr --disable-setuid
> --docdir=/usr/share/doc/man-db
> 
> If you don't add the --disable-setuid, you'll need to add a "man" user
> to your system. If you're not using Corinna's snapshots, you'll need
> to add the user to /etc/passwd as well.
> 
> I'm not sure about the --docdir switch. That seemed to be consistent
> with Cygwin, but an actual package maintainer would be a better source
> of info on this.
> 
> A couple of warnings are generated:
> 
> *** Warning: This system can not link to static lib archive
> /usr/lib/libpipeline.la.
> *** I have the capability to make that library automatically link in 
> when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have.
> 
> and a similar one for libman.la.
> 
> I do have shared versions of these libraries, so I'm not sure why the
> warnings appear. I seem to recall a thread about something similar
> recently in the Cygwin mailing lists. I may go back and check.
> 
> Once installed, you'll want to do a 'mandb -c' to create the database.
> It will report numerous warnings which can generally be ignored. See
> the manpage on mandb. This takes a while.
> 
> When new packages are added or updated on your system, you should run
> 'mandb -c' again. This seems like something that should be part of
> postinstall.
> 
> My 32-bit Cygwin install has a lot of gzipped files and the
> uncompressed versions under /usr/share/man. mandb didn't like that at
> all. That is probably something I did and not a Cygwin problem.
> 
> Note that I've done only the most minimal of testing. make check
> passes for man-db and I've opened a few man pages. They seem to work.
> 
> Obviously, someone with decision making power should decide if this is
> something we want to add to Cygwin. My vote is yes, but that's just
> one vote. Or maybe even zero. I'm not sure I get a vote. :)
> 
> Also obviously, if the decision is to go forward, these three items
> need to be packaged up appropriately and a package maintainer
> assigned. Check is already a Cygwin package, but needs updating.
> 
> Somehow I have a feeling about who will be nominated for this task.
> 
> What minimal testing I have done has been on both 32-bit and 64-bit
> Cygwin 1.7.29.

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin needs a man-db port

[KIMURA Masaru]

Hi,

sorry for METOO(tm) notice.
but check-0.9.10 is totally broken on cygwin.

http://sourceforge.net/p/check/bugs/88/

one of following should apply ASAP IMHO.

 * remove 0.9.10 and stick 0.9.8
 * remove 0.9.10 and bump 0.9.11 or later

Peace,


2014-04-22 5:41 GMT+09:00 waterlan <waterlan@xs4all.nl>:
> Chris J. Breisch schreef op 2014-04-17 20:32:
>
>> Erwin Waterlander wrote:
>>>
>>> Hi,
>>>
>>> The major linux distributions have switched for their man system to
>>> 'man-db' (http://man-db.nongnu.org/) in favour of the classic man.
>>>
>>> I think that Cygwin should also switch to man-db. man-db is much better
>>> in handling man pages in different encoding.
>>>
>>> Before man-db, libpipeline (http://libpipeline.nongnu.org/) needs to be
>>> ported, because man-db uses it.
>>>
>>> I have tried to port man-db to Cygwin, but I did not succeed. I got
>>> stuck in libpipeline. Did anyone else succeed?
>>>
>>
>> Yes. And I agree this is a good idea.
>>
>> Dependencies: gdbm, libpipeline
>>
>> Build dependencies: pkgconfig, check, and the typical build stuff
>> (make, gcc, etc.)
>>
>> As I indicated earlier, I believe the current version of check is not
>> working properly.
>>
>> Check-0.9.12 seems to work out-of-the-box. Configure with --prefix=/usr.
>
>
>
> Hi Yaakov,
>
> Would you like to update check to version 0.9.12?
>
> best regards,
>
> Erwin
>
>
>
>>
>> "make check" on check reports all tests passed, despite what appear to
>> be some failures. The CHANGELOG says that this version should pass all
>> tests on Cygwin. I've just subscribed to the mailing list and will
>> check on whether these failures can be ignored or not. Still, it
>> definitely appears to work better than the version we have now, which
>> only passes 1 test in the test suite.
>>
>> Libpipeline-1.3.0 seems to work out-of-the-box. Configure with
>> --prefix=/usr.
>>
>> Oddly a "make check" for libpipeline-1.3.0 doesn't appear to actually
>> do anything. This was not the case for earlier versions of
>> libpipeline. Well, that's one way of getting rid of the test failures,
>> I guess.
>>
>> Man-db-2.6.7 appears to work out-of-the-box.
>>
>> Configuring man-db is a little harder than the other two.
>>
>> ../man-db-2.6.7/configure --prefix=/usr --disable-setuid
>> --docdir=/usr/share/doc/man-db
>>
>> If you don't add the --disable-setuid, you'll need to add a "man" user
>> to your system. If you're not using Corinna's snapshots, you'll need
>> to add the user to /etc/passwd as well.
>>
>> I'm not sure about the --docdir switch. That seemed to be consistent
>> with Cygwin, but an actual package maintainer would be a better source
>> of info on this.
>>
>> A couple of warnings are generated:
>>
>> *** Warning: This system can not link to static lib archive
>> /usr/lib/libpipeline.la.
>> *** I have the capability to make that library automatically link in when
>> *** you link to this library.  But I can only do this if you have a
>> *** shared version of the library, which you do not appear to have.
>>
>> and a similar one for libman.la.
>>
>> I do have shared versions of these libraries, so I'm not sure why the
>> warnings appear. I seem to recall a thread about something similar
>> recently in the Cygwin mailing lists. I may go back and check.
>>
>> Once installed, you'll want to do a 'mandb -c' to create the database.
>> It will report numerous warnings which can generally be ignored. See
>> the manpage on mandb. This takes a while.
>>
>> When new packages are added or updated on your system, you should run
>> 'mandb -c' again. This seems like something that should be part of
>> postinstall.
>>
>> My 32-bit Cygwin install has a lot of gzipped files and the
>> uncompressed versions under /usr/share/man. mandb didn't like that at
>> all. That is probably something I did and not a Cygwin problem.
>>
>> Note that I've done only the most minimal of testing. make check
>> passes for man-db and I've opened a few man pages. They seem to work.
>>
>> Obviously, someone with decision making power should decide if this is
>> something we want to add to Cygwin. My vote is yes, but that's just
>> one vote. Or maybe even zero. I'm not sure I get a vote. :)
>>
>> Also obviously, if the decision is to go forward, these three items
>> need to be packaged up appropriately and a package maintainer
>> assigned. Check is already a Cygwin package, but needs updating.
>>
>> Somehow I have a feeling about who will be nominated for this task.
>>
>> What minimal testing I have done has been on both 32-bit and 64-bit
>> Cygwin 1.7.29.
>
>
> --
> Erwin Waterlander
> http://waterlan.home.xs4all.nl/
>
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin needs a man-db port

[Chris J. Breisch]

Chris J. Breisch wrote:
>
> Check-0.9.12 seems to work out-of-the-box. Configure with --prefix=/usr.
>
> "make check" on check reports all tests passed, despite what appear to
> be some failures. The CHANGELOG says that this version should pass all
> tests on Cygwin. I've just subscribed to the mailing list and will check
> on whether these failures can be ignored or not. Still, it definitely
> appears to work better than the version we have now, which only passes 1
> test in the test suite.

Just to follow-up on this a bit more.

I misunderstood the results from check's check. I should learn just to 
trust the summary results. The tests passed.
>
> Libpipeline-1.3.0 seems to work out-of-the-box. Configure with
> --prefix=/usr.
>
> Oddly a "make check" for libpipeline-1.3.0 doesn't appear to actually do
> anything. This was not the case for earlier versions of libpipeline.
> Well, that's one way of getting rid of the test failures, I guess.
>

I must have done something wrong in the build before I sent this. 
Re-building libpipeline does cause 'make check' to execute the tests. I 
got one failure. I've talked to the owner of the project, and he's sent 
me a patch that does eliminate the failure. So I now have a libpipeline 
where all tests pass under Cygwin.

I still get the shared library warnings when building man-db. I haven't 
yet investigated that.

-- 
Chris J. Breisch

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin needs a man-db port

[waterlan]

Chris J. Breisch schreef op 2014-04-23 17:18:
> Chris J. Breisch wrote:
>> 
>> Check-0.9.12 seems to work out-of-the-box. Configure with 
>> --prefix=/usr.
>> 
>> "make check" on check reports all tests passed, despite what appear to
>> be some failures. The CHANGELOG says that this version should pass all
>> tests on Cygwin. I've just subscribed to the mailing list and will 
>> check
>> on whether these failures can be ignored or not. Still, it definitely
>> appears to work better than the version we have now, which only passes 
>> 1
>> test in the test suite.
> 
> Just to follow-up on this a bit more.
> 
> I misunderstood the results from check's check. I should learn just to
> trust the summary results. The tests passed.
>> 
>> Libpipeline-1.3.0 seems to work out-of-the-box. Configure with
>> --prefix=/usr.
>> 
>> Oddly a "make check" for libpipeline-1.3.0 doesn't appear to actually 
>> do
>> anything. This was not the case for earlier versions of libpipeline.
>> Well, that's one way of getting rid of the test failures, I guess.
>> 
> 
> I must have done something wrong in the build before I sent this.
> Re-building libpipeline does cause 'make check' to execute the tests.
> I got one failure. I've talked to the owner of the project, and he's
> sent me a patch that does eliminate the failure. So I now have a
> libpipeline where all tests pass under Cygwin.

Hi Chris,

Would you like to send the patch to me?


> I still get the shared library warnings when building man-db. I
> haven't yet investigated that.

regards,

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin needs a man-db port

[Chris J. Breisch]

waterlan wrote:
>>
>> I must have done something wrong in the build before I sent this.
>> Re-building libpipeline does cause 'make check' to execute the tests.
>> I got one failure. I've talked to the owner of the project, and he's
>> sent me a patch that does eliminate the failure. So I now have a
>> libpipeline where all tests pass under Cygwin.
>
> Hi Chris,
>
> Would you like to send the patch to me?
>
>

It's been committed into git.

http://git.savannah.gnu.org/cgit/libpipeline.git/commit/?id=6d04129e3a99c0281cb12098f871a0bc94d08025

I'm also currently waiting on a patch for the one test failure for man-db.


-- 
Chris J. Breisch

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin needs a man-db port

[waterlan]

Chris J. Breisch schreef op 2014-04-17 20:32:
> Erwin Waterlander wrote:
>> Hi,
>> 
>> The major linux distributions have switched for their man system to
>> 'man-db' (http://man-db.nongnu.org/) in favour of the classic man.
>> 
>> I think that Cygwin should also switch to man-db. man-db is much 
>> better
>> in handling man pages in different encoding.
>> 
>> Before man-db, libpipeline (http://libpipeline.nongnu.org/) needs to 
>> be
>> ported, because man-db uses it.
>> 
>> I have tried to port man-db to Cygwin, but I did not succeed. I got
>> stuck in libpipeline. Did anyone else succeed?
>> 
> 
> Yes. And I agree this is a good idea.
> 
> Dependencies: gdbm, libpipeline
> 
> Build dependencies: pkgconfig, check, and the typical build stuff
> (make, gcc, etc.)
> 
> As I indicated earlier, I believe the current version of check is not
> working properly.
> 
> Check-0.9.12 seems to work out-of-the-box. Configure with 
> --prefix=/usr.
> 
> "make check" on check reports all tests passed, despite what appear to
> be some failures. The CHANGELOG says that this version should pass all
> tests on Cygwin. I've just subscribed to the mailing list and will
> check on whether these failures can be ignored or not. Still, it
> definitely appears to work better than the version we have now, which
> only passes 1 test in the test suite.
> 
> Libpipeline-1.3.0 seems to work out-of-the-box. Configure with 
> --prefix=/usr.
> 
> Oddly a "make check" for libpipeline-1.3.0 doesn't appear to actually
> do anything. This was not the case for earlier versions of
> libpipeline. Well, that's one way of getting rid of the test failures,
> I guess.
> 
> Man-db-2.6.7 appears to work out-of-the-box.
> 
> Configuring man-db is a little harder than the other two.
> 
> ../man-db-2.6.7/configure --prefix=/usr --disable-setuid
> --docdir=/usr/share/doc/man-db

When I run that I get this error:

checking for db1/db.h... no
checking ndbm.h usability... no
checking ndbm.h presence... no
checking for ndbm.h... no
configure: error: Fatal: no supported database library/header found



> If you don't add the --disable-setuid, you'll need to add a "man" user
> to your system. If you're not using Corinna's snapshots, you'll need
> to add the user to /etc/passwd as well.
> 
> I'm not sure about the --docdir switch. That seemed to be consistent
> with Cygwin, but an actual package maintainer would be a better source
> of info on this.
> 
> A couple of warnings are generated:
> 
> *** Warning: This system can not link to static lib archive
> /usr/lib/libpipeline.la.
> *** I have the capability to make that library automatically link in 
> when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have.
> 
> and a similar one for libman.la.
> 
> I do have shared versions of these libraries, so I'm not sure why the
> warnings appear. I seem to recall a thread about something similar
> recently in the Cygwin mailing lists. I may go back and check.
> 
> Once installed, you'll want to do a 'mandb -c' to create the database.
> It will report numerous warnings which can generally be ignored. See
> the manpage on mandb. This takes a while.
> 
> When new packages are added or updated on your system, you should run
> 'mandb -c' again. This seems like something that should be part of
> postinstall.
> 
> My 32-bit Cygwin install has a lot of gzipped files and the
> uncompressed versions under /usr/share/man. mandb didn't like that at
> all. That is probably something I did and not a Cygwin problem.
> 
> Note that I've done only the most minimal of testing. make check
> passes for man-db and I've opened a few man pages. They seem to work.
> 
> Obviously, someone with decision making power should decide if this is
> something we want to add to Cygwin. My vote is yes, but that's just
> one vote. Or maybe even zero. I'm not sure I get a vote. :)
> 
> Also obviously, if the decision is to go forward, these three items
> need to be packaged up appropriately and a package maintainer
> assigned. Check is already a Cygwin package, but needs updating.
> 
> Somehow I have a feeling about who will be nominated for this task.
> 
> What minimal testing I have done has been on both 32-bit and 64-bit
> Cygwin 1.7.29.

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin needs a man-db port

[waterlan]

waterlan schreef op 2014-04-24 21:43:
> Chris J. Breisch schreef op 2014-04-17 20:32:
>> Erwin Waterlander wrote:
>>> Hi,
>>> 
>>> The major linux distributions have switched for their man system to
>>> 'man-db' (http://man-db.nongnu.org/) in favour of the classic man.
>>> 
>>> I think that Cygwin should also switch to man-db. man-db is much 
>>> better
>>> in handling man pages in different encoding.
>>> 
>>> Before man-db, libpipeline (http://libpipeline.nongnu.org/) needs to 
>>> be
>>> ported, because man-db uses it.
>>> 
>>> I have tried to port man-db to Cygwin, but I did not succeed. I got
>>> stuck in libpipeline. Did anyone else succeed?
>>> 
>> 
>> Yes. And I agree this is a good idea.
>> 
>> Dependencies: gdbm, libpipeline
>> 
>> Build dependencies: pkgconfig, check, and the typical build stuff
>> (make, gcc, etc.)
>> 
>> As I indicated earlier, I believe the current version of check is not
>> working properly.
>> 
>> Check-0.9.12 seems to work out-of-the-box. Configure with 
>> --prefix=/usr.
>> 
>> "make check" on check reports all tests passed, despite what appear to
>> be some failures. The CHANGELOG says that this version should pass all
>> tests on Cygwin. I've just subscribed to the mailing list and will
>> check on whether these failures can be ignored or not. Still, it
>> definitely appears to work better than the version we have now, which
>> only passes 1 test in the test suite.
>> 
>> Libpipeline-1.3.0 seems to work out-of-the-box. Configure with 
>> --prefix=/usr.
>> 
>> Oddly a "make check" for libpipeline-1.3.0 doesn't appear to actually
>> do anything. This was not the case for earlier versions of
>> libpipeline. Well, that's one way of getting rid of the test failures,
>> I guess.
>> 
>> Man-db-2.6.7 appears to work out-of-the-box.
>> 
>> Configuring man-db is a little harder than the other two.
>> 
>> ../man-db-2.6.7/configure --prefix=/usr --disable-setuid
>> --docdir=/usr/share/doc/man-db
> 
> When I run that I get this error:
> 
> checking for db1/db.h... no
> checking ndbm.h usability... no
> checking ndbm.h presence... no
> checking for ndbm.h... no
> configure: error: Fatal: no supported database library/header found
> 

I needed to install gdbm-devel and then I could install man-db.

> 
> 
>> If you don't add the --disable-setuid, you'll need to add a "man" user
>> to your system. If you're not using Corinna's snapshots, you'll need
>> to add the user to /etc/passwd as well.
>> 
>> I'm not sure about the --docdir switch. That seemed to be consistent
>> with Cygwin, but an actual package maintainer would be a better source
>> of info on this.
>> 
>> A couple of warnings are generated:
>> 
>> *** Warning: This system can not link to static lib archive
>> /usr/lib/libpipeline.la.
>> *** I have the capability to make that library automatically link in 
>> when
>> *** you link to this library.  But I can only do this if you have a
>> *** shared version of the library, which you do not appear to have.
>> 
>> and a similar one for libman.la.

I had the same warnings.

>> I do have shared versions of these libraries, so I'm not sure why the
>> warnings appear. I seem to recall a thread about something similar
>> recently in the Cygwin mailing lists. I may go back and check.
>> 
>> Once installed, you'll want to do a 'mandb -c' to create the database.
>> It will report numerous warnings which can generally be ignored. See
>> the manpage on mandb. This takes a while.

I got a couple of warnings. Not very much.

>> When new packages are added or updated on your system, you should run
>> 'mandb -c' again. This seems like something that should be part of
>> postinstall.

I did not do that.

As far as I could see man-db worked very well. It displayed UTF-8, 
Latin-1, and KOI8-R encoded man pages correctly.

I only tried 32 bit. I used
check 0.9.12
libpipeline 1.3.0
man-db 2.6.7.1

best regards,


>> My 32-bit Cygwin install has a lot of gzipped files and the
>> uncompressed versions under /usr/share/man. mandb didn't like that at
>> all. That is probably something I did and not a Cygwin problem.
>> 
>> Note that I've done only the most minimal of testing. make check
>> passes for man-db and I've opened a few man pages. They seem to work.
>> 
>> Obviously, someone with decision making power should decide if this is
>> something we want to add to Cygwin. My vote is yes, but that's just
>> one vote. Or maybe even zero. I'm not sure I get a vote. :)
>> 
>> Also obviously, if the decision is to go forward, these three items
>> need to be packaged up appropriately and a package maintainer
>> assigned. Check is already a Cygwin package, but needs updating.
>> 
>> Somehow I have a feeling about who will be nominated for this task.
>> 
>> What minimal testing I have done has been on both 32-bit and 64-bit
>> Cygwin 1.7.29.

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin needs a man-db port

[waterlan]

waterlan schreef op 2014-04-25 00:10:
> waterlan schreef op 2014-04-24 21:43:
>> Chris J. Breisch schreef op 2014-04-17 20:32:
>>> Erwin Waterlander wrote:
>>>> Hi,
>>>> 
>>>> The major linux distributions have switched for their man system to
>>>> 'man-db' (http://man-db.nongnu.org/) in favour of the classic man.
>>>> 
>>>> I think that Cygwin should also switch to man-db. man-db is much 
>>>> better
>>>> in handling man pages in different encoding.
>>>> 
>>>> Before man-db, libpipeline (http://libpipeline.nongnu.org/) needs to 
>>>> be
>>>> ported, because man-db uses it.
>>>> 
>>>> I have tried to port man-db to Cygwin, but I did not succeed. I got
>>>> stuck in libpipeline. Did anyone else succeed?
>>>> 
>>> 
>>> Yes. And I agree this is a good idea.
>>> 
>>> Dependencies: gdbm, libpipeline
>>> 
>>> Build dependencies: pkgconfig, check, and the typical build stuff
>>> (make, gcc, etc.)
>>> 
>>> As I indicated earlier, I believe the current version of check is not
>>> working properly.
>>> 
>>> Check-0.9.12 seems to work out-of-the-box. Configure with 
>>> --prefix=/usr.
>>> 
>>> "make check" on check reports all tests passed, despite what appear 
>>> to
>>> be some failures. The CHANGELOG says that this version should pass 
>>> all
>>> tests on Cygwin. I've just subscribed to the mailing list and will
>>> check on whether these failures can be ignored or not. Still, it
>>> definitely appears to work better than the version we have now, which
>>> only passes 1 test in the test suite.
>>> 
>>> Libpipeline-1.3.0 seems to work out-of-the-box. Configure with 
>>> --prefix=/usr.
>>> 
>>> Oddly a "make check" for libpipeline-1.3.0 doesn't appear to actually
>>> do anything. This was not the case for earlier versions of
>>> libpipeline. Well, that's one way of getting rid of the test 
>>> failures,
>>> I guess.
>>> 
>>> Man-db-2.6.7 appears to work out-of-the-box.
>>> 
>>> Configuring man-db is a little harder than the other two.
>>> 
>>> ../man-db-2.6.7/configure --prefix=/usr --disable-setuid
>>> --docdir=/usr/share/doc/man-db
>> 
>> When I run that I get this error:
>> 
>> checking for db1/db.h... no
>> checking ndbm.h usability... no
>> checking ndbm.h presence... no
>> checking for ndbm.h... no
>> configure: error: Fatal: no supported database library/header found
>> 
> 
> I needed to install gdbm-devel and then I could install man-db.
> 
>> 
>> 
>>> If you don't add the --disable-setuid, you'll need to add a "man" 
>>> user
>>> to your system. If you're not using Corinna's snapshots, you'll need
>>> to add the user to /etc/passwd as well.
>>> 
>>> I'm not sure about the --docdir switch. That seemed to be consistent
>>> with Cygwin, but an actual package maintainer would be a better 
>>> source
>>> of info on this.
>>> 
>>> A couple of warnings are generated:
>>> 
>>> *** Warning: This system can not link to static lib archive
>>> /usr/lib/libpipeline.la.
>>> *** I have the capability to make that library automatically link in 
>>> when
>>> *** you link to this library.  But I can only do this if you have a
>>> *** shared version of the library, which you do not appear to have.
>>> 
>>> and a similar one for libman.la.
> 
> I had the same warnings.
> 
>>> I do have shared versions of these libraries, so I'm not sure why the
>>> warnings appear. I seem to recall a thread about something similar
>>> recently in the Cygwin mailing lists. I may go back and check.
>>> 
>>> Once installed, you'll want to do a 'mandb -c' to create the 
>>> database.
>>> It will report numerous warnings which can generally be ignored. See
>>> the manpage on mandb. This takes a while.
> 
> I got a couple of warnings. Not very much.
> 
>>> When new packages are added or updated on your system, you should run
>>> 'mandb -c' again. This seems like something that should be part of
>>> postinstall.

Hi,

A 'mandb -c' takes quite a long time. That can be pretty annoying during 
an install. Perhaps it is not needed. If you don't do it the cache will 
fill as you use man-db (I guess). You don't need all man pages in a 
cache.

> 
> I did not do that.
> 
> As far as I could see man-db worked very well. It displayed UTF-8,
> Latin-1, and KOI8-R encoded man pages correctly.
> 
> I only tried 32 bit. I used
> check 0.9.12
> libpipeline 1.3.0
> man-db 2.6.7.1
> 
> best regards,
> 
> 
>>> My 32-bit Cygwin install has a lot of gzipped files and the
>>> uncompressed versions under /usr/share/man. mandb didn't like that at
>>> all. That is probably something I did and not a Cygwin problem.
>>> 
>>> Note that I've done only the most minimal of testing. make check
>>> passes for man-db and I've opened a few man pages. They seem to work.
>>> 
>>> Obviously, someone with decision making power should decide if this 
>>> is
>>> something we want to add to Cygwin. My vote is yes, but that's just
>>> one vote. Or maybe even zero. I'm not sure I get a vote. :)
>>> 
>>> Also obviously, if the decision is to go forward, these three items
>>> need to be packaged up appropriately and a package maintainer
>>> assigned. Check is already a Cygwin package, but needs updating.
>>> 
>>> Somehow I have a feeling about who will be nominated for this task.

We can share the burden. I'm willing to package libpipeline. This 
package can be installed without harming anything. I will propose it in 
the cygwin-apps list. I think the latest libpipeline version is already 
good enough, even when some tests are failing, because we have seen 
man-db working with it. In the cygwin-apps list it should also be 
discussed how to further integrate man-db.

regards,

Erwin

>>> What minimal testing I have done has been on both 32-bit and 64-bit
>>> Cygwin 1.7.29.

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple