libfontconfig-common-2.15.0-2 system font cache directory settings seem to be wrong

[Masamichi Hosoda via Cygwin]

Hi

If I understand correctly,
the system font cache directory setting in /etc/fonts/fonts.conf
provided by libfontconfig-common-2.15.0-2 is wrong.

In /etc/fonts/fonts.conf provided by libfontconfig-common-2.13.1-2

```
   /var/cache/fontconfig
```

So `fc-cache -s` creates system font cache files in `/var/cache/fontconfig`.
It is correct because `/var/cache` is a common system cache directory.

In /etc/fonts/fonts.conf provided by libfontconfig-common-2.15.0-2

```
   LOCAL_APPDATA_FONTCONFIG_CACHE
```

So `fc-cache -s` creates system font cache files
in `./LOCAL_APPDATA_FONTCONFIG_CACHE`.
`LOCAL_APPDATA_FONTCONFIG_CACHE` directory is created
in the *current* directory when fc-cache.
It is wrong because it means that
processes with different current directories have
different system font cache directories,
and the caches are no longer shared.

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

libfontconfig-devel-2.15.0-1 links wrong DLL

[Masamichi Hosoda via Cygwin]

Hi

If I understand correctly,
libfontconfig-devel-2.15.0-1 links wrong DLL (i.e. libfontconfig-1.dll)
instead of correct DLL (i.e. cygfontconfig-1.dll).
Since the wrong DLL does not exist,
the executable file using libfontconfig-devel-2.15.0-1 cannot be executed.

```
$ cat foo.c
#include 

int main(void)
{
  FcInit();
  return 0;
}

$ gcc -o foo foo.c -lfontconfig

$ ldd foo
ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffccda5)
KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL 
(0x7ffccc23)
KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll 
(0x7ffccb59)
cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffcb3ff)
libfontconfig-1.dll => not found

$
```

Using the previous version, libfontconfig-devel-2.13.1-2, it is fine.

```
$ gcc -o foo foo.c -lfontconfig

$ ldd foo
ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffccda5)
KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL 
(0x7ffccc23)
KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll 
(0x7ffccb59)
cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffcb3ff)
cygfontconfig-1.dll => /usr/bin/cygfontconfig-1.dll (0x507fd)
cygexpat-1.dll => /usr/bin/cygexpat-1.dll (0x5d5bf)
cygfreetype-6.dll => /usr/bin/cygfreetype-6.dll (0x51c6b)
cygintl-8.dll => /usr/bin/cygintl-8.dll (0x5ee2d)
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x50caa)
cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3d2a1)
cygbrotlidec-1.dll => /usr/bin/cygbrotlidec-1.dll (0x42f93)
cygz.dll => /usr/bin/cygz.dll (0x597fd)
cygbz2-1.dll => /usr/bin/cygbz2-1.dll (0x3e1e3)
cygpng16-16.dll => /usr/bin/cygpng16-16.dll (0x5a987)
cygbrotlicommon-1.dll => /usr/bin/cygbrotlicommon-1.dll (0x4678a)

$
```

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

[ANNOUNCEMENT] Updated: extractpdfmark 1.1.1-1

[Masamichi Hosoda]

The following packages have been uploaded to the Cygwin distribution:

* extractpdfmark-1.1.1-1

Extract PDFmark is able to extract page mode
and named destinations as PDFmark from PDF.
By using this you can get the small PDF files that have preserved
the page mode and the named destinations.

This is an update to the latest upstream release.

https://github.com/trueroad/extractpdfmark

--
Masamichi Hosoda

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

Updated: extractpdfmark 1.1.1-1

[Masamichi Hosoda]

The following packages have been uploaded to the Cygwin distribution:

* extractpdfmark-1.1.1-1

Extract PDFmark is able to extract page mode
and named destinations as PDFmark from PDF.
By using this you can get the small PDF files that have preserved
the page mode and the named destinations.

This is an update to the latest upstream release.

https://github.com/trueroad/extractpdfmark

--
Masamichi Hosoda

Re: python-numpy (1.22.0-1) can't be imported

[Masamichi Hosoda]

> If I understand correctly, I've found the root cause of the issue.
> I've sent a pull request to numpy.
> https://github.com/numpy/numpy/pull/20874

A question is asked by NumPy if there is documentation
on the Cygwin package's Cython behavior.
https://github.com/numpy/numpy/pull/20874#issuecomment-1019442058

Does such a document exist?

One of the causes of this issue is a patch
in Cygwin's python-cython package like the one below.
It removes the `__declspec(dllexport)` attribute
from the symbols to be exported.

On the other hand, if you install Cython
by pip without using the Cygwin package,
the exported symbols have the `__declspec(dllexport)` attribute
because the patch has not been applied.

What is the purpose of removing the `__declspec(dllexport)` attribute
in this patch?
Is this to make the modules using Cython
without considering the Cygwin environment,
the module does not have the `__declspec(dllexport)` attribute
like Linux environment, works correctly?

```
--- origsrc/Cython-0.29.21/Cython/Utility/ModuleSetupCode.c 2020-07-08 
23:44:39.0 +0200
+++ Cython/Utility/ModuleSetupCode.c2021-01-30 08:34:37.402649500 +0100
@@ -709,7 +709,11 @@ static CYTHON_INLINE void * PyThread_tss
 /// PyModInitFuncType.proto ///
 
 #ifndef CYTHON_NO_PYINIT_EXPORT
-#define __Pyx_PyMODINIT_FUNC PyMODINIT_FUNC
+#ifdef __cplusplus
+#define __Pyx_PyMODINIT_FUNC extern "C" PyObject *
+#else
+#define __Pyx_PyMODINIT_FUNC PyObject *
+#endif
 
 #elif PY_MAJOR_VERSION < 3
 // Py2: define this to void manually because PyMODINIT_FUNC adds 
__declspec(dllexport) to it's definition.
```

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

Re: python-numpy (1.22.0-1) can't be imported

[Masamichi Hosoda]

> It is something like that, but "-Wl,--export-all-symbols"
> is not used on 1.21.4 and is not needed for most of the other
> modules on 1.22.x
> 
> so I am looking for a less extreme action.
> Also to understand how it can impact other python subpackages

If I understand correctly, I've found the root cause of the issue.
I've sent a pull request to numpy.
https://github.com/numpy/numpy/pull/20874

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

Re: python-numpy (1.22.0-1) can't be imported

[Masamichi Hosoda]

> I have not found the root cause yet.
> As the  1.21.4-1 imports correctly I removed the 1.22.0-1 until I solve 
> the issue.
> 
> I do not see anything obvious in upstream source between 1.21.4 and 
> 1.22.0 that gives me any hint on root cause.
> 
> Also 1.22.1 shows the same problem.
> I excluded the build chain as rebuilding 1.19.4 worked fine
> for all 3.6 to 3.9

If I understand correctly,
the patch below is just a quick hack, but it solves the problem.

```
--- a/numpy/random/setup.py
+++ b/numpy/random/setup.py
@@ -147,7 +147,8 @@
  include_dirs=['.', 'src', 'src/legacy'],
  libraries=mtrand_libs,
  extra_compile_args=EXTRA_COMPILE_ARGS,
- extra_link_args=EXTRA_LINK_ARGS,
+ extra_link_args=(EXTRA_LINK_ARGS +
+  ['-Wl,--export-all-symbols']),
  depends=depends + ['mtrand.pyx'],
  define_macros=defs + LEGACY_DEFS,
  )
```

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

Re: python-cython C++ support patch

[Masamichi Hosoda]

>> python38-cython-0.29.21-3 works fine with following test code.
>> 
>> ```hello.pyx
>> print('Hello World!')
>> ```
>> 
>> ```setup.py
>> from distutils.core import setup
>> from Cython.Build import cythonize
>> 
>> setup(
>>  ext_modules=cythonize(
>>  "hello.pyx",
>>  language="c++",
>>  )
>> )
>> ```
>> 
>> ```test.py
>> import hello
>> ```
>> 
>> Here's the result by python38-cython-0.29.21-2 (failed).
>> 
>> ```
>> $ python setup.py build_ext --inplace
>> [...snip...]
>> $ python test.py
>> Traceback (most recent call last):
>>File "test.py", line 1, in 
>>  import hello
>> ImportError: dynamic module does not define module export function 
>> (PyInit_hello)
>> ```
>> 
>> Here's the result by python38-cython-0.29.21-3 (succeeded).
>> 
>> ```
>> $ python setup.py build_ext --inplace
>> [...snip...]
>> $ python test.py
>> Hello World!
>> ```
>> 
>> Thanks.
>
> Thanks to you
>
> I still think that the change you proposed should go upstream.
>
> Have you tested your example on a NOT cygwin system ?
>
> Regards
> Marco

