naviserver-devel — Developer discussion

[naviserver-devel] no mkstemp() on Windows, use TclpCreateTempFile()?

[Andrew P. <at...@pi...>]

mkstemp() does not exist on Windows, and Naviserver uses it in three
places:

  $ find . -name "*.[ch]" -print | xargs grep -in mkstemp 
  ./nsd/adpeval.c:1183:    fd = mkstemp(debugfile); 
  ./nsd/tclhttp.c:426:                fd = mkstemp(httpPtr->spoolFileName); 
  ./nsd/driver.c:2301:            sockPtr->tfd = mkstemp(sockPtr->tfile); 

We could stick in our own mkstemp() implementation.  Some starting
points for that may be:

  http://stackoverflow.com/questions/6036227/mkstemp-implementation-for-win32 
  http://sourceforge.net/p/mingw/bugs/2003/ 

But Tcl 8.4 and later already have TclpCreateTempFile() (two separate
implementations for Unix and Windows), which seems to solve the same
problem.  It returns a TclFile object, not a file descriptor.

Can/should Naviserver's existing users of mkstemp() be modified to
instead work with TclpCreateTempFile()?  Or will that not quite work,
and we should borrow some of the Windows version of TclpCreateTempFile()
for direct use in Naviserver?

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] recommended location for non-core Naviserver modules?

[Gustaf N. <ne...@wu...>]

The recommended structure is

   foo/naviserver/
   foo/modules/nsssl/
   foo/modules/nsorcacle/

This is at least, what you get by using the tar distributions from 
sourceforge.

-g

Am 23.09.14 17:47, schrieb Andrew Piskorski:
> That makes the think that nesting Mercurial checkouts is a bad idea, 
> and this more separated directory structure is the better choice:
>>    foo/nsoracle/
>>    foo/nsssl/

Re: [naviserver-devel] nsversion.h, running configure on Windows

[Gustaf N. <ne...@wu...>]

Dear Andrew,

the single place for specifying the version numbers is configure.ac,
from this nsversion.h filled with values. The tar-distributions of 
naviserver
contain nsversion.h with the right version numbers, so for porting from 
tar this
is a non-issue. The version numbers do not change so often. I guess, the
basic intention was to generate this file under some unix flavor or (under
cygwin if one wants to go this way) and copy it then to the native windows
build tree.

The bigger issue is probably to keep either the entries of 
include/nsconfig.h
in sync with the windows build (where HAVE_CONFIG_H is not defined), or
to configure a version of nsconfig.h manually for the capabilities of a 
native
windows build environment.

-g
Am 24.09.14 01:35, schrieb Andrew Piskorski:
> Naviserver's include/nsversion.h is auto-generated from nsversion.h.in
> when running configure (or autoconf).  How is that supposed to work
> when building on Windows?  I've avoided the problem for now by simply
> running configure on Linux and using the generated file, which
> obviously isn't the right approach.
>
> Is the idea to actually run configure on Windows, in Cygwin or
> something?  So far I have haven't needed it for anything else.
>
> Also, what is the point of generating nsversion.h like this anyway?
> All that file seems to do is define constants like NS_MAJOR_VERSION,
> so by using autoconf/configure, we set their canonical values in
> configure.ac rather than directly in nsversion.h.  Why is that a win?
>

[naviserver-devel] nsversion.h, running configure on Windows

[Andrew P. <at...@pi...>]

Naviserver's include/nsversion.h is auto-generated from nsversion.h.in
when running configure (or autoconf).  How is that supposed to work
when building on Windows?  I've avoided the problem for now by simply
running configure on Linux and using the generated file, which
obviously isn't the right approach.

Is the idea to actually run configure on Windows, in Cygwin or
something?  So far I have haven't needed it for anything else.

Also, what is the point of generating nsversion.h like this anyway?
All that file seems to do is define constants like NS_MAJOR_VERSION,
so by using autoconf/configure, we set their canonical values in
configure.ac rather than directly in nsversion.h.  Why is that a win?

-- 
Andrew Piskorski <at...@pi...>

[naviserver-devel] was Makefile.win32 deleted c. 2008?

[Andrew P. <at...@pi...>]

