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

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx