You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Pavel Novy <no...@feld.cvut.cz> on 2001/09/12 16:55:04 UTC
[PATCH] Apache 1.3 - mod_auth etc.
Hi all,
after last changes in a src/modules/standard/mod_auth.c file it is
impossible to compile the Apache core for NetWare platform. I can't
understand why these changes have been commited untested. Patch
attached. Thanks.
Pavel
P.S.: The second try with my older (gcc related) proposed updates in
src/include/util_uri.h and src/os/netware/os.h files. Attached.
Re: [PATCH] Apache 1.3 - mod_auth etc.
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Pavel Novy wrote:
>
> after last changes in a src/modules/standard/mod_auth.c file it is
> impossible to compile the Apache core for NetWare platform. I can't
> understand why these changes have been commited untested.
Well, that's how things work. I posted the patch for a few
days to let people try it, since I do not use all possible
platforms, and then, as advertised, committed it. NetWare
and Windows needed fixing, and they were, and that's how
the process works.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"All right everyone! Step away from the glowing hamburger!"
Re: [PATCH] Apache 1.3 - mod_auth etc.
Posted by Pavel Novy <no...@feld.cvut.cz>.
Hi,
William A. Rowe, Jr. wrote:
> From: "Pavel Novy" <no...@feld.cvut.cz>
> Sent: Wednesday, September 12, 2001 9:55 AM
>
>
>
>>Hi all,
>>
>>after last changes in a src/modules/standard/mod_auth.c file it is
>>impossible to compile the Apache core for NetWare platform. I can't
>>understand why these changes have been commited untested. Patch
>>attached. Thanks.
>>
>
> That's fine - applied. I expect OS2 needs this patch as well?
Sorry, I'm not familiar with OS/2 port.
>
>>P.S.: The second try with my older (gcc related) proposed updates in
>>src/include/util_uri.h and src/os/netware/os.h files. Attached.
>>
>
> Comments follow;
>
>
>>--- src/os/netware/os.h Wed Aug 22 00:12:00 2001
>>+++ src_gcc/os/netware/os.h Sun Sep 2 02:23:36 2001
>>@@ -136,7 +136,7 @@
>> void AMCSocketCleanup(void);
>> void clean_parent_exit(int code);
>>
>>-inline int ap_os_is_path_absolute(const char *file)
>>+static inline int ap_os_is_path_absolute(const char *file)
>>
>
> Aren't there some compilers with serious problems about static and
inline being
> mutually exclusive??? I would suspect inline is sufficient here for
all Netware
> compilers, no?
Basically, it's impossible to link Apache core for NetWare with GNU
stuff due duplicate symbol produced in all object files generated from
sources with "#include <os.h>". It looks like gcc related issue (the
same behaviour on Linux) - I've attached a simple sample demonstrating
this issue in some of my older postings, but didn't get no response
here. Sorry, but I'm still not too familiar with the GNU (gcc) stuff to
resolve the issue. Take a look on attached sample, if you are
interested, please.
>
>>--- util_uri.h.orig Mon Feb 26 16:49:32 2001
>>+++ util_uri.h Mon Aug 27 15:44:41 2001
>>@@ -106,10 +106,10 @@
>>
>> unsigned short port; /* The port number, numeric, valid only if
port_str != NULL */
>>
>>- unsigned is_initialized:1;
>>+ unsigned char is_initialized:1;
>>
>>- unsigned dns_looked_up:1;
>>- unsigned dns_resolved:1;
>>+ unsigned char dns_looked_up:1;
>>+ unsigned char dns_resolved:1;
>>
>> } uri_components;
>>
>
> Out of the question. If I didn't say so before, I explicitly veto
this solution.
> EVERYBODY has this problem. Solaris, HP, etc _all_ are binary
incompatable with
> gcc results.
>
> Apache 2.0 -should- strive to resolve these, when we can. But we
aren't breaking
> binary compatibility for one platform in the 1.3 series with a
non-standard, and
> possibily incompatible fix. For that matter, this patch may even
*break* compatibility
> between different big-endian compilers. It's not worth rolling the dice.
Okay, I am definitively giving it up. I hope that these strange
compatibility issues will not appear in 2.0 - I suggest to not use the
bitfields anymore.
> Bill
>
Thanks for your response.
Regards,
Pavel
Re: [PATCH] Apache 1.3 - mod_auth etc.
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Pavel Novy" <no...@feld.cvut.cz>
Sent: Wednesday, September 12, 2001 9:55 AM
> Hi all,
>
> after last changes in a src/modules/standard/mod_auth.c file it is
> impossible to compile the Apache core for NetWare platform. I can't
> understand why these changes have been commited untested. Patch
> attached. Thanks.
That's fine - applied. I expect OS2 needs this patch as well?
> P.S.: The second try with my older (gcc related) proposed updates in
> src/include/util_uri.h and src/os/netware/os.h files. Attached.
Comments follow;
> --- src/os/netware/os.h Wed Aug 22 00:12:00 2001
> +++ src_gcc/os/netware/os.h Sun Sep 2 02:23:36 2001
> @@ -136,7 +136,7 @@
> void AMCSocketCleanup(void);
> void clean_parent_exit(int code);
>
> -inline int ap_os_is_path_absolute(const char *file)
> +static inline int ap_os_is_path_absolute(const char *file)
Aren't there some compilers with serious problems about static and inline being
mutually exclusive??? I would suspect inline is sufficient here for all Netware
compilers, no?
> --- util_uri.h.orig Mon Feb 26 16:49:32 2001
> +++ util_uri.h Mon Aug 27 15:44:41 2001
> @@ -106,10 +106,10 @@
>
> unsigned short port; /* The port number, numeric, valid only if port_str != NULL */
>
> - unsigned is_initialized:1;
> + unsigned char is_initialized:1;
>
> - unsigned dns_looked_up:1;
> - unsigned dns_resolved:1;
> + unsigned char dns_looked_up:1;
> + unsigned char dns_resolved:1;
>
> } uri_components;
Out of the question. If I didn't say so before, I explicitly veto this solution.
EVERYBODY has this problem. Solaris, HP, etc _all_ are binary incompatable with
gcc results.
Apache 2.0 -should- strive to resolve these, when we can. But we aren't breaking
binary compatibility for one platform in the 1.3 series with a non-standard, and
possibily incompatible fix. For that matter, this patch may even *break* compatibility
between different big-endian compilers. It's not worth rolling the dice.
Bill
Re: so modules, libtool and position independent code
Posted by Sascha Schumann <sa...@schumann.cx>.
> Depends on the platform. You cannot link non-PIC code with PIC code on
> HP-UX.
Yes, I was speaking in the context of FreeBSD where the
person I was replying to had specific problems.
- Sascha Experience IRCG
http://schumann.cx/ http://schumann.cx/ircg
Re: so modules, libtool and position independent code
Posted by ne...@thewrittenword.com.
On Wed, Sep 12, 2001 at 05:27:07PM +0200, Sascha Schumann wrote:
> > First - I don't understand why it works, since libpython is not PIC (-fpic
> > is not used when compiling). From reading what I could find on the
> > subject, it's supposed to crash miserably.
>
> You can use non-PIC code in shared libraries with the
> disadvantage that pages cannot be shared between unrelated
> processes, because each process needs to maintain its own
> relocated copy (they should be shared between parent/children
> though).
Depends on the platform. You cannot link non-PIC code with PIC code on
HP-UX.
> > Second - is libtool's refusal to link with non-libtool libraries an issue
> > for other module writers, and what is the recommended way to go around it?
> > The only solution I could think of was not using apxs.
>
> Libtool is capable of linking shared libraries against static
> code since version 1.3d. Prior to that, there were patches
> available to add this feature to libtool.
I think it issues a warning and does so only on platforms that allow
it.
--
albert chin (china@thewrittenword.com)
Re: so modules, libtool and position independent code
Posted by Sascha Schumann <sa...@schumann.cx>.
> First - I don't understand why it works, since libpython is not PIC (-fpic
> is not used when compiling). From reading what I could find on the
> subject, it's supposed to crash miserably.
You can use non-PIC code in shared libraries with the
disadvantage that pages cannot be shared between unrelated
processes, because each process needs to maintain its own
relocated copy (they should be shared between parent/children
though).
> Second - is libtool's refusal to link with non-libtool libraries an issue
> for other module writers, and what is the recommended way to go around it?
> The only solution I could think of was not using apxs.
Libtool is capable of linking shared libraries against static
code since version 1.3d. Prior to that, there were patches
available to add this feature to libtool.
- Sascha Experience IRCG
http://schumann.cx/ http://schumann.cx/ircg
so modules, libtool and position independent code
Posted by "Gregory (Grisha) Trubetskoy" <gr...@modpython.org>.
Here is my issue - mod_python.so needs to be statically linked against
libpython. Apxs (or libtool rather) refuses to do it because it has no
guarantee that libpython is PIC. (I believe this behaviour can be
overriden on some os's versions of libtool, but that's neither here nor
there since libtool is abstracted by apxs anyway)
If I link manually with "ld -G" (tried on FreeBSD 4.3 and Solaris 8)
mod_python.so works just fine.
First - I don't understand why it works, since libpython is not PIC (-fpic
is not used when compiling). From reading what I could find on the
subject, it's supposed to crash miserably.
Second - is libtool's refusal to link with non-libtool libraries an issue
for other module writers, and what is the recommended way to go around it?
The only solution I could think of was not using apxs.
Thanks!
Grisha