# Nginx build under Debian Hurd i386 **URL:** \ **Category:** NGINX\ **Created:** [September 28, 2011, 10:40am UTC](https://www.ruby-forum.com/t/nginx-build-under-debian-hurd-i386/212285 "2011-09-28T10:40:13Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\ **Post date:** [September 28, 2011, 10:40am UTC](https://www.ruby-forum.com/t/nginx-build-under-debian-hurd-i386/212285/1 "2011-09-28T10:40:13Z")
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 A. 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 ([#22 (Nginx 1.1.4 can't build on Debian hurd-i386) – nginx](http://trac.nginx.org/nginx/ticket/22)), which provide a patch for this. With this patch it’s building well and working well. 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 ([#23 (MP4 module fails to build under Debian hurd-i386) – nginx](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. Thanks. ---
**Author:** ![Cyril\_LAVIER](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/dec6dc/32.png) [@Cyril\_LAVIER](https://www.ruby-forum.com/u/Cyril_LAVIER)\ **Post date:** [September 28, 2011, 3:33pm UTC](https://www.ruby-forum.com/t/nginx-build-under-debian-hurd-i386/212285/2 "2011-09-28T15:33:35Z")
On Wed, 28 Sep 2011 17:13:38 +0400, Maxim D. wrote: > > working > > [realpath](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. > > patch, > > 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 D. > > * * * > > nginx mailing list > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [mailman.nginx.org archive](http://mailman.nginx.org/mailman/listinfo/nginx) – Cyril “Davromaniak” Lavier ---
**Author:** ![Cyril\_LAVIER](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/dec6dc/32.png) [@Cyril\_LAVIER](https://www.ruby-forum.com/u/Cyril_LAVIER)\ **Post date:** [September 28, 2011, 3:14pm UTC](https://www.ruby-forum.com/t/nginx-build-under-debian-hurd-i386/212285/3 "2011-09-28T15:14:28Z")
Hello! On Wed, Sep 28, 2011 at 10:39:26AM +0200, Cyril LAVIER wrote: > to this packaging, I tried to figure out why nginx build failed. > > For > this, I opened a ticket ([#22 (Nginx 1.1.4 can't build on Debian hurd-i386) – nginx](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 \ header, the behavior is : undefined. > **[realpath](https://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. > 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 D.