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
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
.
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
.
This is an update to the latest upstream release.
https://github.com/trueroad/extractpdfmark
--
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.
> 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
> 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
>> 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",
>>
>> 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
> 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
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
+++
.
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
.
This is an update to the latest upstream release.
https://github.com/trueroad/extractpdfmark
--
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.
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.
> 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
> 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
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
> 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
[...]
>> > 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
LL) = 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 ("
> 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
>> >
>>> 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 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
> 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
>>
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 ()
{
> 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
> 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 cygw
> 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
>
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
://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
://github.com/trueroad/extractpdfmark
--
Masamichi Hosoda
Name: Masamichi Hosoda
Package: extractpdfmark
BEGIN SSH2 PUBLIC KEY
B3NzaC1yc2EDAQABAAABAQDLomE4Lvlq++seGqMaRHR4qmxCc3w6xeWFOalEOD
9ohibY9BRZIMMH38FGqMT4Cpdj1IePntVektbbFTu8HGg+doqRjKaJ2HWg+6rL4xjbm2QN
9jSHby36JOoJPRrXgWJwLEaH+jcDsnFndLdoWMGxZ4dBRkE54xsr98q5ndJpkwjAa06AVE
>> 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
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:
>> 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
>> 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
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
38 matches
Mail list logo
