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 (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.
>

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
fix.

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

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
issue.

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

Thanks.

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

--
Cyril "Davromaniak" Lavier

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