I forked naviserver on Bitbucket so I could start adding Windows nmake
build support.  I added two new files, "naviserver/Makefile.win32" and
"naviserver/include/Makefile.win32", but to my surprise, when I view
their history I see older commits back in 2007 and 2001 (by Vlad and
Dossy)!

  https://bitbucket.org/apiskors/naviserver/history-node/a5c978071e1d/Makefile.win32
  https://bitbucket.org/apiskors/naviserver/history-node/a5c978071e1d/include/Makefile.win32

What is going on here?  Were those file deleted at some point, and
then my adding them "revived" their old history?  But if so, why is
there nothing in the commit log about a delete?  Is this some sort of
artifact due to converting from CVS into Mercurial?

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] recommended location for non-core Naviserver modules?

[Andrew P. <at...@pi...>]

On Tue, Sep 23, 2014 at 11:27:33AM -0400, Andrew Piskorski wrote:

> Should they be placed like this:
> 
>   foo/naviserver/nsoracle/
>   foo/naviserver/nsssl/

I notice that if I put one checkout inside another like the above,
then when I do "hg -v log" while in the naviserver directory,
Mercurial does NOT recurse down into the nsoracle checkout at all.
And even doing an explicit "hg -v log nsoracle" does nothing!

That makes the think that nesting Mercurial checkouts is a bad idea,
and this more separated directory structure is the better choice:

>   foo/nsoracle/
>   foo/nsssl/

-- 
Andrew Piskorski <at...@pi...>

[naviserver-devel] recommended location for non-core Naviserver modules?

[Andrew P. <at...@pi...>]

The core Naviserver repository on Bitbucket includes several important
modules like nslog, nssock, etc., which are placed in this directory
structure:

  foo/naviserver/nslog/
  foo/naviserver/nssock/

A whole bunch of add-on modules (nsoracle, nsssl, nszlib, etc.) are
each in their own Mercurial repositories on Bibucket.  (I'm not sure
why; it'd seem simpler to me to have all the modules in the same
repository as the core server, but whatever.)

So in theory I can put the local working copy of each module anywhere
in my directory tree I want.  But what is the recommended convention?
Should they be placed like this:

  foo/naviserver/nsoracle/
  foo/naviserver/nsssl/

Or like this:

  foo/nsoracle/
  foo/nsssl/

Btw, with the modules I've looked at so far it seems like either
location should work, but I'm not sure if that's intentional (and a
feature that must be preserved) or an accident.

The Naviserver build scripts are setup to REQUIRE installing the core
Naviserver first, before building add-on modules.  Building the add-on
modules then uses the installed core headers and libraries rather than
from their original source checkout.

(In my own work I've preferred to do the opposite, build the core and
modules together using the same source tree and only install them once
together at the end, but I assume you folks have a good reason for
preferring their method.)

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] LIB nmake and environment variables collide on Windows

[Andrew P. <at...@pi...>]

On Thu, Sep 18, 2014 at 12:24:12PM +0200, Gustaf Neumann wrote:
> Am 17.09.14 23:19, schrieb Andrew Piskorski:
> > The Naviserver makefiles often definite a LIB variable, e.g.:
> >
> >    LIB = nsthread
> What is the exact problem you see: is it the case, when LIB is set
> in a Makefile (as cited), or is the problem, when it is *not* set.

Both.  When Naviserver sets LIB for its current "library name"
purpose, one, that prevents me from using it for the Windows linker,
AND I think the Windows linker still sees it and could break because
of it.

Also, currently in my Windows build work I NEED to set LIB for the
Windows linker to use.  Without it the linker fails.  There may be
some other way to get the Windows linker to do the right thing but
right now my only solution is to set its LIB environment variable
correctly.

So as they stand in my sandbox right now, LIB is actually used for two
entirely DIFFERENT purposes in the Linux vs. Windows parts of the
makefiles!  That's very confusing, and definitely something I want to
fix.

Right now in my sandbox I'm able to build the Naviserver nsthread
module on Windows 7 64-bit, but my changes definitely break the Linux
build.  So I will revisit that, get it cleaned up, and commit to a
fork on Bitbucket so others can actually see what I'm doing.  As part
of that I'll try to better verify what LIB is doing and think harder
about what a good fix is.

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] pid_t missing on Windows

[Gustaf N. <ne...@wu...>]

