For details, see below.
Here is a new patch, which applies the MAX_PATH fix
in os_win.c to Cygwin as well.
Additional remark: This is not a bug in Cygwin64:
calling win32 functions from Cygwin executables is
unsupported even though it normally works fine
(GetTempPath apparently is one of the functions
which cannot be thrusted from the Cygwin environment).
I don't know why it appears to work in Cygwin32, that
might be related to my environment setup.
Regards,
Jan Nijtmans
2013/8/1 Jan Nijtmans:
> Hi Joe, Richard,
>
> Are you aware of the SQLite bug being discussed here:
> http://cygwin.com/ml/cygwin/2013-06/msg00181.html
> and here:?
> http://comments.gmane.org/gmane.comp.db.sqlite.general/81718
>
> Building latest Fossil on Cygwin64 gives the same problem, so I
> was able to debug this. Here is my proposed patch.
>
> Explanation:
> When Cygwin starts, it copies all win32 environment variables to its
> own UTF-8-aware environment and then clears the win32 env vars.
> This means that osGetTempPath[W|A] is no longer able to
> determine the value of the tempdir, so we have to do it ourselves
> using getenv() with the proper path translations.
>
> With this patch, I am able to build and run latest fossil on
> Cygwin32/64 (copying the re-generated sqlite3.[ch] there)
>
> Joe, I saw your latest Cygwin/win32-related enhancements, so I
> hope this helps bringing the Cygwin build back to where it was again.
>
> Regards,
> Jan Nijtmans
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
