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 f
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 ma
.
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
> 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#issuecomme
> 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 exclud
>> 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",
>> langua
>> 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
> 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 o
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/ModuleSetupCod
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
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.
h
> 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 st
[...]
>> > 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 wron
", 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
strt
> 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 ()
{
st
> 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 du
> 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
> 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
> #in
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 fo
://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
>> 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 answe
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 "newp
28 matches
Mail list logo