Here's the result by Ubuntu 20.04 with python-cython 0.29.21

```
$ lsb_release -d
Description:Ubuntu 20.04.2 LTS
$ pip3 list | grep "Cython"
Cython 0.29.21
$ python3 setup.py build_ext --inplace
[...snip...]
$ python3 test.py
Hello World!
```

The export name is different for the successful and unsuccessful cases.

Here's Cygwin python38-cython-0.29.21-2 (failed).

```
$ nm hello.cpython-38-x86_64-cygwin.dll | grep "PyInit"
00040b8a22af T _Z12PyInit_hellov
```

Here's Cygwin python38-cython-0.29.21-3 (succeeded).

```
$ nm hello.cpython-38-x86_64-cygwin.dll | grep "PyInit"
00040b8a22af T PyInit_hello
```

Here's Ubuntu python-cython 0.29.21 (succeeded).

```
$ nm hello.cpython-38-x86_64-linux-gnu.so | grep "PyInit"
30b7 T PyInit_hello
```

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

Re: python-cython C++ support patch

[Masamichi Hosoda]

>> PyMODINIT_FUNC unfortunately dos not work and my changes try
>> to overcome it, see similar on
>> 
>> https://sourceware.org/pipermail/cygwin/2021-January/247211.html
>> 
>> but your portion is for additional C++ case
>> than I am adding in asimilar way
>> 
>> Regards
>> Marco
>
> a test package has been just uploaded.
> Try it and tell me if it solves your problem.
>
> Otherwise point me to your C++ code and I will look on it.
>
> Regards
> Marco

python38-cython-0.29.21-3 works fine with following test code.

```hello.pyx
print('Hello World!')
```

```setup.py
from distutils.core import setup
from Cython.Build import cythonize

setup(
ext_modules=cythonize(
"hello.pyx",
language="c++",
)
)
```

```test.py
import hello
```

Here's the result by python38-cython-0.29.21-2 (failed).

```
$ python setup.py build_ext --inplace
[...snip...]
$ python test.py
Traceback (most recent call last):
  File "test.py", line 1, in 
import hello
ImportError: dynamic module does not define module export function 
(PyInit_hello)
```

Here's the result by python38-cython-0.29.21-3 (succeeded).

```
$ python setup.py build_ext --inplace
[...snip...]
$ python test.py
Hello World!
```

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

Re: python-cython C++ support patch

[Masamichi Hosoda]

> have you considered that you just need to define
> CYTHON_NO_PYINIT_EXPORT ?
>
> the portion of the code below your change has already the
> ifdef __cplusplus semantic
>
> Have you proposed it upstream ? It does not seem
> a change restricted to Cygwin
>
> Any way I see no "wrongness" to add it on the Cython rebuild

Hi Marco,

The relevant upstream source looks like this.
https://github.com/cython/cython/blob/0.29.21/Cython/Utility/ModuleSetupCode.c#L712

```
#define __Pyx_PyMODINIT_FUNC PyMODINIT_FUNC
```
Perhaps `PyMODINIT_FUNC` is defined differently
depending on whether it is in C++ or not.

If I understand correctly, python-cython-0.29.21-2.src.patch
in the Cygwin python-cython package changes `PyMODINIT_FUNC` to `PyObject *`.
Here is the part of python-cython-0.29.21-2.src.patch.

```
--- origsrc/Cython-0.29.21/Cython/Utility/ModuleSetupCode.c 2020-07-08 
23:44:39.0 +0200
+++ src/Cython-0.29.21/Cython/Utility/ModuleSetupCode.c 2021-01-04 
22:10:21.641515500 +0100
@@ -709,7 +709,7 @@ static CYTHON_INLINE void * PyThread_tss
 /// PyModInitFuncType.proto ///
 
 #ifndef CYTHON_NO_PYINIT_EXPORT
-#define __Pyx_PyMODINIT_FUNC PyMODINIT_FUNC
+#define __Pyx_PyMODINIT_FUNC  PyObject *
 
 #elif PY_MAJOR_VERSION < 3
 // Py2: define this to void manually because PyMODINIT_FUNC adds 
__declspec(dllexport) to it's definition.
```

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

python-cython C++ support patch

[Masamichi Hosoda]

Hi,

I've found that modules built by python-cython with C++ could not be loaded.
If I understand correctly, the following patch fixes it.
Would you like to apply this patch to the package?

```
--- a/Cython-0.29.21/Cython/Utility/ModuleSetupCode.c
+++ b/Cython-0.29.21/Cython/Utility/ModuleSetupCode.c
@@ -709,7 +709,11 @@
 /// PyModInitFuncType.proto ///
 
 #ifndef CYTHON_NO_PYINIT_EXPORT
+#ifdef __cplusplus
+#define __Pyx_PyMODINIT_FUNC  extern "C" PyObject *
+#else
 #define __Pyx_PyMODINIT_FUNC  PyObject *
+#endif
 
 #elif PY_MAJOR_VERSION < 3
 // Py2: define this to void manually because PyMODINIT_FUNC adds 
__declspec(dllexport) to it's definition.
```

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

[ANNOUNCEMENT] Updated: extractpdfmark-1.1.0-1

[Masamichi Hosoda]

The following package has been uploaded to the Cygwin distribution:

* extractpdfmark-1.1.0-1

Extract PDFmark can extract page mode and named destinations
as PDFmark from PDF.
By using this you can get the small PDF files that have preserved
the page mode and the named destinations.

This is an update to the latest upstream release.

https://github.com/trueroad/extractpdfmark

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

Updated: extractpdfmark-1.1.0-1

[Masamichi Hosoda]

The following package has been uploaded to the Cygwin distribution:

* extractpdfmark-1.1.0-1

Extract PDFmark can extract page mode and named destinations
as PDFmark from PDF.
By using this you can get the small PDF files that have preserved
the page mode and the named destinations.

This is an update to the latest upstream release.

https://github.com/trueroad/extractpdfmark

--
Masamichi Hosoda

[ANNOUNCEMENT] liblbfgs 1.10

[Masamichi Hosoda]

The following packages have been uploaded to the Cygwin distribution:

* liblbfgs1-1.10-1
* liblbfgs-devel-1.10-1

This library is a C port of the implementation of
Limited-memory Broyden-Fletcher-Goldfarb-Shanno (L-BFGS) method.
The L-BFGS method solves the unconstrainted minimization problems.

http://www.chokkan.org/software/liblbfgs/

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

liblbfgs 1.10

[Masamichi Hosoda]

The following packages have been uploaded to the Cygwin distribution:

* liblbfgs1-1.10-1
* liblbfgs-devel-1.10-1

This library is a C port of the implementation of
Limited-memory Broyden-Fletcher-Goldfarb-Shanno (L-BFGS) method.
The L-BFGS method solves the unconstrainted minimization problems.

http://www.chokkan.org/software/liblbfgs/

Re: [ITP] liblbfgs 1.10

[Masamichi Hosoda]

> Thank you for your reviewing.
> 
> Setting a value in the PKG_SUMMARY array has no effect.
> So I use `eval` for setting the subpackage summaries.
> 
> My updated cygport file is attached.

My updated cygport file is attached.
NAME="liblbfgs"
VERSION=1.10
RELEASE=1

HOMEPAGE="http://www.chokkan.org/software/${PN}/;
SRC_URI="
https://github.com/downloads/chokkan/${PN}/${PN}-${PV}.tar.gz
${PN}.pc
"
PATCH_URI="libtool-package-versioning.patch"

CATEGORY="Libs"
SUMMARY="L-BFGS nonlinear optimizer"
DESCRIPTION="This library is a C port of the implementation of
Limited-memory Broyden-Fletcher-Goldfarb-Shanno (L-BFGS) method.
The L-BFGS method solves the unconstrainted minimization problems."

abi=1

PKG_NAMES="${PN}${abi} ${PN}-devel"

eval ${PN}${abi}_CONTENTS='"usr/bin/cyglbfgs-${abi}.dll"'
eval ${PN}${abi}_SUMMARY='"${SUMMARY} - runtime"'

eval ${PN}_devel_CONTENTS='"usr/include/ usr/lib/ usr/share/doc/"'
eval ${PN}_devel_SUMMARY='"${SUMMARY} - header and import lib"'