Am 18.09.14 18:33, schrieb Maurizio Martignano:
> I still do not quite understand/explain why the nsthread module is so
> different between Aolserver and Naviserver. And again as the two pieces of
> software are implemented at the moment, the Aolserver version seems to be
> more portable.
not sure, what you exactly refer to. the difference to aolserver is most 
likely
explained in several years of development, which did happen to a much
lesser degree on the aolserver side. naviserver has much functionality, 
that
aolserver does not have, containing e.g. multi-protocol support, 
including UDP etc.
If you read the annals, this support was a main reason for the split.

when you refer to differences in "nsthread.h", then the "problem" is not
the nsthread module, but a somwhat misleading name of this file,
since this is the central place, where all system dependencies are 
addressed.
It is natural, that a native windows port has to touch this.

all the best
-g

Re: [naviserver-devel] pid_t missing on Windows

[Maurizio M. <Mau...@sp...>]

Dear Gustav,
	This is ok.

I still do not quite understand/explain why the nsthread module is so
different between Aolserver and Naviserver. And again as the two pieces of
software are implemented at the moment, the Aolserver version seems to be
more portable.

Thank you,
Maurizio

-----Original Message-----
From: Gustaf Neumann [mailto:ne...@wu...] 
Sent: 18 September 2014 13:51
To: nav...@li...
Subject: Re: [naviserver-devel] pid_t missing on Windows


historically, unix used "int" for pids. the open group / ieee standard
defines pid_t  [1],  which is used e.g. for fork(), getpid(),
kill() etc.
on linux, mac os x etc. Therefore, the use of pid_t instead of "int"
is a good thing, especially, since pids are passed around as arguments and
returned by naviserver functions.

for keeping the code portable, the best thing is to define in naviserver
pid_t  as well for windows, but using HANDLE.

I've changed right now various places in naviserver, where pids are assumed
as "int", and added a definition for pid_t for win as well. everything
compiles still nicely under unix, i have not testes with windows, but things
should have become there better as well. Please get an update from
bitbucket.

-g

[1] http://pubs.opengroup.org/onlinepubs/007904975/toc.htm

Am 18.09.14 01:26, schrieb Andrew Piskorski:
> On Windows with the VC 2012 compiler I get this error, which seems to 
> then break a lot of other important stuff downstream:
>
>    thread.c(55) : error C2061: syntax error : identifier 'pid_t'
>
> Is pid_t defined anywhere for Windows?  AFAICT it is not.  Adding this 
> in an appropriate spot in nsthread.h makes the error go away:
>
>    #ifndef pid_t
>    typedef int pid_t;
>    #endif
>
> But I don't know whether that's actually a correct fix for the various 
> places that use pid_t.  Interestingly, in nsd/exec.c Ns_WaitForProcess 
> uses pid_t ONLY on Unix, and has a completely different implementation 
> for Windows, which uses a HANDLE type instead of pid_t.  And 
> winthread.c definitely uses HANDLE.  So it looks like use of the 
> Unix-only pid_t crept into a few of the nominally cross-platform files 
> over time.  But what's the correct fix?
>

----------------------------------------------------------------------------
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce Perforce version control.
Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
naviserver-devel mailing list
nav...@li...
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] NS_EXTERN set wrong on Windows?

[Gustaf N. <ne...@wu...>]

Am 18.09.14 00:50, schrieb Andrew Piskorski:
> AFAICT from reading that code, when using Microsoft's compiler
> NSTHREAD_EXPORTS is never set, and thus NS_STORAGE_CLASS is never set
> to NS_EXPORT, it is always set to NS_IMPORT and thus is wrong when
> building nsthread.
i think the intention was to set NSTHREAD_EXPORTS from the build-script
in windows. See e.g. win32/nsthread/nsthread.vcproj.
I would think, doing this as well from an nmake build should work as well.

-g

Re: [naviserver-devel] pid_t missing on Windows

[Gustaf N. <ne...@wu...>]

historically, unix used "int" for pids. the open group / ieee
standard defines pid_t  [1],  which is used e.g. for fork(), getpid(), 
kill() etc.
on linux, mac os x etc. Therefore, the use of pid_t instead of "int"
is a good thing, especially, since pids are passed around as
arguments and returned by naviserver functions.

for keeping the code portable, the best thing is
to define in naviserver pid_t  as well for windows, but using
HANDLE.

I've changed right now various places in naviserver, where
pids are assumed as "int", and added a definition for
pid_t for win as well. everything compiles still nicely
under unix, i have not testes with windows, but things
should have become there better as well. Please
get an update from bitbucket.

-g

[1] http://pubs.opengroup.org/onlinepubs/007904975/toc.htm

