Hi!
I am closely monitoring all that is happening.
We have significant investment in NS. For the
time being we run our own stable copy because
of the sensitivity of our application. But we
sync up every now and then, if needed.
Stephen is still arround and keeping an
eye on all changes.
IIRC, Vl
Stephen,
the Docker image is cool stuff! Many thanks!
This eases mingw builds significantly.
It compiles now fine the first bunch of files in nsthread
fine, but stops then with
x86_64-w64-mingw32-gcc -shared -L../nsthread -L../nsd
-L../nsdb -o libnsthread.dll error.o master.o memory.o
mutex.o
On Tue, Oct 7, 2014 at 12:11 PM, Gustaf Neumann wrote:
>
> Stephen,
>
> the Docker image is cool stuff! Many thanks!
> This eases mingw builds significantly.
>
> It compiles now fine the first bunch of files in nsthread
> fine, but stops then with
>
> x86_64-w64-mingw32-gcc -shared -L../nsthread -
On Fri, Oct 03, 2014 at 04:16:41PM +0200, Maurizio Martignano wrote:
> Dear Andrew,
> These are the basic options I would use for a Windows 64 bit, AMD64:
>
> COPTS = /EHsc /W3 /nologo /c
> DEFS = $(DEFS) /D "_WINDOWS" /D "TCL_THREADS=1" /D "WIN32" /D "_WIN32" \
> /D "FD_SETSIZE=128
On Tue, Oct 07, 2014 at 12:09:41AM +0200, Gustaf Neumann wrote:
> Please something more to try: to provide some potential evidence for
> my "too early for tcl calls" hypothesis, i've deactivated for the
> time being the mutex time monitoring for windows, since the earliest
> calls are from mutex c
On Mon, Oct 06, 2014 at 05:18:08PM -0400, Andrew Piskorski wrote:
> On Sun, Oct 05, 2014 at 09:37:39PM +0200, Maurizio Martignano wrote:
> > > Did you use the define _USE_32BIT_TIME_T yes or not?
> I haven't tried using _USE_32BIT_TIME_T yet, but I think using it
> would be INCORRECT on Windows-64
On Tue, Oct 07, 2014 at 04:09:02PM -0400, Andrew Piskorski wrote:
> C:\> C:\web\nsd-atp\bin\nsd -c
> [384.e14][-main-] Notice: nsmain: NaviServer/4.99 starting
> [384.e14][-main-] Fatal: nsthreads: localtime_s failed in ns_localtime: win32
> err: 22
In ns_localtime(), I changed this call:
er
On Tue, Oct 07, 2014 at 05:02:41PM -0400, Andrew Piskorski wrote:
> And yet it still fails in exactly the same way, with EINVAL = 22.
> This makes me think there is nothing wrong with the tlsPtr code or
> data, rather something is seriously broken in my build.
I think my analysis above was entire
On Tue, Oct 07, 2014 at 12:09:41AM +0200, Gustaf Neumann wrote:
> Please something more to try: to provide some potential evidence for
> my "too early for tcl calls" hypothesis, i've deactivated for the
> time being the mutex time monitoring for windows, since the earliest
> calls are from mutex c
Hm, this warning sounds kind of scary:
sockfile.c(351) : warning C4293: '>>' : shift count negative or too big,
undefined behavior
That's in the Windows-only implementation of pread(), in nsd/sockfile.c:
overlapped.Offset = (DWORD)offset;
overlapped.OffsetHigh = ((DWORD)offset >> 32);
Dear Andrew,
Sorry for the late reply, but have been away of my computer.
1. _USE_32BIT_TIME_T
Indeed, you are absolutely write. My Windows distribution had since 2011 to
2013 both Windows 32 and Windows 64 binaries.
I was using more or less the same make and configuration files to build i
Dear Andrew,
Yes, it is a potential issue.
http://sonarsrv.spazioit.com:9000/dashboard/index?id=my%3Anaviserver%3Ansd%2
Fsockfile.c
Maurizio
-Original Message-
From: Andrew Piskorski [mailto:a...@piskorski.com]
Sent: 08 October 2014 07:48
To: naviserver-devel@lists.sourceforge.n
12 matches
Mail list logo