src_install() {
cd ${B}
cyginstall
cd ${S}
dodir /usr/lib/pkgconfig
insinto /usr/lib/pkgconfig
doins ${PN}.pc
}

src_test() {
export PATH=${B}/lib/.libs:${PATH}
cd ${B}/sample
.libs/sample.exe
}

Re: [ITP] liblbfgs 1.10

[Masamichi Hosoda]

> it builds fine on 64 bit.
> 
> However the SUMMARY should be differentiated between the
> runtime and the devel package and there is no need for an empty
> package.
> 
> Attached suggested modification and test using the built sample.

Thank you for your reviewing.

Setting a value in the PKG_SUMMARY array has no effect.
So I use `eval` for setting the subpackage summaries.

My updated cygport file is attached.

Updated package files:

https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/liblbfgs/liblbfgs-1.10-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/liblbfgs/liblbfgs-1.10-1-src.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/liblbfgs/liblbfgs1/liblbfgs1-1.10-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/liblbfgs/liblbfgs1/liblbfgs1-1.10-1.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/liblbfgs/liblbfgs-debuginfo/liblbfgs-debuginfo-1.10-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/liblbfgs/liblbfgs-debuginfo/liblbfgs-debuginfo-1.10-1.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/liblbfgs/liblbfgs-devel/liblbfgs-devel-1.10-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/liblbfgs/liblbfgs-devel/liblbfgs-devel-1.10-1.tar.xz

https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/liblbfgs/liblbfgs-1.10-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/liblbfgs/liblbfgs-1.10-1-src.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/liblbfgs/liblbfgs1/liblbfgs1-1.10-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/liblbfgs/liblbfgs1/liblbfgs1-1.10-1.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/liblbfgs/liblbfgs-debuginfo/liblbfgs-debuginfo-1.10-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/liblbfgs/liblbfgs-debuginfo/liblbfgs-debuginfo-1.10-1.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/liblbfgs/liblbfgs-devel/liblbfgs-devel-1.10-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/liblbfgs/liblbfgs-devel/liblbfgs-devel-1.10-1.tar.xz

[ITP] liblbfgs 1.10

[Masamichi Hosoda]

liblbfgs is in Debian and Fedora:

https://packages.debian.org/source/stretch/liblbfgs
https://apps.fedoraproject.org/packages/liblbfgs

My cygport file is attached.
Please review.

Package files:

https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/liblbfgs/liblbfgs-1.10-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/liblbfgs/liblbfgs-1.10-1.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/liblbfgs/liblbfgs-1.10-1-src.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/liblbfgs/liblbfgs1/liblbfgs1-1.10-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/liblbfgs/liblbfgs1/liblbfgs1-1.10-1.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/liblbfgs/liblbfgs-debuginfo/liblbfgs-debuginfo-1.10-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/liblbfgs/liblbfgs-debuginfo/liblbfgs-debuginfo-1.10-1.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/liblbfgs/liblbfgs-devel/liblbfgs-devel-1.10-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/liblbfgs/liblbfgs-devel/liblbfgs-devel-1.10-1.tar.xz

https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/liblbfgs/liblbfgs-1.10-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/liblbfgs/liblbfgs-1.10-1.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/liblbfgs/liblbfgs-1.10-1-src.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/liblbfgs/liblbfgs1/liblbfgs1-1.10-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/liblbfgs/liblbfgs1/liblbfgs1-1.10-1.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/liblbfgs/liblbfgs-debuginfo/liblbfgs-debuginfo-1.10-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/liblbfgs/liblbfgs-debuginfo/liblbfgs-debuginfo-1.10-1.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/liblbfgs/liblbfgs-devel/liblbfgs-devel-1.10-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/liblbfgs/liblbfgs-devel/liblbfgs-devel-1.10-1.tar.xz

License: MIT
NAME="liblbfgs"
VERSION=1.10
RELEASE=1

HOMEPAGE="http://www.chokkan.org/software/${PN}/;
SRC_URI="
https://github.com/downloads/chokkan/${PN}/${PN}-${PV}.tar.gz
${PN}.pc
"
PATCH_URI="libtool-package-versioning.patch"

CATEGORY="Libs"
SUMMARY="L-BFGS nonlinear optimizer"
DESCRIPTION="This library is a C port of the implementation of
Limited-memory Broyden-Fletcher-Goldfarb-Shanno (L-BFGS) method.
The L-BFGS method solves the unconstrainted minimization problems."

abi=1

PKG_NAMES="${PN} ${PN}${abi} ${PN}-devel"

PKG_CONTENTS[0]=""
liblbfgs_REQUIRES=${PN}${abi}

PKG_CONTENTS[1]="usr/bin/ usr/share/doc/"

PKG_CONTENTS[2]="usr/include/ usr/lib/"

src_install() {
cd ${B}
cyginstall
cd ${S}
dodir /usr/lib/pkgconfig
insinto /usr/lib/pkgconfig
doins ${PN}.pc
}

Re: strtod ("nan") returns negative NaN

[Masamichi Hosoda]

> On Wed, 15 Aug 2018, Masamichi Hosoda wrote:
> 
>> On Linux with glibc, both strtod ("nan")
>> and strtod ("-nan") return positive NaN.
>> 
>> So I've created the patch that behaves like glibc.
>> Both strtod ("nan") and strtod ("-nan") return positive NaN.
> 
> I would suggest that you should not consider fixed bugs in glibc (bug 
> 23007 in this case) to be appropriate to emulate in other libraries.

I've create the patch that behaves to preserve the sign bit.

The result on Cygwin 64 bit (newlib, x86_64) with the patch:
```
strtof ("nan", NULL) = nan
strtof ("-nan", NULL) = -nan
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = -nan
strtold ("nan", NULL) = nan
strtold ("-nan", NULL) = -nan
```

Thank you for your suggestion.
>From 91cf4a20e0773f4a38d6d56b0867fe3725859e5e Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda 
Date: Tue, 14 Aug 2018 22:29:34 +0900
Subject: [PATCH v2 1/2] Fix strtod ("nan") returns negative NaN

The definition of qNaN for x86_64 and i386 was wrong.
So strtod ("nan") and strtold ("nan") returned negative NaN
instead of positive NaN.

strtof ("nan") returns positive NaN so it does not have this issue.

This commit fixes definition of qNaN for x86_64 and i386.
So strtod ("nan") and strtold ("nan") return positive NaN.
---
 newlib/libc/stdlib/gd_qnan.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/newlib/libc/stdlib/gd_qnan.h b/newlib/libc/stdlib/gd_qnan.h
index b775f82..8b0726a 100644
--- a/newlib/libc/stdlib/gd_qnan.h
+++ b/newlib/libc/stdlib/gd_qnan.h
@@ -26,6 +26,20 @@
 #elif defined(__IEEE_LITTLE_ENDIAN)
 
 #if !defined(__mips)
+#if defined (__x86_64__) || defined (__i386__)
+#define f_QNAN 0x7fc0
+#define d_QNAN0 0x0
+#define d_QNAN1 0x7ff8
+#define ld_QNAN0 0x0
+#define ld_QNAN1 0xc000
+#define ld_QNAN2 0x7fff
+#define ld_QNAN3 0x0
+#define ldus_QNAN0 0x0
+#define ldus_QNAN1 0x0
+#define ldus_QNAN2 0x0
+#define ldus_QNAN3 0xc000
+#define ldus_QNAN4 0x7fff
+#else
 #define f_QNAN 0xffc0
 #define d_QNAN0 0x0
 #define d_QNAN1 0xfff8
@@ -38,6 +52,7 @@
 #define ldus_QNAN2 0x0
 #define ldus_QNAN3 0xc000
 #define ldus_QNAN4 0x
+#endif
 #elif defined(__mips_nan2008)
 #define f_QNAN 0x7fc0
 #define d_QNAN0 0x0
-- 
2.17.0

>From 51363ce08ffc587b206f2efdd72527ffba7b4381 Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda 
Date: Wed, 15 Aug 2018 08:39:22 +0900
Subject: [PATCH v2 2/2] Fix strtof ("-nan") returns positive NaN

strtof ("-nan") returned positive NaN instead of negative NaN.
strtod ("-nan") and strtold ("-nan") return negative NaN.

Linux glibc has been fixed
that strto{f|d|ld} ("-nan") returns negative NaN.
https://sourceware.org/bugzilla/show_bug.cgi?id=23007