Am 18.09.14 01:26, schrieb Andrew Piskorski:
> On Windows with the VC 2012 compiler I get this error, which seems to
> then break a lot of other important stuff downstream:
>
>    thread.c(55) : error C2061: syntax error : identifier 'pid_t'
>
> Is pid_t defined anywhere for Windows?  AFAICT it is not.  Adding this
> in an appropriate spot in nsthread.h makes the error go away:
>
>    #ifndef pid_t
>    typedef int pid_t;
>    #endif
>
> But I don't know whether that's actually a correct fix for the various
> places that use pid_t.  Interestingly, in nsd/exec.c Ns_WaitForProcess
> uses pid_t ONLY on Unix, and has a completely different implementation
> for Windows, which uses a HANDLE type instead of pid_t.  And winthread.c
> definitely uses HANDLE.  So it looks like use of the Unix-only pid_t
> crept into a few of the nominally cross-platform files over time.  But
> what's the correct fix?
>

Re: [naviserver-devel] LIB nmake and environment variables collide on Windows

[Gustaf N. <ne...@wu...>]

Am 17.09.14 23:19, schrieb Andrew Piskorski:
> The Naviserver makefiles often definite a LIB variable, e.g.:
>
>    LIB = nsthread
What is the exact problem you see: is it the case, when LIB is set
in a Makefile (as cited), or is the problem, when it is *not* set.
In the latter case,  "make" picks up the value of the environment
variable and the logic in Makefile.module fails.

If the latter is the problem, would it be an option to set in the
makefiles LIB to empty and to change the logic from
"if LIB exists" to "exists and noempty" in Makefile.module?
Would this help for the windows nmake build?

> What's the best fix for this variable collision problem?  Would it be
> clearest to just rename all of Naviserver's uses of LIB to something
> else?  (DLL?  LIB_NAME?  MYLIB?)
Makefile.module defines

#     LIB         Root name of dynamic library (without lib prefix or 
extension)
#     LIBOBJS     List of library object files (required with LIB)
#     LIBHDRS     List of public header files to install (required with 
module LIB)

If we have to change the name, this involves potentially
all modules, making mixing versions of modules and naviserver impossible
(which is probably not a good idea either, and not so bad, since we have the
matching modules also in the sourceforge tar files).

Note that LIB is not not only used for dynamic builds, but as well for 
static builds,
so DLL is misleading. if we have to go this way, i would prefer
LIBRARY, also LIBNAME is an option, but MOD has a similar purpose
and is not called MODNAME (but is also not called MODULE).

> Note that I'm currently running into this because the example Windows
> nmake files Ibrahim Tannir of Archiware sent me mostly replace only
> include/Makefile.module, and re-use Naviserver's stock per-module
> makefiles.  At first glance that seems reasonable to me, as most of
> the per-module makefiles are very simple, and should presumably work
> correctly in both Gnu make and Window nmake.
replacing the Makefile.module for windows is as well also an option, and
is a more local change and gives finally more freedom for windows 
adjustments...

-g

Re: [naviserver-devel] pid_t missing on Windows

[Maurizio M. <Mau...@sp...>]

Dear Andrew,

Handles in windows are void pointers. 32 bit void pointers in Windows 32 and
64 bit void pointers in Windows 64 (obviously). However in WIN64 only the
less significant 32 bits of a handle are used for compatibility and
interoperability reasons.
So having
typedef int pid_t;
or
typedef HANDLE pid_t;
it is not quite the same.

Frankly what puzzles me is the huge code difference between the Aolserver
and Naviserver versions of this file (thread.c), and in general of all the
nsthread module.

I also have the feeling that the the Aolserver version is less OS dependent
and more portable.

Well yes, Naviserver has been ported on Windows but with MinGW and quite
likely only in Win32. I suspect that many other problems will show up in
Windows 64 and I sincerely hope you are concentrating your efforts on this
platform (Windows 64).

Hope this helps and thank you for your work,
Maurizio
 

-----Original Message-----
From: Andrew Piskorski [mailto:at...@pi...] 
Sent: 18 September 2014 01:26
To: nav...@li...
Subject: [naviserver-devel] pid_t missing on Windows

On Windows with the VC 2012 compiler I get this error, which seems to then
break a lot of other important stuff downstream:

  thread.c(55) : error C2061: syntax error : identifier 'pid_t'

