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), 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), 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.
On Wed, 28 Sep 2011 17:13:38 +0400, Maxim D. wrote:
working
realpath
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
[email protected]
nginx Info Page
–
Cyril “Davromaniak” Lavier
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), 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.
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.