This commit makes strtof preserves the negative sign bit
when parsing "-nan" like glibc.
---
 newlib/libc/stdlib/strtod.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/newlib/libc/stdlib/strtod.c b/newlib/libc/stdlib/strtod.c
index 0cfa9e6..9c5ed56 100644
--- a/newlib/libc/stdlib/strtod.c
+++ b/newlib/libc/stdlib/strtod.c
@@ -1285,7 +1285,7 @@ strtof_l (const char *__restrict s00, char **__restrict se, locale_t loc)
 {
   double val = _strtod_l (_REENT, s00, se, loc);
   if (isnan (val))
-return nanf (NULL);
+return signbit (val) ? -nanf (NULL) : nanf (NULL);
   float retval = (float) val;
 #ifndef NO_ERRNO
   if (isinf (retval) && !isinf (val))
@@ -1300,7 +1300,7 @@ strtof (const char *__restrict s00,
 {
   double val = _strtod_l (_REENT, s00, se, __get_current_locale ());
   if (isnan (val))
-return nanf (NULL);
+return signbit (val) ? -nanf (NULL) : nanf (NULL);
   float retval = (float) val;
 #ifndef NO_ERRNO
   if (isinf (retval) && !isinf (val))
-- 
2.17.0



--
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: strtod ("nan") returns negative NaN

[Masamichi Hosoda]

[...]
>> > With your patch, strtold looks more correct, but it still prints the
>> > sign of NaN:
>> > 
>> >   strtod ("nan", NULL) = nan
>> >   strtod ("-nan", NULL) = nan
>> >   strtold ("nan", NULL) = nan
>> >   strtold ("-nan", NULL) = -nan
>> >   nan ("") = nan
>> > 
>> > Question: What's wrong with that?  Wouldn't it be more correct if
>> > strtod returns -NaN for "-nan" as well?
>> 
>> In my investigate,
>> strtold sets sign bit when parameter has '-' character.
>> The wrong long double NaN definition is negative NaN that is set sign bit.
>> So without my patch, both strtold ("nan") and
>> strtold ("-nan") return negative NaN.
>> 
>> On the other hand, strtod inverts the sign when parameter has '-' character.
>> The wrong double NaN definition is negative NaN.
>> So without my patch, strtod ("nan") returns negative NaN
>> and strtod ("-nan") returns positive NaN.
> 
> Your patch improves the situation, that's a sure thing and I did not
> question that.
> 
> I just wonder why returning -NaN when the input is "-nan" isn't the
> better approach.  After all:
> 
>   printf ("nan (\"\") = %f\n", nan (""));
>   printf ("-nan (\"\") = %f\n", -nan (""));
> 
> ==>
> 
>   nan ("") = nan
>   -nan ("") = -nan
> 
> So, shouldn't the ideal outcome be this:
> 
>   strtod ("nan", NULL) = nan
>   strtod ("-nan", NULL) = -nan
>   strtold ("nan", NULL) = nan
>   strtold ("-nan", NULL) = -nan
> 
> ?

On Linux,
strtof ("nan"), strtof ("-nan"),
strtod ("nan"), strtod ("-nan"),
strtold ("nan"), and strtold ("-nan")
all return positive NaN.

My patch is for closing to the behavior of Linux.
I don't know why Linux's strtod ("-nan") does not return negative NaN.
But, probably because both positive and negative NaN behave in the same way,
I think.

Here's sample code.
```
#include 
#include 
#include 

int main (void)
{
  double pnan = nan ("");
  double nnan = -pnan;

  printf ("positive NaN == positive NaN: ");
  if (pnan == pnan)
printf ("true\n");
  else
printf ("false\n");

  printf ("negative NaN == negative NaN: ");
  if (nnan == nnan)
printf ("true\n");
  else
printf ("false\n");

  printf ("0 < positive NaN: ");
  if (0 < pnan)
printf ("true\n");
  else
printf ("false\n");

  printf ("0 > positive NaN: ");
  if (0 > pnan)
printf ("true\n");
  else
printf ("false\n");

  printf ("0 < negative NaN: ");
  if (0 < nnan)
printf ("true\n");
  else
printf ("false\n");

  printf ("0 > negative NaN: ");
  if (0 > nnan)
printf ("true\n");
  else
printf ("false\n");
}
```

Result:
```
positive NaN == positive NaN: false
negative NaN == negative NaN: false
0 < positive NaN: false
0 > positive NaN: false
0 < negative NaN: false
0 > negative NaN: false
```

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

strtod ("nan") returns negative NaN

[Masamichi Hosoda]

Hi

I've found that strtod ("nan") returns negative NaN on Cygwin 64 bit.
https://cygwin.com/ml/cygwin/2018-08/msg00168.html

On Linux with glibc, both strtod ("nan")
and strtod ("-nan") return positive NaN.

So I've created the patch that behaves like glibc.
Both strtod ("nan") and strtod ("-nan") return positive NaN.

Sample code:
```
#include 
#include 

int main (void)
{
  printf ("strtof (\"nan\", NULL) = %f\n", strtof ("nan", NULL));
  printf ("strtof (\"-nan\", NULL) = %f\n", strtof ("-nan", NULL));
  printf ("strtod (\"nan\", NULL) = %f\n", strtod ("nan", NULL));
  printf ("strtod (\"-nan\", NULL) = %f\n", strtod ("-nan", NULL));
  printf ("strtold (\"nan\", NULL) = %Lf\n", strtold ("nan", NULL));
  printf ("strtold (\"-nan\", NULL) = %Lf\n", strtold ("-nan", NULL));
}
```

The result of Cygwin (newlib) without my patch:
```
strtof ("nan", NULL) = nan
strtof ("-nan", NULL) = nan
strtod ("nan", NULL) = -nan
strtod ("-nan", NULL) = nan
strtold ("nan", NULL) = -nan
strtold ("-nan", NULL) = -nan
```

The result of Linux (glibc, Ubuntu 16.04):
```
strtof ("nan", NULL) = nan
strtof ("-nan", NULL) = nan
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = nan
strtold ("nan", NULL) = nan
strtold ("-nan", NULL) = nan
```

The result of FreeBSD 10.1 (BSD libc):
```
strtof ("nan", NULL) = nan
strtof ("-nan", NULL) = nan
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = nan
strtold ("nan", NULL) = nan
strtold ("-nan", NULL) = nan
```

The result of Cygwin (newlib) with my patch:
```
strtof ("nan", NULL) = nan
strtof ("-nan", NULL) = nan
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = nan
strtold ("nan", NULL) = nan
strtold ("-nan", NULL) = nan
```

Thanks.
>From 91cf4a20e0773f4a38d6d56b0867fe3725859e5e Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda 
Date: Tue, 14 Aug 2018 22:29:34 +0900
Subject: [PATCH 1/2] Fix strtod ("nan") returns negative NaN

The definition of qNaN for x86_64 and i386 was wrong.
So strtod ("nan") and strtold ("nan") returned negative NaN
instead of positive NaN.

strtof ("nan") returns positive NaN so it does not have this issue.

This commit fixes definition of qNaN for x86_64 and i386.
So strtod ("nan") and strtold ("nan") return positive NaN.
---
 newlib/libc/stdlib/gd_qnan.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/newlib/libc/stdlib/gd_qnan.h b/newlib/libc/stdlib/gd_qnan.h
index b775f82..8b0726a 100644
--- a/newlib/libc/stdlib/gd_qnan.h
+++ b/newlib/libc/stdlib/gd_qnan.h
@@ -26,6 +26,20 @@
 #elif defined(__IEEE_LITTLE_ENDIAN)
 
 #if !defined(__mips)
+#if defined (__x86_64__) || defined (__i386__)
+#define f_QNAN 0x7fc0
+#define d_QNAN0 0x0
+#define d_QNAN1 0x7ff8
+#define ld_QNAN0 0x0
+#define ld_QNAN1 0xc000
+#define ld_QNAN2 0x7fff
+#define ld_QNAN3 0x0
+#define ldus_QNAN0 0x0
+#define ldus_QNAN1 0x0
+#define ldus_QNAN2 0x0
+#define ldus_QNAN3 0xc000
+#define ldus_QNAN4 0x7fff
+#else
 #define f_QNAN 0xffc0
 #define d_QNAN0 0x0
 #define d_QNAN1 0xfff8
@@ -38,6 +52,7 @@
 #define ldus_QNAN2 0x0
 #define ldus_QNAN3 0xc000
 #define ldus_QNAN4 0x
+#endif
 #elif defined(__mips_nan2008)
 #define f_QNAN 0x7fc0
 #define d_QNAN0 0x0
-- 
2.17.0

>From 7256702e5034b016b5114dd1a6c4c1a689a17816 Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda 
Date: Tue, 14 Aug 2018 23:12:49 +0900
Subject: [PATCH 2/2] Fix strtod ("-nan") returns negative NaN

On Linux,
glibc's strtod ("-nan") and strtold ("-nan") return positive NaN.

But, newlib's strtod ("-nan") returns negative NaN
because it inverted the sign with the presence of `-` character.
And, newlib's srtold ("-nan") returns negative NaN
because it set the sign bit with the presence of `-` character.

newlib's strtof ("-nan") returns positive NaN same as Linux glibc's.

This commit removes strtod's NaN sign inversion
and removes strtold's NaN sign bit setting.
So strtod ("-nan") and strtold ("-nan") return positive NaN
same as Linux glibc.
---
 newlib/libc/stdlib/strtod.c  | 1 +
 newlib/libc/stdlib/strtodg.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/newlib/libc/stdlib/strtod.c b/newlib/libc/stdlib/strtod.c
index 0cfa9e6..3b9fd26 100644
--- a/newlib/libc/stdlib/strtod.c
+++ b/newlib/libc/stdlib/strtod.c
@@ -451,6 +451,7 @@ _strtod_l (struct _reent *ptr, const char *__restrict s00, char **__restrict se,
 #ifndef No_Hex_NaN
 		}
 #endif
+	sign = 0;
 	goto ret;
 	}

Re: strtod ("nan") returns negative NaN

[Masamichi Hosoda]

> On Aug 14 11:56, Corinna Vinschen wrote:
>> On Aug 14 13:45, Masamichi Hosoda wrote:
>> > >From a50ee5a4747a99c70469a53fe959f3dc22d3b79a Mon Sep 17 00:00:00 2001
>> > From: Masamichi Hosoda 
>> > Date: Tue, 14 Aug 2018 12:50:32 +0900
>> > Subject: [PATCH] Fix strtod ("nan") returns qNaN
>> > 
>> > The definition of qNaN for x86_64 and x86 was wrong.
>> > So strtod ("nan") returned sNaN instead of qNaN.
>> > 
>> > Furthermore, it was inverted the sign bit with the presence of `-` 
>> > character.
>> > So strtod ("-nan") returned qNaN.
>> > 
>> > This commit fixes definition of qNaN
>> > and removes the sign bit inversion when evaluating "nan".
>> > ---
>> >  newlib/libc/stdlib/gd_qnan.h | 8 
>> >  newlib/libc/stdlib/strtod.c  | 1 +
>> >  2 files changed, 5 insertions(+), 4 deletions(-)
>> 
>> Can you please send this patch to the newlib AT sourceware DOT org
>> mailing list?  As soon as something in newlib gets changed, a lot of
>> other targets are affected and the guys working on those targets should
>> have a chance to chime in.

I'll improve the patch and send it.
It did not consider environments excluding x86 and x86_64.

> Looks like strtold is affected as well, just differently:
> 
>   printf ("strtod (\"nan\", NULL) = %f\n", strtod ("nan", NULL));
>   printf ("strtod (\"-nan\", NULL) = %f\n", strtod ("-nan", NULL));
>   printf ("strtold (\"nan\", NULL) = %Lf\n", strtold ("nan", NULL));
>   printf ("strtold (\"-nan\", NULL) = %Lf\n", strtold ("-nan", NULL));
>   printf ("nan (\"\") = %f\n", nan (""));
> 
> ==>
> 
>   strtod ("nan", NULL) = -nan
>   strtod ("-nan", NULL) = nan
>   strtold ("nan", NULL) = -nan
>   strtold ("-nan", NULL) = -nan
>   nan ("") = nan
> 
> so it prints always -nan.
> 
> With your patch, strtold looks more correct, but it still prints the
> sign of NaN:
> 
>   strtod ("nan", NULL) = nan
>   strtod ("-nan", NULL) = nan
>   strtold ("nan", NULL) = nan
>   strtold ("-nan", NULL) = -nan
>   nan ("") = nan
> 
> Question: What's wrong with that?  Wouldn't it be more correct if
> strtod returns -NaN for "-nan" as well?

In my investigate,
strtold sets sign bit when parameter has '-' character.
The wrong long double NaN definition is negative NaN that is set sign bit.
So without my patch, both strtold ("nan") and
strtold ("-nan") return negative NaN.

On the other hand, strtod inverts the sign when parameter has '-' character.
The wrong double NaN definition is negative NaN.
So without my patch, strtod ("nan") returns negative NaN
and strtod ("-nan") returns positive NaN.

My previous patch removes the sign inversion in strtod when NaN.
But I did not fix strtold.

Perhaps, the following patch removes the sign bit setting of strtold when NaN.

```
--- a/newlib/libc/stdlib/strtodg.c
+++ b/newlib/libc/stdlib/strtodg.c
@@ -585,6 +585,7 @@ _strtodg_l (struct _reent *p, const char *s00, char **se, 
FPI *fpi, Long *exp,
if (*s == '(') /*)*/
irv = hexnan(, fpi, bits);
 #endif
+   sign = 0;
goto infnanexp;
}
  }
```

--
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: strtod ("nan") returns negative NaN

[Masamichi Hosoda]

>>> On Mon, 13 Aug 2018 at 19:46, Duncan Roe  wrote:
>>>>
>>>> On Mon, Aug 13, 2018 at 12:52:48PM -0400, Stephen John Smoogen wrote:
>>>> > On Mon, 13 Aug 2018 at 11:16, Masamichi Hosoda  
>>>> > wrote:
>>>> [...]
>>>> > On Fedora 27 with 7.3.1 it gives
>>>> > ```
>>>> > stod ("nan") = nan
>>>> > stod ("-nan") = nan
>>>> > quiet_NaN () = nan
>>>> > ```
[...]
>> Cygwin 2.10.0 64 bit with gcc 7.3.0
>> ```
>> strtod ("nan", NULL) = -nan
>> strtod ("-nan", NULL) = nan
>> nan ("") = nan
>> ```
>> 
>> Ubuntu 16.04 LTS 64 bit with gcc 5.4.0
>> ```
>> strtod ("nan", NULL) = nan
>> strtod ("-nan", NULL) = nan
>> nan ("") = nan
>> ```

I've created the quick hack patch that fixes `strtod ()`.

On Cygwin 64 bit with the patch, result of foobar.c:

```
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = nan
nan ("") = nan
```

Also result of foobar.cc:

```
stod ("nan") = nan
stod ("-nan") = nan
quiet_NaN () = nan
```
>From a50ee5a4747a99c70469a53fe959f3dc22d3b79a Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda 
Date: Tue, 14 Aug 2018 12:50:32 +0900
Subject: [PATCH] Fix strtod ("nan") returns qNaN

The definition of qNaN for x86_64 and x86 was wrong.
So strtod ("nan") returned sNaN instead of qNaN.

Furthermore, it was inverted the sign bit with the presence of `-` character.
So strtod ("-nan") returned qNaN.

This commit fixes definition of qNaN
and removes the sign bit inversion when evaluating "nan".
---
 newlib/libc/stdlib/gd_qnan.h | 8 
 newlib/libc/stdlib/strtod.c  | 1 +
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/newlib/libc/stdlib/gd_qnan.h b/newlib/libc/stdlib/gd_qnan.h
index b775f82..3ca337b 100644
--- a/newlib/libc/stdlib/gd_qnan.h
+++ b/newlib/libc/stdlib/gd_qnan.h
@@ -26,18 +26,18 @@
 #elif defined(__IEEE_LITTLE_ENDIAN)
 
 #if !defined(__mips)
-#define f_QNAN 0xffc0
+#define f_QNAN 0x7fc0
 #define d_QNAN0 0x0
-#define d_QNAN1 0xfff8
+#define d_QNAN1 0x7ff8
 #define ld_QNAN0 0x0
 #define ld_QNAN1 0xc000
-#define ld_QNAN2 0x
+#define ld_QNAN2 0x7fff
 #define ld_QNAN3 0x0
 #define ldus_QNAN0 0x0
 #define ldus_QNAN1 0x0
 #define ldus_QNAN2 0x0
 #define ldus_QNAN3 0xc000
-#define ldus_QNAN4 0x
+#define ldus_QNAN4 0x7fff
 #elif defined(__mips_nan2008)
 #define f_QNAN 0x7fc0
 #define d_QNAN0 0x0
diff --git a/newlib/libc/stdlib/strtod.c b/newlib/libc/stdlib/strtod.c
index 0cfa9e6..3b9fd26 100644
--- a/newlib/libc/stdlib/strtod.c
+++ b/newlib/libc/stdlib/strtod.c
@@ -451,6 +451,7 @@ _strtod_l (struct _reent *ptr, const char *__restrict s00, char **__restrict se,
 #ifndef No_Hex_NaN
 		}
 #endif
+	sign = 0;
 	goto ret;
 	}
 			  }