Is pid_t defined anywhere for Windows?  AFAICT it is not.  Adding this in an
appropriate spot in nsthread.h makes the error go away:

  #ifndef pid_t
  typedef int pid_t;
  #endif 

But I don't know whether that's actually a correct fix for the various
places that use pid_t.  Interestingly, in nsd/exec.c Ns_WaitForProcess uses
pid_t ONLY on Unix, and has a completely different implementation for
Windows, which uses a HANDLE type instead of pid_t.  And winthread.c
definitely uses HANDLE.  So it looks like use of the Unix-only pid_t crept
into a few of the nominally cross-platform files over time.  But what's the
correct fix?

--
Andrew Piskorski <at...@pi...>

----------------------------------------------------------------------------
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce Perforce version control.
Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
naviserver-devel mailing list
nav...@li...
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

[naviserver-devel] pid_t missing on Windows

[Andrew P. <at...@pi...>]

On Windows with the VC 2012 compiler I get this error, which seems to
then break a lot of other important stuff downstream:

  thread.c(55) : error C2061: syntax error : identifier 'pid_t'

Is pid_t defined anywhere for Windows?  AFAICT it is not.  Adding this
in an appropriate spot in nsthread.h makes the error go away:

  #ifndef pid_t 
  typedef int pid_t; 
  #endif 

But I don't know whether that's actually a correct fix for the various
places that use pid_t.  Interestingly, in nsd/exec.c Ns_WaitForProcess
uses pid_t ONLY on Unix, and has a completely different implementation
for Windows, which uses a HANDLE type instead of pid_t.  And winthread.c
definitely uses HANDLE.  So it looks like use of the Unix-only pid_t
crept into a few of the nominally cross-platform files over time.  But
what's the correct fix?

-- 
Andrew Piskorski <at...@pi...>

[naviserver-devel] NS_EXTERN set wrong on Windows?

[Andrew P. <at...@pi...>]

In my Windows build work, I'm getting a lot of warnings like this one:

  master.c(67) : warning C4273: 'Ns_MasterLock' : inconsistent dll linkage
     ..\include\nsthread.h(597) : see previous definition of 'Ns_MasterLock'

The definition is of course in nsthread/master.c, which starts like so:

  void Ns_MasterLock(void)

The declaration in include/nsthread.h is:

  NS_EXTERN void Ns_MasterLock(void);

include/ns.h has this:

  #define NS_EXTERN                  extern NS_EXPORT

But I believe that is NOT relevent here because master.c, thread.h,
and nsthread.h (correctly) do NOT include ns.h.

Instead, I think it is the separate definition of NS_EXTERN in
nsthread.h that matters when building nsthread.  The code there gets
pretty tricky.  Tracing the dependencies backwards, I THINK the
relevent bits are:

  #ifdef _WIN32
  # define NS_EXPORT                   __declspec(dllexport)
  # define NS_IMPORT                   __declspec(dllimport)

  # define NS_EXTERN                   extern NS_STORAGE_CLASS

  # if defined(NSTHREAD_EXPORTS)
  #  define NS_STORAGE_CLASS            NS_EXPORT
  # else
  #  define NS_STORAGE_CLASS            NS_IMPORT
  # endif

  #if defined(__GNUC__) || defined(__MINGW32__)
  #define NSTHREAD_EXPORTS
  #endif

AFAICT from reading that code, when using Microsoft's compiler
NSTHREAD_EXPORTS is never set, and thus NS_STORAGE_CLASS is never set
to NS_EXPORT, it is always set to NS_IMPORT and thus is wrong when
building nsthread.

Why is that checking which compiler was used anyway?  Is the correct
fix simply to set NSTHREAD_EXPORTS unconditionally regardless of the
compiler?

I tried that, and it DOES make the warning for Ns_MasterLock go away.
However, I do still have more serious build errors after that point,
and then additional "inconsistent dll linkage" warnings (for
Ns_ThreadCreate, etc.) despite that change, so I'm not yet entirely
convinced that I correctly diagnosed the problem.

-- 
Andrew Piskorski <at...@pi...>

[naviserver-devel] LIB nmake and environment variables collide on Windows

[Andrew P. <at...@pi...>]

The Naviserver makefiles often definite a LIB variable, e.g.:

  LIB = nsthread

However, on Windows the LIB environment variable is a semicolon
separated list of paths where the linker will look for libraries:

  http://msdn.microsoft.com/en-us/library/6y6t9esh

