Nginx build under Debian Hurd i386

Cyril LAVIER cyril.lavier at
Wed Sep 28 13:32:54 UTC 2011

 On Wed, 28 Sep 2011 17:13:38 +0400, Maxim Dounin wrote:
> 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 (, 
>> 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.
> 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.

 Thanks for this information.

 I was not aware of this, and also I don't have a big knowledge in C 
 coding, I patched the file the easy way, by choosing an arbitrary value 
 for PATH_MAX, but as it may cause problems, we may see a more accurate 

 Maybe Igor or any other developer can help providing a solution for 
 this issue, because I know I won't be able to do a clean patch.

> 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
>> (, 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?

 I don't know, as I said earlier, my knowledge in this domain is 
 limited, but I just wanted to research a bit to try to help resolve this 

 Maybe Kartik will have this information, or maybe any other person in 
 this mailing list.


> Maxim Dounin
> _______________________________________________
> nginx mailing list
> nginx at

 Cyril "Davromaniak" Lavier

More information about the nginx mailing list