-- 
2.17.0



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

strtod ("nan") returns negative NaN (was `std::stod ("nan")` returns negative NaN)

[Masamichi Hosoda]

>> On Mon, 13 Aug 2018 at 19:46, Duncan Roe  wrote:
>>>
>>> On Mon, Aug 13, 2018 at 12:52:48PM -0400, Stephen John Smoogen wrote:
>>> > On Mon, 13 Aug 2018 at 11:16, Masamichi Hosoda  
>>> > wrote:
>>> [...]
>>> > On Fedora 27 with 7.3.1 it gives
>>> > ```
>>> > stod ("nan") = nan
>>> > stod ("-nan") = nan
>>> > quiet_NaN () = nan
>>> > ```
>>> [...]
>> 
>> I tested a compile on Windows Subsystem for Linux Ubuntu 18.04 which
>> had gcc 7.3.0. The output was the same as everything but Cygwin. At
>> this point it is time to pull through the gdb debugger and try to
>> figure out where it is coming from.
> 
> I suspect `cygwin1.dll`'s `strtod ()` etc.
> Here's a code.
> 
> ```
> /* gcc foobar.c */
> 
> #include 
> #include 
> #include 
> 
> int main (void)
> {
>   printf ("strtod (\"nan\", NULL) = %f\n", strtod ("nan", NULL));
>   printf ("strtod (\"-nan\", NULL) = %f\n", strtod ("-nan", NULL));
>   printf ("nan (\"\") = %f\n", nan (""));
> 
>   return 0;
> }
> ```
> 
> Cygwin 2.10.0 64 bit with gcc 7.3.0
> ```
> strtod ("nan", NULL) = -nan
> strtod ("-nan", NULL) = nan
> nan ("") = nan
> ```
> 
> Ubuntu 16.04 LTS 64 bit with gcc 5.4.0
> ```
> strtod ("nan", NULL) = nan
> strtod ("-nan", NULL) = nan
> nan ("") = nan
> ```