This makes it hard to set the LIB linker path from inside makefiles
without the two colliding and breaking things.  Is there some good way
for me to keep the nmake variable and environment variable namespaces
separate on Windows, or are they necessarily mixed?

What's the best fix for this variable collision problem?  Would it be
clearest to just rename all of Naviserver's uses of LIB to something
else?  (DLL?  LIB_NAME?  MYLIB?)

Note that I'm currently running into this because the example Windows
nmake files Ibrahim Tannir of Archiware sent me mostly replace only
include/Makefile.module, and re-use Naviserver's stock per-module
makefiles.  At first glance that seems reasonable to me, as most of
the per-module makefiles are very simple, and should presumably work
correctly in both Gnu make and Window nmake.

But these sorts of speed bumps make me wonder if the approach is a
mistake and I'd be better off using a completely independent Windows
makefile.

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] Fastpath HEAD request content-length zero

[Peter C. <pe...@qc...>]

Thanks, I'll have a go at using that fix. At present I don't really care
about head-range requests and I don't know what the specs would say about
them either.

-- 
Peter Chaplin
Qcode Software Limited
www.qcode.co.uk
T 01463 896 483

On 8 September 2014 15:28, Gustaf Neumann <ne...@wu...> wrote:

> Am 08.09.14 13:06, schrieb Peter Chaplin:
> > I'm using fastpath to handle HEAD requests for static files, and
> > getting a "Content-Length: 0" response header.
> > is it a bug?
> unless the file has a length of 0 bytes, its a bug.
>
> i've added a quick fix to bitbucket, but some more testing is required
> (regression test cases)
> handing HEAD + complex Range requests is currently probably broken, not
> sure
> whether this is important and what the exact semantics are.
>
> -g
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

Re: [naviserver-devel] Fastpath HEAD request content-length zero

[Gustaf N. <ne...@wu...>]

Am 08.09.14 13:06, schrieb Peter Chaplin:
> I'm using fastpath to handle HEAD requests for static files, and 
> getting a "Content-Length: 0" response header.
> is it a bug?
unless the file has a length of 0 bytes, its a bug.

i've added a quick fix to bitbucket, but some more testing is required 
(regression test cases)
handing HEAD + complex Range requests is currently probably broken, not sure
whether this is important and what the exact semantics are.

-g

[naviserver-devel] Fastpath HEAD request content-length zero

[Peter C. <pe...@qc...>]

I'm using fastpath to handle HEAD requests for static files, and getting a
"Content-Length: 0" response header.
This seems to be contrary to the specs:
http://tools.ietf.org/html/rfc2616#section-14.13
is it a bug?
-- 
Peter Chaplin
Qcode Software Limited
www.qcode.co.uk
T 01463 896 483

Re: [naviserver-devel] the --enable-rpath option is broken?

[Gustaf N. <ne...@wu...>]

Am 03.09.14 00:06, schrieb Andrew Piskorski:
> Makefiles I understand, but Autoconf and configure not so much. Does 
> anyone have a good reference you can point me to for learning how to 
> debug this sort of autoconf hell? 
not sure about a good tutorial. unfortunately, the rpath depends on the 
OS, and on
Mac OS X, it is different to Linux. So, to really help you, i would have 
to set up the oracle
libs on Linux as well...

But maybe, the following helps:
- the rpath is handled via the tcl configuration (naviserver/m4/tcl.m4)
- it is supposed to be passed finally to the variables CCRFLAG and LDRFLAG
   in the installed naviserver/include/Makefile.global
- these variables are included finally in 
naviserver/include/Makefile.module
   in the rules for $(MOD) via NSLIBS

so, by looking at nsoracle, i see the following problems:
- the nsoracle/Makefile should include Makefile.module and not 
Makefile.global
- the reason, why it copied parts of Makefile.module seems to be related 
with
   the target of CASSANDRACLE

i have now made some more changes to bring nsoracle/Makefile closer
to the other NaviServer modules, and i still can compile and link under
Mac OS X.

Hope this help
-g

Re: [naviserver-devel] unknown type name off64_t

[Gustaf N. <ne...@wu...>]

