Nginx build under Debian Hurd i386

[Maxim Dounin]

Hello!

On Wed, Sep 28, 2011 at 10:39:26AM +0200, Cyril LAVIER wrote:

>   
> 
> Hi nginx lovers. 
> 
> As it's my first mail on this mailing list, I
> will introduce myself a little bit. 
> 
> I'm Cyril Lavier, a 25 years old
> System Administrator from France. I use nginx for barely a year now. I
> use it for my own website, and also for the company I'm working. 
> 
> Now,
> let's work :). 
> 
> For the Debian packaging purposes, we try to make nginx
> build properly under the hurd-i386 kernel. 
> 
> But it never built well,
> and Kartik sent a mail in January about this. 
> 
> Now, as I'm contributing
> to this packaging, I tried to figure out why nginx build failed. 
> 
> For
> this, I opened a ticket (http://trac.nginx.org/nginx/ticket/22), which
> provide a patch for this. With this patch it's building well and working
> well. 

There is a problem with this patch: nginx uses PATH_MAX to 
allocate buffer used in realpath(), and POSIX claims:

: If resolved_name is not a null pointer and {PATH_MAX} is not 
: defined as a constant in the <limits.h> header, the behavior is 
: undefined.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html

Just using arbitrary value instead of PATH_MAX will likely lead to 
a problem.  If we want to avoid usage of PATH_MAX the relevant 
code should be converted to use realpath() with NULL as 
resolved_name.

Other current use of PATH_MAX is for getcwd() buffer which should 
be ok with any buffer size as getcwd() interface includes "size" 
argument.

> After, we add the MP4 module to the nginx-extras package, but
> the module failed to compile under hurd-i386 (the build works like a
> charm on other architectures). 
> 
> I opened the ticket #23
> (http://trac.nginx.org/nginx/ticket/23), with a first draft of a patch,
> which resolves one issue. By the way, my C coding knowledge is too low
> to completely correct this issue. 
> 
> We would like the hurd package being
> the same as the others, so if the developers (or other contributors with
> sufficient knowledge) can take a look at both tickets, and judging about
> a patch inclusion for #22 and a more complete patch #23, this would be
> very appreciated. 

This looks like result of the fact that off_t used is 32-bit wide.  
I believe correct patch to support 32-bit off_t would require a 
bit more work.

Meanwhile, you may want to focus on using 64-bit off_t instead.  
Under Linux it's typically done with "#define _FILE_OFFSET_BITS 
64".  Is it possible to do the same on Debian GNU/Hurd?

Maxim Dounin