If I understand correctly,
`std::stod ()` uses cygwin1.dll's `strtod ()` for the conversion.

`std::stod ()` is defined in
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/include/c++/bits/basic_string.h L6388-.
It calls `__gnu_cxx::__stoa ()` with pointer of `std::strtod ()`.

```
  inline double
  stod(const string& __str, size_t* __idx = 0)
  { return __gnu_cxx::__stoa(::strtod, "stod", __str.c_str(), __idx); }
```

`__gnu_cxx::__stoa ()` is defined in
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/include/c++/ext/string_conversions.h L51-.
It calls the first parameter, `std::strtod ()`.

`std::strtod ()` is cygwin1.dll's `strtod ()`.

--
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: `std::stod ("nan")` returns negative NaN

[Masamichi Hosoda]

> On Mon, 13 Aug 2018 at 19:46, Duncan Roe  wrote:
>>
>> On Mon, Aug 13, 2018 at 12:52:48PM -0400, Stephen John Smoogen wrote:
>> > On Mon, 13 Aug 2018 at 11:16, Masamichi Hosoda  
>> > wrote:
>> [...]
>> > On Fedora 27 with 7.3.1 it gives
>> > ```
>> > stod ("nan") = nan
>> > stod ("-nan") = nan
>> > quiet_NaN () = nan
>> > ```
>> [...]
> 
> I tested a compile on Windows Subsystem for Linux Ubuntu 18.04 which
> had gcc 7.3.0. The output was the same as everything but Cygwin. At
> this point it is time to pull through the gdb debugger and try to
> figure out where it is coming from.

I suspect `cygwin1.dll`'s `strtod ()` etc.
Here's a code.

```
/* gcc foobar.c */

#include 
#include 
#include 

int main (void)
{
  printf ("strtod (\"nan\", NULL) = %f\n", strtod ("nan", NULL));
  printf ("strtod (\"-nan\", NULL) = %f\n", strtod ("-nan", NULL));
  printf ("nan (\"\") = %f\n", nan (""));

  return 0;
}
```

Cygwin 2.10.0 64 bit with gcc 7.3.0
```
strtod ("nan", NULL) = -nan
strtod ("-nan", NULL) = nan
nan ("") = nan
```

Ubuntu 16.04 LTS 64 bit with gcc 5.4.0
```
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = nan
nan ("") = nan
```

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

`std::stod ("nan")` returns negative NaN

[Masamichi Hosoda]

Hi

I've found a curious behavior about `std::stod ("nan")` on Cygwin.
Only on Cygwin, `std::stod ("nan")` returns negative NaN.
On Linux etc., `std::stod ("nan")` returns positive NaN.

Here is a reproduction code.

```
// g++ -std=c++11 foobar.cc

#include 
#include 
#include 

int main ()
{
  std::cout << "stod (\"nan\") = "
<< std::stod ("nan")
<< std::endl;
  std::cout << "stod (\"-nan\") = "
<< std::stod ("-nan")
<< std::endl;

  std::cout << "quiet_NaN () = "
<< std::numeric_limits::quiet_NaN ()
<< std::endl;
}
```

The result on Cygwin 2.10.0 64 bit (g++ 7.3.0):
```
stod ("nan") = -nan
stod ("-nan") = nan
quiet_NaN () = nan
```

The result on MinGW-w64 64 bit (g++ 4.9.2):
```
stod ("nan") = nan
stod ("-nan") = nan
quiet_NaN () = nan
```

The result on Ubuntu 16.04 LTS 64 bit (g++ 5.4.0):
```
stod ("nan") = nan
stod ("-nan") = nan
quiet_NaN () = nan
```

The result on FreeBSD 10.1 64 bit (clang++ 3.4.1):
```
stod ("nan") = nan
stod ("-nan") = nan
quiet_NaN () = nan
```

Is it correct that returning negative NaN on Cygwin?

Thanks.

--
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: g++ std::map initializing raises segmentation fault.

[Masamichi Hosoda]

> On 07/07/2017 16:21, Ivan Gagis wrote:
>> I installed g++ 6.3.0-2 and still can reproduce the segfault :(.
>>
>> Br,
>> Ivan
>>
> 
> It seems due to the -std=c++11 restriction
> 
> $ g++ foo.cc
> 
> $ ./a.exe
> Hello World!
> 
> $ g++ -std=c++11 foo.cc
> 
> $ ./a.exe
> Segmentation fault (core dumped)



Even if g++ 6.3.0-2 with `-std=c++11`,
there is no problem if cygwin-devel-2.8.0-1 is installed.



```
$ uname -a
CYGWIN_NT-10.0 inspiron5559 2.8.1(0.312/5/3) 2017-07-03 14:11 x86_64 Cygwin

$ cygcheck -c cygwin-devel
Cygwin Package Information
Package  VersionStatus
cygwin-devel 2.8.0-1OK

$ g++ --version
g++ (GCC) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ g++ -std=c++11 foo.cc

$ ./a
Hello World!

$ g++ -std=gnu++11 foo.cc

$ ./a
Hello World!

$
```



However, if cygwin-devel-2.8.1-1 is installed, segmentation fault is raised.



```
$ uname -a
CYGWIN_NT-10.0 inspiron5559 2.8.1(0.312/5/3) 2017-07-03 14:11 x86_64 Cygwin

$ cygcheck -c cygwin-devel
Cygwin Package Information
Package  VersionStatus
cygwin-devel 2.8.1-1OK

$ g++ --version
g++ (GCC) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ g++ -std=c++11 foo.cc

$ ./a
Segmentation fault (core dumped)

$ g++ -std=gnu++11 foo.cc

$ ./a
Hello World!

$
```



So the cause is cygwin-devel-2.8.1-1 in my humble opinion.

--
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: g++ std::map initializing raises segmentation fault.

[Masamichi Hosoda]

> On 07/07/2017 14:51, Marco Atzeri wrote:
>> On 06/07/2017 14:26, Masamichi Hosoda wrote:
>>> Hello,
>>>
>>> On Cygwin 2.8.1 x86_64, I've found that g++ std:map initializing
>>> may raise segmentation fault.
>>> The binary compiled with cygwin-devel-2.8.0-1
>>> does not raise segmentation fault
>>> even if on Cygwin 2.8.1 x86_64 environments.
>>>
>>
>> I can not replicate.
>>
> 
> Wrong. I can replicate.
> 
> One solution is to use the gcc-6.3.0-2 compiler in test
> 
> https://www.cygwin.com/ml/cygwin-announce/2017-06/msg00079.html

Thank you for your information.

If I understand correctly, there is three workaround solutions.

. Use g++ option `-std=gnu++11` instead of `-std=c++11`
TANNHAUSER Falk reported in
https://cygwin.com/ml/cygwin/2017-07/msg00089.html

I've tried this. It works fine.

. Downgrade `cygwin-devel` to 2.8.0-1 instead of 2.8.1-1.
I reported in
https://cygwin.com/ml/cygwin/2017-07/msg00088.html

Of course, it works fine in my environment.

. Use gcc-6.3.0-2 instead of gcc-5.4.0-1
You reported in
https://cygwin.com/ml/cygwin/2017-07/msg00109.html

I'd like to try this.

Thanks

--
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: [GCC] C++ program calling std::getline() crashes with certain compilation flags

[Masamichi Hosoda]

> The following C++ program crashes when compiled with GCC (both 5.4 and 6.3) 
> under Cygwin, when compiled with both an optimization level higher than -O0 
> (i.e. -O1, -O2 or -O3) and the C++ standard set to -std=c++nn (for any 
> supported nn, i.e. 98, 03, 11, 14 or 17):
> ```
> #include 
> #include 
> int main()
> {
> std::string s;
> std::getline(std::cin, s);
> std::cout << "You entered \"" << s << "\".\n";
> return 0;
> }
> ```
> On the other hand, when compiled with -std=gnu++nn or -O0, the program 
> executes normally. For details, run the attached Bash script test_getline.sh, 
> which produces the output contained in the attached file 
> test_getline_Cygwin.txt . No similar problem shows with GCC under Linux.
> It looks similar to the problem reported in 
> https://cygwin.com/ml/cygwin/2017-07/msg00088.html which appears to be 
> circumvented by passing -std=gnu++11 instead of -std=c++11.

I've tried it with both cygwin-devel-2.8.0-1 and cygwin-devel-2.8.1-1.
With cygwin-devel-2.8.1-1, reproduced.
With cygwin-devel-2.8.0-1, there is no problem.

I've attached the script that I used and the results.


test_getline.sh
Description: Binary data
CYGWIN_NT-10.0 Z87EXTREAM4 2.8.1(0.312/5/3) 2017-07-03 14:11 x86_64 Cygwin
base-cygwin   3.8-1
cygwin2.8.1-1
cygwin-debuginfo  2.8.1-1
cygwin-devel  2.8.0-1
g++ (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

### -std=c++98 -O0 ###: You entered "// Let's see if it works...".
### -std=c++98 -O1 ###: You entered "// Let's see if it works...".
### -std=c++98 -O2 ###: You entered "// Let's see if it works...".
### -std=c++98 -O3 ###: You entered "// Let's see if it works...".
### -std=c++03 -O0 ###: You entered "// Let's see if it works...".
### -std=c++03 -O1 ###: You entered "// Let's see if it works...".
### -std=c++03 -O2 ###: You entered "// Let's see if it works...".
### -std=c++03 -O3 ###: You entered "// Let's see if it works...".
### -std=c++11 -O0 ###: You entered "// Let's see if it works...".
### -std=c++11 -O1 ###: You entered "// Let's see if it works...".
### -std=c++11 -O2 ###: You entered "// Let's see if it works...".
### -std=c++11 -O3 ###: You entered "// Let's see if it works...".
### -std=c++14 -O0 ###: You entered "// Let's see if it works...".
### -std=c++14 -O1 ###: You entered "// Let's see if it works...".
### -std=c++14 -O2 ###: You entered "// Let's see if it works...".
### -std=c++14 -O3 ###: You entered "// Let's see if it works...".
### -std=c++17 -O0 ###: You entered "// Let's see if it works...".
### -std=c++17 -O1 ###: You entered "// Let's see if it works...".
### -std=c++17 -O2 ###: You entered "// Let's see if it works...".
### -std=c++17 -O3 ###: You entered "// Let's see if it works...".
### -std=gnu++98 -O0 ###: You entered "// Let's see if it works...".
### -std=gnu++98 -O1 ###: You entered "// Let's see if it works...".
### -std=gnu++98 -O2 ###: You entered "// Let's see if it works...".
### -std=gnu++98 -O3 ###: You entered "// Let's see if it works...".
### -std=gnu++03 -O0 ###: You entered "// Let's see if it works...".
### -std=gnu++03 -O1 ###: You entered "// Let's see if it works...".
### -std=gnu++03 -O2 ###: You entered "// Let's see if it works...".
### -std=gnu++03 -O3 ###: You entered "// Let's see if it works...".
### -std=gnu++11 -O0 ###: You entered "// Let's see if it works...".
### -std=gnu++11 -O1 ###: You entered "// Let's see if it works...".
### -std=gnu++11 -O2 ###: You entered "// Let's see if it works...".
### -std=gnu++11 -O3 ###: You entered "// Let's see if it works...".
### -std=gnu++14 -O0 ###: You entered "// Let's see if it works...".
### -std=gnu++14 -O1 ###: You entered "// Let's see if it works...".
### -std=gnu++14 -O2 ###: You entered "// Let's see if it works...".
### -std=gnu++14 -O3 ###: You entered "// Let's see if it works...".
### -std=gnu++17 -O0 ###: You entered "// Let's see if it works...".
### -std=gnu++17 -O1 ###: You entered "// Let's see if it works...".
### -std=gnu++17 -O2 ###: You entered "// Let's see if it works...".
### -std=gnu++17 -O3 ###: You entered "// Let's see if it works...".
CYGWIN_NT-10.0 Z87EXTREAM4 2.8.1(0.312/5/3) 2017-07-03 14:11 x86_64 Cygwin
base-cygwin   3.8-1
cygwin2.8.1-1
cygwin-debuginfo  2.8.1-1
cygwin-devel  2.8.1-1
g++ (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

### -std=c++98 -O0 ###: You entered "// Let's see if it works...".
### 

g++ std::map initializing raises segmentation fault.

[Masamichi Hosoda]

Hello,

On Cygwin 2.8.1 x86_64, I've found that g++ std:map initializing
may raise segmentation fault.
The binary compiled with cygwin-devel-2.8.0-1
does not raise segmentation fault
even if on Cygwin 2.8.1 x86_64 environments.

So I suspect cygwin-devel-2.8.1-1 is the cause.

Here's sample code for reproduce.

```
// foo.cc
// g++ -std=c++11 foo.cc

#include
#include

std::map m
{
  { 1, 1},
  { 2, 2}
};

int main ()
{
  std::cout << "Hello World!" << std::endl;
}
```

I've reproduced it on both Windows 7 64 bit and Windows 10 64 bit.

```
$ ./a
Segmentation fault (core dumped)

$
```

Here's my environment.

```
$ uname -a
CYGWIN_NT-10.0 Z87EXTREAM4 2.8.1(0.312/5/3) 2017-07-03 14:11 x86_64 Cygwin

$ g++ --version
g++ (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$
```

Thanks

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

[ANNOUNCEMENT] New: extractpdfmark-1.0.2-1

[Masamichi Hosoda]

The following package has been added to the Cygwin distribution:

* extractpdfmark-1.0.2-1

Extract PDFmark can extract page mode and named destinations
as PDFmark from PDF.
By using this you can get the small PDF files that have preserved
the page mode and the named destinations.

https://github.com/trueroad/extractpdfmark

--
Masamichi Hosoda

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

New: extractpdfmark-1.0.2-1

[Masamichi Hosoda]

The following package has been added to the Cygwin distribution:

* extractpdfmark-1.0.2-1

Extract PDFmark can extract page mode and named destinations
as PDFmark from PDF.
By using this you can get the small PDF files that have preserved
the page mode and the named destinations.

https://github.com/trueroad/extractpdfmark

--
Masamichi Hosoda

SSH key for upload access

[Masamichi Hosoda]

Name: Masamichi Hosoda
Package: extractpdfmark
 BEGIN SSH2 PUBLIC KEY 
B3NzaC1yc2EDAQABAAABAQDLomE4Lvlq++seGqMaRHR4qmxCc3w6xeWFOalEOD
9ohibY9BRZIMMH38FGqMT4Cpdj1IePntVektbbFTu8HGg+doqRjKaJ2HWg+6rL4xjbm2QN
9jSHby36JOoJPRrXgWJwLEaH+jcDsnFndLdoWMGxZ4dBRkE54xsr98q5ndJpkwjAa06AVE
FXkddWWqLihRtDRfsE3eiFy0dB8NgbkcOwZSWPnq9QXoOP0DRww9Tv55Oy+OpixrPg2FxE
cSOEcVTVBfq61r8vTPiE+ZtRDfM4ogQdlrB9R0XfPz5fvz0kfnDGW3+6EgA7GmX4dsvQ/k
t4dxgzKpDh+xRheW9WlFXn
 END SSH2 PUBLIC KEY 

Re: [ITP] extractpdfmark 1.0.2

[Masamichi Hosoda]

>> Extract PDFmark can extract page mode and named destinations
>> as PDFmark from PDF.
>> By using this you can get the small PDF files that have preserved
>> them.
> 
> Thanks.

Thank you for your reviewing.

> extractpdfmark.cygport:
> 
> DEPEND is for declaring build dependencies.  This should include
> libpoppler-devel

I've added it.

> runtime dependencies which aren't autodetected should be declared in
> REQUIRES.

texlive (pdftex), ghostscript (gs), and diffutils (diff)
are needed for testing "cygport extractpdfmark.cygport check".
They are not runtime dependencies.

I've added comment.

>> ldesc: "Extract PDFmark is able to extract page mode
>> and named destinations as PDFmark from PDF.
>> By using this you can get the small PDF files that have preserved
>> them."
> 
> The last sentence is a bit unclear to me.  What is the referent of the
> final "them"?.

Final "them" is
"the page mode and the named destinations".

I've added it.

extractpdfmark-1.0.2-1.hint:
category: Publishing Utils
requires: cygwin libgcc1 libpoppler66 libstdc++6 
sdesc: "Extract page mode and named destinations as PDFmark from PDF"
ldesc: "Extract PDFmark is able to extract page mode
and named destinations as PDFmark from PDF.
By using this you can get the small PDF files that have preserved
the page mode and the named destinations."

extractpdfmark-debuginfo-1.0.2-1.hint:
category: Debug
requires: cygwin-debuginfo
external-source: extractpdfmark
sdesc: "Debug info for extractpdfmark"
ldesc: "This package contains files necessary for debugging the
extractpdfmark package with gdb."

package files:
http://cygwin-packages.trueroad.jp/dist/x86_64/release/extractpdfmark/extractpdfmark-1.0.2-1.hint
http://cygwin-packages.trueroad.jp/dist/x86_64/release/extractpdfmark/extractpdfmark-1.0.2-1.tar.xz
http://cygwin-packages.trueroad.jp/dist/x86_64/release/extractpdfmark/extractpdfmark-1.0.2-1-src.tar.xz
http://cygwin-packages.trueroad.jp/dist/x86_64/release/extractpdfmark/extractpdfmark-debuginfo/extractpdfmark-debuginfo-1.0.2-1.hint
http://cygwin-packages.trueroad.jp/dist/x86_64/release/extractpdfmark/extractpdfmark-debuginfo/extractpdfmark-debuginfo-1.0.2-1.tar.xz
http://cygwin-packages.trueroad.jp/dist/x86/release/extractpdfmark/extractpdfmark-1.0.2-1.hint
http://cygwin-packages.trueroad.jp/dist/x86/release/extractpdfmark/extractpdfmark-1.0.2-1.tar.xz
http://cygwin-packages.trueroad.jp/dist/x86/release/extractpdfmark/extractpdfmark-1.0.2-1-src.tar.xz
http://cygwin-packages.trueroad.jp/dist/x86/release/extractpdfmark/extractpdfmark-debuginfo/extractpdfmark-debuginfo-1.0.2-1.hint
http://cygwin-packages.trueroad.jp/dist/x86/release/extractpdfmark/extractpdfmark-debuginfo/extractpdfmark-debuginfo-1.0.2-1.tar.xz

Thanks

[ITP] extractpdfmark 1.0.2

[Masamichi Hosoda]

Hi, all

Extract PDFmark can extract page mode and named destinations
as PDFmark from PDF.
By using this you can get the small PDF files that have preserved them.

Ubuntu has this package:
http://packages.ubuntu.com/zesty/extractpdfmark

(Also Debian stretch has it:
 https://packages.debian.org/stretch/extractpdfmark )

extractpdfmark-1.0.2-1.hint:
category: Publishing Utils
requires: cygwin libgcc1 libpoppler66 libstdc++6 
sdesc: "Extract page mode and named destinations as PDFmark from PDF"
ldesc: "Extract PDFmark is able to extract page mode
and named destinations as PDFmark from PDF.
By using this you can get the small PDF files that have preserved them."

extractpdfmark-debuginfo-1.0.2-1.hint:
category: Debug
requires: cygwin-debuginfo
external-source: extractpdfmark
sdesc: "Debug info for extractpdfmark"
ldesc: "This package contains files necessary for debugging the
extractpdfmark package with gdb."

package files:
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/extractpdfmark/extractpdfmark-1.0.2-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/extractpdfmark/extractpdfmark-1.0.2-1.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/extractpdfmark/extractpdfmark-1.0.2-1-src.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/extractpdfmark/extractpdfmark-debuginfo/extractpdfmark-debuginfo-1.0.2-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86_64/release/extractpdfmark/extractpdfmark-debuginfo/extractpdfmark-debuginfo-1.0.2-1.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/extractpdfmark/extractpdfmark-1.0.2-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/extractpdfmark/extractpdfmark-1.0.2-1.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/extractpdfmark/extractpdfmark-1.0.2-1-src.tar.xz
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/extractpdfmark/extractpdfmark-debuginfo/extractpdfmark-debuginfo-1.0.2-1.hint
https://trueroad.github.io/tr-cygwin-packages-dist/dist/x86/release/extractpdfmark/extractpdfmark-debuginfo/extractpdfmark-debuginfo-1.0.2-1.tar.xz

Thanks

Re: rename() cannot replace the file which is opened with writable access

[Masamichi Hosoda]

>> I've found that rename() cannot replace the file
>> which is opened with writable access on Cygwin.
>> On Linux, it works.
>> 
>> If I understand correctly, it should work under POSIX.
>> 
>> Here's sample code for reproduce.
> 
> Thanks for the testcase.  I applied a patch(*) and will upload a new
> developer snapshot for testing to https://cygwin.com/snapshots/
> at some point tomorrow.
> 
> 
> Corinna
> 
> (*) https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=6ed4753

The snapshot has been fixed the issue.
Thank you.

--
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: rename() cannot replace the file which is opened with writable access

[Masamichi Hosoda]

>> I've found that rename() cannot replace the file
>> which is opened with writable access on Cygwin.
>> On Linux, it works.
> 
> It is OS dependent behavior, and vary even on same OS.
> Windows may let you rename a file, or may not, depends on how exactly it is
> opened.

Thank you for your answer.

If I understand correctly,
POSIX behavior should be able to replace the writable opened file by rename().
But, It does not work on my Cygwin environment.

Is it no problem if Cygwin's behavior is different from POSIX behavior?
If so, we need different application handling for Cygwin and POSIX.

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

rename() cannot replace the file which is opened with writable access

[Masamichi Hosoda]

Hello,

I've found that rename() cannot replace the file
which is opened with writable access on Cygwin.
On Linux, it works.

If I understand correctly, it should work under POSIX.

Here's sample code for reproduce.

```
#include 
#include 
#include 

#define OLDPATH "oldpath"
#define NEWPATH "newpath"

int main ()
{
  int fd;
  struct flock fl;
  char buff[] = "test";

  /* create oldpath file */
  fd = open (OLDPATH, O_CREAT | O_RDWR | O_TRUNC, 0666);
  close (fd);

  /* create newpath file */
  fd = open (NEWPATH, O_CREAT | O_RDWR | O_TRUNC, 0666);

  /* rename *** FAILED on Cygwin *** */
  if (rename (OLDPATH, NEWPATH) < 0)
perror ("rename");

  close (fd);

  return 0;
}
```

Thanks

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