Am 03.09.14 10:21, schrieb Gustaf Neumann:
> Am 02.09.14 22:31, schrieb Andrew Piskorski:
>> With all the latest sources, I still get the same error when building
>> nsoracle, no change.  I then redid my configure using "--with-zlib=/usr/lib",
>> but that seemed to make no difference, same error when using the stock ns.h.
> just to be sure. you are using the tip versions of naviserver and
> nsoracle from bitbucket?
one more idea: did you do an "hg pull" and then an "hg update"?

-g

Re: [naviserver-devel] unknown type name off64_t

[Gustaf N. <ne...@wu...>]

Am 02.09.14 22:31, schrieb Andrew Piskorski:
>
> With all the latest sources, I still get the same error when building
> nsoracle, no change.  I then redid my configure using "--with-zlib=/usr/lib",
> but that seemed to make no difference, same error when using the stock ns.h.
just to be sure. you are using the tip versions of naviserver and 
nsoracle from bitbucket?

The following change causes the CFLAGS to include the zlib include path
(after configuration and compilation in include/Makefile.global)
https://bitbucket.org/naviserver/naviserver/commits/89577366e888cc72b6858855ad9a89967a49965a

and this change is for adding the oracle options to the CFLAGS
https://bitbucket.org/naviserver/nsoracle/commits/2eac27630cb658983e14120ddb66d3b17955a19d

with these changes (+ reconfiguration of the naviserver build with 
--with-zlib + install) the include
flags for zlib are passed to the compilation of nsoracle.c. Don't you 
see this in the compilation
step ?

-g

Re: [naviserver-devel] the --enable-rpath option is broken?

[Andrew P. <at...@pi...>]

On Tue, Sep 02, 2014 at 05:14:50PM -0400, Andrew Piskorski wrote:
> I'm configuring Naviserver like so:
> 
>   export inst_dir=/usr/local/nsd-4.99.6-dtk-1 
>   AUTOCONF=autoconf2.50 ./autogen.sh --prefix=$inst_dir --enable-symbols --enable-rpath --with-tcl=/usr/lib/tcl8.5 --with-zlib=/usr/lib 
> 
> But to my surprise, even though I specified "--enable-rpath", the
> build does NOT emit the necessary "-Wl,-rpath,${inst_dir}" flag when
> calling gcc (or ld).  Anybody know why, or how to fix this?

I can get rpath to work by making this simple change to Makefile.global:

  ATP_RPATH    = -Wl,-rpath,${NAVISERVER}/lib 
  NSLIBS      += -L/usr/lib -ltcl8.5 ${DL_LIBS} ${LIBS} ${MATH_LIBS}  -Wl,--export-dynamic  -L/usr/lib $(ATP_RPATH) 

But of course the Makefile.global is auto-generated, and my change
above will vanish anytime I re-run configure.  And I am lost about how
to make autoconf/configure scripts support this properly.

Makefiles I understand, but Autoconf and configure not so much.  Does
anyone have a good reference you can point me to for learning how to
debug this sort of autoconf hell?

-- 
Andrew Piskorski <at...@pi...>

[naviserver-devel] the --enable-rpath option is broken?

[Andrew P. <at...@pi...>]

I'm configuring Naviserver like so:

  export inst_dir=/usr/local/nsd-4.99.6-dtk-1 
  AUTOCONF=autoconf2.50 ./autogen.sh --prefix=$inst_dir --enable-symbols --enable-rpath --with-tcl=/usr/lib/tcl8.5 --with-zlib=/usr/lib 

But to my surprise, even though I specified "--enable-rpath", the
build does NOT emit the necessary "-Wl,-rpath,${inst_dir}" flag when
calling gcc (or ld).  Anybody know why, or how to fix this?

Because of that, starting up my nsd immediately fails because it can't
find its own libraries:

  $ /usr/local/nsd-4.99.6-dtk-1/bin/nsd -f  -t /usr/local/nsd-4.99.6-dtk-1/conf/nsd-config.tcl 
  /usr/local/nsd-4.99.6-dtk-1/bin/nsd: error while loading shared libraries: libnsd.so: cannot open shared object file: No such file or directory 
  $ ldd /usr/local/nsd-4.99.6-dtk-1/bin/nsd 
        linux-vdso.so.1 =>  (0x00007fff45594000) 
        libnsd.so => not found 
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fefde7ea000) 
        /lib64/ld-linux-x86-64.so.2 (0x00007fefdebce000) 

Btw, why is "--disable-rpath" the default anyway?

-- 
Andrew Piskorski <at...@pi...>