Re: svn commit: r1834513 - in /apr/apr/branches/1.6.x: STATUS file_io/win32/buffer.c

[jean-frederic clere]

On 27/06/18 19:08, William A Rowe Jr wrote:
> Any reason this is absent from development branch 1.7.x? I think all such
> 1.x-only issues should be started there. (Similarly with apr-util.)

Oops my bad :-( Thanks!
and I need to check if the trunk code can be use there:
file->flags & APR_FOPEN_XTHREAD instead file->mutex

Cheers

Jean-Frederic

> 
> On Wed, Jun 27, 2018 at 10:21 AM,  > wrote:
> 
> Author: jfclere
> Date: Wed Jun 27 15:21:19 2018
> New Revision: 1834513
> 
> URL: http://svn.apache.org/viewvc?rev=1834513=rev
> 
> Log:
> remove the wrong proposal in STATUS and commit a fix for my crash
> problems.
> 
> Modified:
>     apr/apr/branches/1.6.x/STATUS
>     apr/apr/branches/1.6.x/file_io/win32/buffer.c
> 
> Modified: apr/apr/branches/1.6.x/STATUS
> URL:
> 
> http://svn.apache.org/viewvc/apr/apr/branches/1.6.x/STATUS?rev=1834513=1834512=1834513=diff
> 
> 
> 
> ==
> --- apr/apr/branches/1.6.x/STATUS [utf-8] (original)
> +++ apr/apr/branches/1.6.x/STATUS [utf-8] Wed Jun 27 15:21:19 2018
> @@ -98,10 +98,6 @@ CURRENT VOTES:
>        1.5.x patch:
> http://people.apache.org/~jim/patches/apr-1.5-permset.patch
> 
>        +1:
> 
> -    * make sure we don't unlock mutex when we haven't locked it.
> -      1.6.x patch:
> http://people.apache.org/~jfclere/patch.180618.txt
> 
> -      +1 jfclere
> -
>  CURRENT test/testall -v EXCEPTIONS:
> 
>      Please add any platform anomilies to the following exception list.
> 
> Modified: apr/apr/branches/1.6.x/file_io/win32/buffer.c
> URL:
> 
> http://svn.apache.org/viewvc/apr/apr/branches/1.6.x/file_io/win32/buffer.c?rev=1834513=1834512=1834513=diff
> 
> 
> 
> ==
> --- apr/apr/branches/1.6.x/file_io/win32/buffer.c (original)
> +++ apr/apr/branches/1.6.x/file_io/win32/buffer.c Wed Jun 27
> 15:21:19 2018
> @@ -23,13 +23,17 @@ APR_DECLARE(apr_status_t) apr_file_buffe
>  {
>      apr_status_t rv;
> 
> -    apr_thread_mutex_lock(file->mutex);
> +    if (file->mutex) {
> +        apr_thread_mutex_lock(file->mutex);
> +    }
> 
>      if(file->buffered) {
>          /* Flush the existing buffer */
>          rv = apr_file_flush(file);
>          if (rv != APR_SUCCESS) {
> -            apr_thread_mutex_unlock(file->mutex);
> +            if (file->mutex) {
> +                apr_thread_mutex_unlock(file->mutex);
> +            }
>              return rv;
>          }
>      }
> @@ -48,7 +52,9 @@ APR_DECLARE(apr_status_t) apr_file_buffe
>              file->buffered = 0;
>      }
> 
> -    apr_thread_mutex_unlock(file->mutex);
> +    if (file->mutex) {
> +        apr_thread_mutex_unlock(file->mutex);
> +    }
> 
>      return APR_SUCCESS;
>  }
> 
> 
> 


-- 
Cheers

Jean-Frederic

Re: svn commit: r1833786 - /apr/apr/branches/1.6.x/STATUS

[jean-frederic clere]

On 21/06/18 10:36, Rainer Jung wrote:
> Am 21.06.2018 um 10:24 schrieb jean-frederic clere:
>> On 21/06/18 10:04, Yann Ylavic wrote:
>>> On Thu, Jun 21, 2018 at 8:00 AM, jean-frederic clere
>>>  wrote:
>>>>
>>>> OK if everyone agrees I will just commit my small fix and don't
>>>> backport
>>>> the 2 other revisions.
>>>
>>> Are we looking at the same 1.6.x code?
>>> For me apr_file_buffer_set() locks the mutex unconditionally so it
>>> must unlock it likewise, I don't understand what your patch solves.
>>
>> that is what my patch is doing ;-)
> 
> Please be more explicit. I agree with Yann. From current unpatched APR
> 1.6.x file_io/win32/buffer.c:
> 
> APR_DECLARE(apr_status_t) apr_file_buffer_set(apr_file_t *file,
>   char * buffer,
>   apr_size_t bufsize)
> {
> ...
>     apr_thread_mutex_lock(file->mutex);
> 
>     if(file->buffered) {
> ...
>     if (rv != APR_SUCCESS) {
>     apr_thread_mutex_unlock(file->mutex);
>     return rv;
>     }
>     }
> 
> ... (no return)
> 
>     apr_thread_mutex_unlock(file->mutex);
> 
>     return APR_SUCCESS;
> }
> 
> So where's the problem? Unconditional "apr_thread_mutex_lock" and
> unconditional "apr_thread_mutex_unlock" on every path before return.
> 
> Looking at your patch
> "http://people.apache.org/~jfclere/patches/patch.180618.txt; (STATUS
> still contains a broken link, so we need to guess):
> 
> Index: file_io/win32/buffer.c
> ===
> --- file_io/win32/buffer.c    (revision 1833783)
> +++ file_io/win32/buffer.c    (working copy)
> @@ -47,8 +47,10 @@
>   */
>  file->buffered = 0;
>  }
> -
> -    apr_thread_mutex_unlock(file->mutex);
> +
> +    if (file->buffered) {
> +    apr_thread_mutex_unlock(file->mutex);
> +    }
> 
>  return APR_SUCCESS;
>  }
> 
> 
> any call to "apr_file_buffer_set" for a file with "buffered" not set
> will end with not giving back the lock.

Correct... My problem is that file->mutex is NULL not that the file is
buffered or not...

> 
> Regards,
> 
> Rainer
> 


-- 
Cheers

Jean-Frederic

Re: svn commit: r1833786 - /apr/apr/branches/1.6.x/STATUS

[jean-frederic clere]

On 21/06/18 10:04, Yann Ylavic wrote:
> On Thu, Jun 21, 2018 at 8:00 AM, jean-frederic clere  
> wrote:
>>
>> OK if everyone agrees I will just commit my small fix and don't backport
>> the 2 other revisions.
> 
> Are we looking at the same 1.6.x code?
> For me apr_file_buffer_set() locks the mutex unconditionally so it
> must unlock it likewise, I don't understand what your patch solves.

that is what my patch is doing ;-)

> 
> Regards,
> Yann.
> 


-- 
Cheers

Jean-Frederic

Re: svn commit: r1833786 - /apr/apr/branches/1.6.x/STATUS

[jean-frederic clere]

On 21/06/18 01:08, Evgeny Kotkov wrote:
> William A Rowe Jr  writes:
> 
>> Confusing... which patch is missing?
>>
>> http://svn.apache.org/viewvc?view=revision=1808457
>> http://svn.apache.org/viewvc?view=revision=1829962
>>
>> It should not be possible at this point to need 1.x specific code
>> that wouldn't correspond to a trunk commit.
> 
> I think that r1829962 should be treated as a follow-up to r1808457
> (where I missed one calling site of apr_thread_mutex_unlock() in buffer.c).
> 
> In other words, they should either be backported together, or not backported
> at all.  Since this change is a relatively minor optimization (not a fix),
> I would think that it might make sense to keep it just in trunk.

Actually it is a fix logresolve cores without it ;-)

OK if everyone agrees I will just commit my small fix and don't backport
the 2 other revisions.

Cheers

Jean-Frederic

> 
> 
> Thanks,
> Evgeny Kotkov
> 

Re: svn commit: r1833786 - /apr/apr/branches/1.6.x/STATUS

[jean-frederic clere]

On 19/06/18 11:02, Yann Ylavic wrote:
> Hi Jean-Frédéric,
> 
> On Tue, Jun 19, 2018 at 10:01 AM,   wrote:
>> Author: jfclere
>> Date: Tue Jun 19 08:01:45 2018
>> New Revision: 1833786
>>
>> URL: http://svn.apache.org/viewvc?rev=1833786=rev
>> Log:
>> proposal for review.
> 
> Usually APR backports are CTR (Commit Then Review), but it does not
> prevent to propose them first ;)
> I don't find the corresponding trunk commit here, though.

Trunk is quite different the missing piece in 1.6.x is in
file_io/win32/buffer.c line 55 (trunk is good).

> 
>>
>> +* make sure we don't unlock mutex when we haven't locked it.
>> +  1.6.x patch: http://people.apache.org/~jfclere/patch.180618.txt
> (assuming this is
> http://people.apache.org/~jfclere/patches/patch.180618.txt, above is
> 404).
> 
> In 1.6.x, the mutex is locked unconditionally, I don't think we can
> unlock it when ->buffered only.
> Don't you want the whole http://svn.apache.org/r1808457 instead?

That is why I wrote in STATUS, wasn't sure what is best and my changes
are minimal.
If you think the whole http://svn.apache.org/r1808457 is better I will
go for it.

Cheers

Jean-Frederic

> 
> Regards,
> Yann.
> 

Re: APR Util: Migrating Win64 build from 1.5.x to 1.6.x; testcrypto fails, looking for NSS

[jean-frederic clere]

On 10/18/2017 10:39 PM, Michal Karm wrote:

Hi guys,

I've switched my Windows CI from APR Util 1.5.x
to the 1.6.x branch. Little did I know it would
demand NSS even though I built with OpenSSL.

This is the pertinent excerpt from the log [1],
the full build log (large text) can be found here [2]
and last but not least, this is the build script [3],
note that I tried to set -DAPU_HAVE_NSS=OFF out of good
sport, but it was in vain.

Could you tell me what might be improved in the
CMakeLists.txt so as the test run doesn't look for NSS?


If you look to test/testcrypto.c  it seems it require nss and openssl, I 
think it should be possible to test for nss and skip the corresponding 
tests... Patches are welcome


Cheers

Jean-Frederic



Is there anything else fishy about it? Perhaps the root
cause is entirely different.

Thank you for any pointers


Cheers

Karm

[1] https://www.hastebin.com/umitizokor.lua
[2] https://ci.modcluster.io/job/apr-util-windows/15/label=w2k12r2/consoleText
[3]
https://github.com/modcluster/ci.modcluster.io/blob/6a01bf9f015224271078336eebab4e258b8f9196/windows/apr-util/build.bat#L28

Michal Karm Babacek

apr_sockaddr_info_get() with %n behave different on Solaris and Linux.

[jean-frederic clere]

Hi,

I have different behaviours on solaris and linux:
solaris doesn't seem to support the %2:

code (2001:db8:0:f101::1 or 2620:52:0:105f:0:0::51):
+++
rv = apr_sockaddr_info_get(sa, 2001:db8:0:f101::1%2, APR_UNSPEC, 
80, 0, p);

printf(2001:db8:0:f101::1%%2 %d\n, rv);
rv = apr_sockaddr_info_get(sa, 2001:db8:0:f101::1, APR_UNSPEC, 
80, 0, p);

printf(2001:db8:0:f101::1 %d\n, rv);
+++

Solaris:
+++
[hudson@dev20-03 jfclere]$ java Address
 fe80:52:0:105f:0:0::50%2
 2620:52:0:105f:0:0::51%2
 2620:52:0:105f:0:0::50%2
 10.16.92.170
 10.16.92.169
 10.16.92.168
 10.16.92.167
 10.16.89.252
 0:0:0:0:0:0:0:1%1
 127.0.0.1
[hudson@dev20-03 jfclere]$ ./testsockIPv6
2620:52:0:105f:0:0::51%2 670008
2620:52:0:105f:0:0::51 0
+++

Linux:
+++
[jfclere@jfcpc X509]$ java Address
 10.36.6.146
 fe80:0:0:0:f2de:f1ff:fe5a:1fb3%2
 2001:db8:0:f101:0:0:0:1%2
 192.168.1.35
 0:0:0:0:0:0:0:1%1
 127.0.0.1
[jfclere@jfcpc X509]$ ./testsockIPv6
2001:db8:0:f101::1%2 0
2001:db8:0:f101::1 0
+++

The apr_sockaddr_info_get() gives an error in Solaris and works in 
Linux, comments?


Cheers

Jean-Frederic

Re: svn commit: r921306 - /apr/apr/branches/1.5.x/file_io/win32/open.c

[jean-frederic clere]

On 03/12/2010 11:48 AM, Bert Huijben wrote:
 Why do we even have this block?
 
 CreateHardLinkA is only implemented in Windows 2000 and later, which implies 
 unicode support. 
 (Why support an ansi version of an API that is only implemented on unicode 
 capable systems?)
 
   Bert
 
 

See http://msdn.microsoft.com/en-us/library/aa363860%28VS.85%29.aspx

Cheers

Jean-Frederic

Re: Community question; always load expat for any apr application?

[jean-frederic clere]

On 01/20/2010 08:28 AM, William A. Rowe Jr. wrote:
 We have really trimmed down the footprint of apr as a loadable library,
 so the very last not-dynamic component is expat.
 
 It's small and lightweight, and I just wanted to confirm that the devs
 are all comfortable that xml is pervasive enough to merit binding expat
 with libdl every time a user launches an apr-based application.
 
 I'm about to revisit adding ICU support in place of our apriconv, and that
 would certainly be abstracted.  Expat certainly could be abstracted, but
 I'm not sure if we see there is a value in doing so?

expat and iconv would be optional, no?

Cheers

Jean-Frederic

web pages and current versions

[jean-frederic clere]

Hi,

The download page offers apr:: 1.3.8, apu:1.3.9 and api:1.2.1 the 
announce page says apr: 1.3.9.


I know that 1.3.9 causes regression in Solaris could that explains the 
1.3.8 in the download page?


What about the 1.3.10?

Should I fix the download page?

Cheers

Jean-Frederic

AC_LIBTOOL_WIN32_DLL in apr-util-1.3.x/xml/expat/configure.in

[jean-frederic clere]

Hi,

When using libtool 2.2.6 I have noted that AC_LIBTOOL_WIN32_DLL isn't 
defined this version.

How should we fix that? Why do we need AC_LIBTOOL_WIN32_DLL BTW?

Cheers

Jean-Frederic

build broken

[jean-frederic clere]

Hi,

It seems there is something somewhere:
+++
	/usr/bin/posix/sh /home/jfclere/TMP/dev25/APR/build-1/libtool --silent 
--mode=compile cc -g -Ae +Z -mt   -DHAVE_CONFIG_H -DHPUX11 -D_REENTRANT 
-D_HPUX_SOURCE -D_LARGEFILE64_SOURCE 
-I/home/jfclere/TMP/dev25/apr-util-trunk/include 
-I/home/jfclere/TMP/dev25/apr-util-trunk/include/private 
-I/home/jfclere/TMP/dev25/APR/include/apr-1 
-I/home/jfclere/TMP/dev25/apr-util-trunk/xml/expat/lib  -o 
misc/apr_reslist.lo -c misc/apr_reslist.c  touch misc/apr_reslist.lo
misc/apr_reslist.c, line 288: error #2140: too many arguments in 
function call

apr_pool_cleanup_null);
^

1 error detected in the compilation of misc/apr_reslist.c.
*** Error exit code 1
+++
I will have a look later, any hints in the meantime?

Cheers

Jean-Frederic

Re: build broken

[jean-frederic clere]

Bojan Smojver wrote:

Quoting jean-frederic clere [EMAIL PROTECTED]:


I will have a look later, any hints in the meantime?


That was fixed in r677523.


Ok thanks ;-)

Cheers

Jean-Frederic

Re: svn commit: r663499 - /apr/apr-util/trunk/build/dso.m4

[jean-frederic clere]

[EMAIL PROTECTED] wrote:

Author: jfclere
Date: Thu Jun  5 01:37:38 2008
New Revision: 663499

URL: http://svn.apache.org/viewvc?rev=663499view=rev
Log:
Otherwise install-modules-yes in Makefile and the shell will complains on
syntax error because APU_MODULES is only a space (on Solaris for example).

Modified:
apr/apr-util/trunk/build/dso.m4

Modified: apr/apr-util/trunk/build/dso.m4
URL: 
http://svn.apache.org/viewvc/apr/apr-util/trunk/build/dso.m4?rev=663499r1=663498r2=663499view=diff
==
--- apr/apr-util/trunk/build/dso.m4 (original)
+++ apr/apr-util/trunk/build/dso.m4 Thu Jun  5 01:37:38 2008
@@ -69,6 +69,8 @@
  test $apu_have_freetds = 1  dsos=$dsos dbd/apr_dbd_freetds.la
  test $apu_has_ldap = 1  dsos=$dsos ldap/apr_ldap.la
 
- APU_MODULES=$APU_MODULES $dsos

+ if test -n $dsos; then
+APU_MODULES=$APU_MODULES $dsos
+ fi
   fi
 ])





It seems 1.3.0 is buggy and doesn't build on my test machine for the 
same reasons ;-(


Cheers

Jean-Frederic

Re: svn commit: r601938 - in /apr/apr-util/trunk: CHANGES include/apr_ldap.h.in include/apr_ldap_rebind.h ldap/NWGNUmakefile ldap/apr_ldap_rebind.c

[jean-frederic clere]

Hi,

That breaks my builds:
+++
/bin/bash /home/jfclere/TMP/dev12.qa.atl2.redhat.com/APR/build-1/libtool
--silent --mode=compile gcc -g -O2 -pthreads   -DHAVE_CONFIG_H
-DSOLARIS2=9 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT
-D_LARGEFILE64_SOURCE
-I/qa/home/jfclere/TMP/dev12.qa.atl2.redhat.com/apr-util-trunk/include
-I/qa/home/jfclere/TMP/dev12.qa.atl2.redhat.com/apr-util-trunk/include/private
 -I/home/jfclere/TMP/dev12.qa.atl2.redhat.com/APR/include/apr-1-o
ldap/apr_ldap_rebind.lo -c ldap/apr_ldap_rebind.c  touch
ldap/apr_ldap_rebind.lo
In file included from ldap/apr_ldap_rebind.c:29:
/qa/home/jfclere/TMP/dev12.qa.atl2.redhat.com/apr-util-trunk/include/apr_ldap_rebind.h:62:
error: parse error before LDAP
/qa/home/jfclere/TMP/dev12.qa.atl2.redhat.com/apr-util-trunk/include/apr_ldap_rebind.h:77:
error: parse error before '*' token
ldap/apr_ldap_rebind.c:40: error: parse error before LDAP
ldap/apr_ldap_rebind.c:40: warning: no semicolon at end of struct or union
ldap/apr_ldap_rebind.c:44: error: parse error before '}' token
ldap/apr_ldap_rebind.c:49: error: parse error before '*' token
ldap/apr_ldap_rebind.c:68: error: parse error before LDAP
ldap/apr_ldap_rebind.c: In function `apr_ldap_rebind_add':
ldap/apr_ldap_rebind.c:73: error: `pool' undeclared (first use in this
function)
ldap/apr_ldap_rebind.c:73: error: (Each undeclared identifier is
reported only once
ldap/apr_ldap_rebind.c:73: error: for each function it appears in.)
ldap/apr_ldap_rebind.c:73: error: invalid application of `sizeof' to an
incomplete type
ldap/apr_ldap_rebind.c:73: error: invalid application of `sizeof' to an
incomplete type
ldap/apr_ldap_rebind.c:75: error: dereferencing pointer to incomplete type
ldap/apr_ldap_rebind.c:76: error: dereferencing pointer to incomplete type
ldap/apr_ldap_rebind.c:76: error: `ld' undeclared (first use in this
function)
ldap/apr_ldap_rebind.c:78: error: dereferencing pointer to incomplete type
ldap/apr_ldap_rebind.c:81: error: dereferencing pointer to incomplete type
ldap/apr_ldap_rebind.c:88: error: dereferencing pointer to incomplete type
ldap/apr_ldap_rebind.c: At top level:
ldap/apr_ldap_rebind.c:113: error: parse error before '*' token
ldap/apr_ldap_rebind.c: In function `apr_ldap_rebind_remove':
ldap/apr_ldap_rebind.c:122: error: dereferencing pointer to incomplete type
ldap/apr_ldap_rebind.c:122: error: `ld' undeclared (first use in this
function)
ldap/apr_ldap_rebind.c:124: error: dereferencing pointer to incomplete type
ldap/apr_ldap_rebind.c:129: error: dereferencing pointer to incomplete type
ldap/apr_ldap_rebind.c:132: error: dereferencing pointer to incomplete type
ldap/apr_ldap_rebind.c:132: error: dereferencing pointer to incomplete type
ldap/apr_ldap_rebind.c:138: error: dereferencing pointer to incomplete type
ldap/apr_ldap_rebind.c:138: error: dereferencing pointer to incomplete type
ldap/apr_ldap_rebind.c: In function `apr_ldap_rebind_remove_helper':
ldap/apr_ldap_rebind.c:150: error: `LDAP' undeclared (first use in this
function)
ldap/apr_ldap_rebind.c:150: error: `ld' undeclared (first use in this
function)
ldap/apr_ldap_rebind.c:150: error: parse error before ')' token
ldap/apr_ldap_rebind.c: At top level:
ldap/apr_ldap_rebind.c:156: error: parse error before '*' token
ldap/apr_ldap_rebind.c: In function `apr_ldap_rebind_lookup':
ldap/apr_ldap_rebind.c:166: error: dereferencing pointer to incomplete type
ldap/apr_ldap_rebind.c:166: error: `ld' undeclared (first use in this
function)
ldap/apr_ldap_rebind.c:171: error: dereferencing pointer to incomplete type
ldap/apr_ldap_rebind.c: At top level:
ldap/apr_ldap_rebind.c:260: error: parse error before '*' token
+++

Cheers

Jean-Frederic

Re: svn commit: r601938 - in /apr/apr-util/trunk: CHANGES include/apr_ldap.h.in include/apr_ldap_rebind.h ldap/NWGNUmakefile ldap/apr_ldap_rebind.c

[jean-frederic clere]

Graham Leggett wrote:
 jean-frederic clere wrote:
 
 /qa/home/jfclere/TMP/dev12.qa.atl2.redhat.com/apr-util-trunk/include/apr_ldap_rebind.h:62:

 error: parse error before LDAP
 
 Looks like this header file doesn't take into account when the LDAP
 stuff is turned off - it's been fixed, can you try again and confirm the
 problem has gone away?

Yep it is fixed now.

Cheers

Jean-Frederic

 
 Regards,
 Graham
 -- 

Re: svn commit: r589846 - /apr/apr/trunk/file_io/unix/fullrw.c

[jean-frederic clere]

[EMAIL PROTECTED] wrote:
 Author: trawick
 Date: Mon Oct 29 13:36:08 2007
 New Revision: 589846
 
 URL: http://svn.apache.org/viewvc?rev=589846view=rev
 Log:
 AIX C compiler won't add to void * in picky mode

It seems I also had problems on HP-UX:
+++
if (amt) {
 .mine
/* rv = apr_file_write_full(thefile, vec[i].iov_base + amt, */
void *ptr = vec[i].iov_base;
ptr = ptr + amt;
rv = apr_file_write_full(thefile, ptr,
===
rv = apr_file_write_full(thefile, (const char *)vec[i].iov_base
+ amt,
 .r589986
 vec[i].iov_len - amt, NULL);
}
+++

 
 Modified:
 apr/apr/trunk/file_io/unix/fullrw.c
 
 Modified: apr/apr/trunk/file_io/unix/fullrw.c
 URL: 
 http://svn.apache.org/viewvc/apr/apr/trunk/file_io/unix/fullrw.c?rev=589846r1=589845r2=589846view=diff
 ==
 --- apr/apr/trunk/file_io/unix/fullrw.c (original)
 +++ apr/apr/trunk/file_io/unix/fullrw.c Mon Oct 29 13:36:08 2007
 @@ -95,7 +95,7 @@
  }
  
  if (amt) {
 -rv = apr_file_write_full(thefile, vec[i].iov_base + amt,
 +rv = apr_file_write_full(thefile, (const char *)vec[i].iov_base + 
 amt,
   vec[i].iov_len - amt, NULL);
  }
  
 
 
 

Re: svn commit: r589846 - /apr/apr/trunk/file_io/unix/fullrw.c

[jean-frederic clere]

Jeff Trawick wrote:
 On 10/30/07, jean-frederic clere [EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED] wrote:
 Author: trawick
 Date: Mon Oct 29 13:36:08 2007
 New Revision: 589846

 URL: http://svn.apache.org/viewvc?rev=589846view=rev
 Log:
 AIX C compiler won't add to void * in picky mode
 It seems I also had problems on HP-UX:
 
 I wondered about that one...  In the old days I had build/test
 regression set up on a bunch of boxes...  AIX, HP-UX, and Tru64 with
 the native compilers would generally barf in lock step.
 

Without you correction it says:
+++
$ make
/usr/bin/posix/sh /qa/home/jfclere/TMP/dev25/apr-trunk/libtool
--silent --mode=compile cc -g -Ae +Z -mt   -DHAVE_CONFIG_H -DHPUX11
-D_REENTRANT -D_HPUX_SOURCE -D_LARGEFILE64_SOURCE   -I./include
-I/qa/home/jfclere/TMP/dev25/apr-trunk/include/arch/unix
-I./include/arch/unix -I/qa/home/jfclere/TMP/dev25/apr-trunk/include  -o
file_io/unix/fullrw.lo -c file_io/unix/fullrw.c  touch
file_io/unix/fullrw.lo
file_io/unix/fullrw.c, line 98: error #2852: expression must be a
pointer to
  a complete object type
  rv = apr_file_write_full(thefile, vec[i].iov_base + amt,
^

1 error detected in the compilation of file_io/unix/fullrw.c.
*** Error exit code 1

Stop.
*** Error exit code 1

Cheers

Jean-Frederic
Stop.
+++

Re: svn commit: r589846 - /apr/apr/trunk/file_io/unix/fullrw.c

[jean-frederic clere]

Lucian Adrian Grijincu wrote:
 On 10/30/07, jean-frederic clere [EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED] wrote:
 Author: trawick
 Date: Mon Oct 29 13:36:08 2007
 New Revision: 589846

 URL: http://svn.apache.org/viewvc?rev=589846view=rev
 Log:
 AIX C compiler won't add to void * in picky mode
 It seems I also had problems on HP-UX:
 +++
 if (amt) {
  .mine
 /* rv = apr_file_write_full(thefile, vec[i].iov_base + amt, */
 void *ptr = vec[i].iov_base;
 ptr = ptr + amt;
 rv = apr_file_write_full(thefile, ptr,
 ===
 
 
 does the C standard allow void* arithmetics?
 
 won't this compile for you:
  const char *ptr = (const char*) vec[i].iov_base;
  ptr = ptr + amt;
  rv = apr_file_write_full(thefile, ptr,
 
 ?

Yep, this one compiles the void * version doesn't.

Cheers

Jean-Frederic

 
 rv = apr_file_write_full(thefile, (const char *)vec[i].iov_base
 + amt,
 .r589986
  vec[i].iov_len - amt, NULL);
 }
 +++

 Modified:
 apr/apr/trunk/file_io/unix/fullrw.c

 Modified: apr/apr/trunk/file_io/unix/fullrw.c
 URL: 
 http://svn.apache.org/viewvc/apr/apr/trunk/file_io/unix/fullrw.c?rev=589846r1=589845r2=589846view=diff
 ==
 --- apr/apr/trunk/file_io/unix/fullrw.c (original)
 +++ apr/apr/trunk/file_io/unix/fullrw.c Mon Oct 29 13:36:08 2007
 @@ -95,7 +95,7 @@
  }

  if (amt) {
 -rv = apr_file_write_full(thefile, vec[i].iov_base + amt,
 +rv = apr_file_write_full(thefile, (const char *)vec[i].iov_base + 
 amt,
   vec[i].iov_len - amt, NULL);
  }





 
 

Re: svn commit: r588062 - /apr/apr-util/trunk/buckets/apr_brigade.c

[jean-frederic clere]

[EMAIL PROTECTED] wrote:
 Author: wrowe
 Date: Wed Oct 24 15:29:11 2007
 New Revision: 588062
 
 URL: http://svn.apache.org/viewvc?rev=588062view=rev
 Log:
 Adopt 1.3.0 trunk's new constant.
 
 Modified:
 apr/apr-util/trunk/buckets/apr_brigade.c
 
 Modified: apr/apr-util/trunk/buckets/apr_brigade.c
 URL: 
 http://svn.apache.org/viewvc/apr/apr-util/trunk/buckets/apr_brigade.c?rev=588062r1=588061r2=588062view=diff
 ==
 --- apr/apr-util/trunk/buckets/apr_brigade.c (original)
 +++ apr/apr-util/trunk/buckets/apr_brigade.c Wed Oct 24 15:29:11 2007
 @@ -29,12 +29,6 @@
  #include sys/uio.h
  #endif
  
 -/* TODO: ~((apr_size_t)0) appears to be the best way to quickly 
 - * represent  MAX_APR_SIZE_T for any CPU we support.  Move this
 - * out as APR_MAX_SIZE_T to our public headers...
 - */
 -#define MAX_APR_SIZE_T (~((apr_size_t)0))
 -
  static apr_status_t brigade_cleanup(void *data) 
  {
  return apr_brigade_cleanup(data);
 @@ -123,7 +117,7 @@
  /* For an unknown length bucket, while 'point' is beyond the possible
   * size contained in apr_size_t, read and continue...
   */
 -if ((e-length == (apr_size_t)(-1))  (point  MAX_APR_SIZE_T)) {
 +if ((e-length == (apr_size_t)(-1))  (point  APR_SIZE_MAX)) {
  /* point is too far out to simply split this bucket,
   * we must fix this bucket's size and keep going... */
  rv = apr_bucket_read(e, s, len, APR_BLOCK_READ);
 
 
 

That gives:
+++
make[1]: Entering directory `/home/jfclere/apr-util'
/bin/sh /home/jfclere/APR/build-1/libtool --silent --mode=compile gcc -g
-O2 -pthread   -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE
-D_LARGEFILE64_SOURCE   -I/home/jfclere/apr-util/include
-I/home/jfclere/apr-util/include/private
-I/home/jfclere/APR/include/apr-1  -I/usr/include/mysql  -o
buckets/apr_brigade.lo -c buckets/apr_brigade.c  touch
buckets/apr_brigade.lo
buckets/apr_brigade.c: In function 'apr_brigade_partition':
buckets/apr_brigade.c:120: error: 'APR_SIZE_MAX' undeclared (first use
in this function)
buckets/apr_brigade.c:120: error: (Each undeclared identifier is
reported only once
buckets/apr_brigade.c:120: error: for each function it appears in.)
make[1]: *** [buckets/apr_brigade.lo] Error 1
make[1]: Leaving directory `/home/jfclere/apr-util'
make: *** [all-recursive] Error 1
+++

Cheers

Jean-Frederic

Re: svn commit: r588062 - /apr/apr-util/trunk/buckets/apr_brigade.c

[jean-frederic clere]

Oops sorry... Forget my previous comment... My apr.h wasn't updated.

Cheers

Jean-Frederic

Re: svn commit: r577654 - /apr/apr-util/trunk/build/dbd.m4

[jean-frederic clere]

Bojan Smojver wrote:
 On Thu, 2007-09-20 at 09:39 +, [EMAIL PROTECTED] wrote:
 Author: jfclere
 Date: Thu Sep 20 02:39:27 2007
 New Revision: 577654

 URL: http://svn.apache.org/viewvc?rev=577654view=rev
 Log:
 Use the mysql libtool library when available.
 (Otherwise it breaks on one of the HP-UX where I am testing).
 
 The second hunk (@@ -158,6 +164,12 @@) doesn't seem correct. The value
 of $withval at that point is yes, so the code is looking for the
 presence of yes/lib/mysql/libmysqlclient_r.la or
 yes/lib/libmysqlclient_r.la.
 

Oops. I will have a look and fix or just remove it until I find a better
way to handle it.

Cheers

Jean-Frederic

Re: [VOTE] Release apr 0.9.16 / 1.2.11 --- apr-util 0.9.15 / 1.2.10

[jean-frederic clere]

William A. Rowe, Jr. wrote:
 Please review and vote on those you have time to - reply once or four times,
 just review those you can as you can; http://apr.apache.org/dev/dist/
 
 [If you want to speed up the effort by comparing the packages, you can still
 obtain the withdrawn packages at http://apr.apache.org/dev/dist/abandoned/
 until the end of voting.]
 
   +1/-1   Release
[  ]   apr-1.2.11

I have:
testsockets : FAILED 1 of 6 on a Solaris9 SPARC Box with
SunStudio compiler.

[  ]   apr-util-1.2.10
[  ]   apr-0.9.16
[  ]   apr-util-0.9.15
 
 Win .zip's will follow when I have a few minutes on a win box to extract
 the .mak files, likely early Tuesday.
 
 Bill
 
 

Re: [VOTE] Release apr 0.9.16 / 1.2.11 --- apr-util 0.9.15 / 1.2.10

[jean-frederic clere]

Ruediger Pluem wrote:
 
 On 09/04/2007 03:38 PM, jean-frederic clere wrote:
 William A. Rowe, Jr. wrote:
 Please review and vote on those you have time to - reply once or four times,
 just review those you can as you can; http://apr.apache.org/dev/dist/

 [If you want to speed up the effort by comparing the packages, you can still
 obtain the withdrawn packages at http://apr.apache.org/dev/dist/abandoned/
 until the end of voting.]

   +1/-1   Release
[  ]   apr-1.2.11
 I have:
 testsockets : FAILED 1 of 6 on a Solaris9 SPARC Box with
 SunStudio compiler.
 
 Which test failed? I stumbled across an issue on Solaris that the bind test 
 fails
 because APR_HAVE_IPV6 was set, but ::1 was not bound on the loopback interface
 (only 127.0.0.1) on my box. A truss can help to find out.

bind(3, 0x000C3540, 32, 3)  Err#126 EADDRNOTAVAIL
and
#define APR_HAVE_IPV6   1
and
/sbin/ifconfig doesn't show any IPV6 stuff.

Yes that is the probleme.

So:
 [-1] apr-1.2.11 Tested on Solaris9 SPARC.

Cheers

Jean-Frederic



 
 Regards
 
 Rüdiger
 
 

Re: [VOTE] Release apr 0.9.16 / 1.2.11 --- apr-util 0.9.15 / 1.2.10

[jean-frederic clere]

William A. Rowe, Jr. wrote:
 jean-frederic clere wrote:
 William A. Rowe, Jr. wrote:
 Please review and vote on those you have time to - reply once or four times,
 just review those you can as you can; http://apr.apache.org/dev/dist/
 I have:
 testsockets : FAILED 1 of 6 on a Solaris9 SPARC Box with
 SunStudio compiler.
 
 ./testall -v is our friend...

Yes I plan to add some apr_snprintf(). For example a %pI so that is
clear that bind to [::1]:7772 will fail if IPV6 is no usable on the box.

 
 this is pollset 'expected 5 saw 4' bug?

No just a bind() failed.

Cheers

Jean-Frederic

  It refers to the number of poll
 fd's and the test has a bogus assumption that you can add a socket 2x.  On
 Win, Solaris and perhaps others, there's one pollset entry per socket.
 
 Bill
 

Re: [VOTE] Release apr 0.9.16 / 1.2.11 --- apr-util 0.9.15 / 1.2.10

[jean-frederic clere]

William A. Rowe, Jr. wrote:
 jean-frederic clere wrote:
 Ruediger Pluem wrote:
 Which test failed? I stumbled across an issue on Solaris that the bind test 
 fails
 because APR_HAVE_IPV6 was set, but ::1 was not bound on the loopback 
 interface
 (only 127.0.0.1) on my box. A truss can help to find out.
 bind(3, 0x000C3540, 32, 3)  Err#126 EADDRNOTAVAIL
 and
 #define APR_HAVE_IPV6   1
 and
 /sbin/ifconfig doesn't show any IPV6 stuff.

 Yes that is the probleme.

 So:
  [-1] apr-1.2.11 Tested on Solaris9 SPARC.
 
 Just an FYI; that would be a flaw in your configuration/your operating
 system.  Your machine advertised IPV6 (installed) and failed to bind
 to ::1, so i'd consider the test is working as-designed...
 
 ...and pointing out your bug ;-)

Sure:
[+1] apr-1.2.11 Tested on Solaris9 SPARC.

Cheers

Jean-Frederic

 
 Bill
 

Re: Roll 0.9.15 this week?

[jean-frederic clere]

William A. Rowe, Jr. wrote:
 jean-frederic clere wrote:
 Ruediger Pluem wrote:
 On 08/13/2007 09:34 PM, William A. Rowe, Jr. wrote:
 It's a nice idea in 1.3, but since it's causing issues, simply revert.
 Done in r565517.
 Wasn't the (*new)-remote_addr_unknown = 0; causing the problem?
 
 Are you thinking of the unix issue or windows issue?
 
 The windows issue is that we defined that remote address was flagged known
 before - and became known, because httpd filled it in on AcceptEx from
 the data.  Windows 2000 could *only* recall the remote IP from the AcceptEx
 command, and the classic socket commands returned 0.0.0.0.  This had been
 already fixed in the last apr release, and filling in the remote IP from
 httpd now causes the 'unknown' to be toggled false.

Thank that explains the used of remote_addr_unknown. So
(*new)-remote_addr_unknown = 0 wasn't the problem.

 
 Rüdiger observed (with respect to a platform he didn't identify);
 -
 These regression are caused by an apr problem. 2.0.59 is shipped with
 apr 0.9.12 whereas 2.0.60 is shipped with apr 0.9.14.
 
 The regressions are caused by r442526 and r443264 which are backports
 of r442135 and r443262 from apr trunk.
 These revisions change apr_socket_accept in network_io/unix/sockets.c.
 Why does this not happen with apr trunk / 1.2.x?
 
 On apr trunk we have r447894. Backporting this patch to 0.9.14 fixes
 the regressions.

Yes I have tested that too.

  On apr 1.2.x the backports of r442135 and r443262
 have been reverted in r473681.

With r565517 we have the same logic in 0.9.x

 
 So I guess we either have to ship 2.0.x with an older release of apr 0.9.x
 or we have to wait for a new release of apr 0.9.x that fixes this problem.
 --
 
 So although rpluem has gone ahead and verified that reverting this solves
 the issue; you should feel welcome to craft a complete backport that does
 NOT introduce the bug discovered in httpd.  Although I felt changing the
 contract was unnecessary, I don't object if it solves other problems or
 makes the previous API contracts more conformant.
 
 I'm rolling today, although not quite first thing as I had planned.

Great.

Cheers

Jean-Frederic

  I've
 spent my time since vacation fighting with Win32-foo, and want to make sure
 the release is solid on Win32 as well as unix.
 
 If anyone is working on any last minute spit-n-polish (no major changes
 please!!!) then ping on irc as well as the list, so I don't 'roll over' you.
 
 Bill
 

Re: Roll 0.9.15 this week?

[jean-frederic clere]

Ruediger Pluem wrote:
 
 On 08/13/2007 09:34 PM, William A. Rowe, Jr. wrote:
 Jim Jagielski wrote:
 On Aug 13, 2007, at 3:06 PM, Ruediger Pluem wrote:
 On 08/13/2007 07:38 AM, William A. Rowe, Jr. wrote:
 Jim's spearheaded an effort to release httpd-2.0.60 and we've
 discovered a set of socket issues that need to be corrected by
 apr-0.9.15.
 How do we plan to address these? Like in 1.2.x by reverting the
 backports (which seems to make sense to me given the comments
 in r473681, http://svn.apache.org/viewvc?view=revrevision=473681)?
 Or should we backport r447894?
 I am happy to proceed either way with a preference of reverting.
 That would be my pref as well...
 +1.  I raised an objection when this first went in that changing the
 contract was iffy.  Our entire versioning rules were based on the
 fact that once you have a specific major, minimum .minor - that's it.
 Your app is safe.

 It's a nice idea in 1.3, but since it's causing issues, simply revert.
 
 Done in r565517.

Wasn't the (*new)-remote_addr_unknown = 0; causing the problem?

Cheers

Jean-Frederic

 
 Regards
 
 Rüdiger
 
 

atomics on PPC Linux.

[jean-frederic clere]

Hi,

I have tried to compile on PPC Linux and I have the following error:
+++
/bin/sh /home/jclere/apr-trunk/libtool --silent --mode=compile gcc -g 
-O2 -pthread   -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE 
-D_LARGEFILE64_SOURCE
  -I./include -I/home/jclere/apr-trunk/include/arch/unix 
-I./include/arch/unix -
I/home/jclere/apr-trunk/include  -o atomic/unix/ppc.lo -c 
atomic/unix/ppc.c  t

ouch atomic/unix/ppc.lo
atomic/unix/ppc.c: In function `apr_atomic_xchgptr':
atomic/unix/ppc.c:189: error: `PPC_SYNC' undeclared (first use in this 
function)
atomic/unix/ppc.c:189: error: (Each undeclared identifier is reported 
only once

atomic/unix/ppc.c:189: error: for each function it appears in.)
atomic/unix/ppc.c:189: error: syntax error before string constant
make[1]: *** [atomic/unix/ppc.lo] Error 1
+++

Any hints? Is someone working on it?

Cheers

Jean-Frederic

print pid from apr_proc_t

[Jean-frederic Clere]

Hi,

It seems there is not anyway to print the pid from an apr_proc_t, isn't
it?

Does such a thing make sense to add to apr? (There is a %pT for
apr_os_thread_t).

Cheers

Jean-Frederic

./configure prefix option doesn't work.

[Jean-frederic Clere]

Hi,

When I do:
./configure --prefix=$HOME/APR
prefix is still set to /usr/local/apr by config.layout, is it a feature?

Cheers

Jean-Frederic

Re: decision on anonymous shared memory allocation method failed

[Jean-frederic Clere]

Schmoll, Brett x66244 wrote:


Hi all,

Trying to see if I can get svn to build on our HP NonStop platform and 
am having some difficulties getting APR portion to build.


Checking for Shared Memory Support...
checking for library containing shm_open... no
checking sys/mman.h usability... no
checking sys/mman.h presence... no
checking for sys/mman.h... no
checking sys/ipc.h usability... yes
checking sys/ipc.h presence... yes
checking for sys/ipc.h... yes
checking sys/mutex.h usability... no
checking sys/mutex.h presence... no
checking for sys/mutex.h... no
checking sys/shm.h usability... yes
checking sys/shm.h presence... yes
checking for sys/shm.h... yes
checking sys/file.h usability... no
checking sys/file.h presence... no
checking for sys/file.h... no
checking kernel/OS.h usability... no
checking kernel/OS.h presence... no
checking for kernel/OS.h... no
checking os2.h usability... no
checking os2.h presence... no
checking for os2.h... no
checking for mmap... no
checking for munmap... no
checking for shm_open... no
checking for shm_unlink... no
checking for shmget... yes
checking for shmat... yes
checking for shmdt... yes
checking for shmctl... yes
checking for create_area... no
checking for MAP_ANON in sys/mman.h... no
checking for /dev/zero... no
./configure:Error: decision on anonymous shared memory allocation 
method failed


Given the yes's on shmget etc I would have thought that it wouldv'e 
worked. Is their anyway to work-around this and/or fix it?



You should have a config.log somewhere please send it.

Cheers

Jean-frederic


-Brett Schmoll



This message and any attachments are intended only for the use of the 
addressee and may contain information that is privileged and 
confidential. If the reader of the message is not the intended 
recipient or an authorized representative of the intended recipient, 
you are hereby notified that any dissemination of this communication 
is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail and delete the message 
and any attachments from your system.

apr-iconv (error: invalid lvalue in increment)

[Jean-frederic Clere]

Hi,

I am trying to compile trunk and I have a problem in apr-iconv the 
corrections are like the patch below.

The memcpy is a bit paranoid, any comments?

Cheers

Jean-frederic

+++
[EMAIL PROTECTED]:~/apr-iconv$ svn diff .
Index: ces/ucs2-internal.c
===
--- ces/ucs2-internal.c (revision 390028)
+++ ces/ucs2-internal.c (working copy)
@@ -59,7 +59,9 @@
   return -1;  /* No corresponding character in UCS-2 */
   if (*outbytesleft  sizeof(ucs2_t))
   return 0;   /* No space in the output buffer */
-   *((ucs2_t *)(*outbuf))++ = in;
+   /* memcpy prevents addressing problems */
+   *outbuf += sizeof(ucs2_t);
+   memcpy(*outbuf, in, sizeof(ucs2_t));
   (*outbytesleft) -= sizeof(ucs2_t);
   return 1;
}
@@ -68,10 +70,14 @@
convert_to_ucs(struct iconv_ces *ces,
   const unsigned char **inbuf, apr_size_t *inbytesleft)
{
+   ucs2_t ret;
   if (*inbytesleft  sizeof(ucs2_t))
   return UCS_CHAR_NONE;   /* Not enough bytes in the input 
buffer */

   (*inbytesleft) -= sizeof(ucs2_t);
-   return *((const ucs2_t *)(*inbuf))++;
+   /* memcpy prevents addressing problems */
+   *inbuf += sizeof(ucs2_t);
+   memcpy(ret, *inbuf, sizeof(ucs2_t));
+   return ret;
}

static const struct iconv_ces_desc iconv_ces_desc = {
+++

Re: svn commit: r387938 - /apr/apr-util/branches/0.9.x/buildconf

[Jean-frederic Clere]

William A. Rowe, Jr. wrote:


Joe Orton wrote:


On Wed, Mar 22, 2006 at 08:50:48PM -, William Rowe wrote:


-
-# Remove autoconf cache
-rm -rf autom4te*.cache



That line was suppoesd to be there - the tarball you rolled now 
includes an unnecessary autom4te.cache directory.



Outch you are right... I see we pre-and-post remove the thing.  
Recommitting,
and if I don't see any other feedback before the 24 hour mark I'll re 
TR...

Version numbers are cheap.

The question is, do we *also* need to _pre_remove autom4te*.cache in 
the expat

tree?


Well, if someone runs buildconf and have a different version of 
automake/autoconf/m4 the created configure will not work (I remember 
spending a lot of time after scp -rp apr-util ... and rm -rf 
autom4te*.cache fixed the problem).




Bill

Re: apr error.

[Jean-frederic Clere]

Garrett Rooney wrote:


On 3/21/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 


Error:

checking for APR... no
configure: error: APR could not be located. Please use the --with-apr option.

project name:Apache tomcat upgrade

URL :/usr/local/atomcat/apache-tomcat-5.5.16/bin/tomcat-native-1.1.1/jni/native

Please do the needful
   



And what exactly do you expect us to do?
 

This question belongs to the tomcat-user list, please ask it there.  
(and read jni/native/BUILDING).


Cheers

Jean-Frederic


-garrett

 

Re: build.conf and gen-build.py

[jean-frederic clere]

Joe Orton wrote:

On Thu, Jun 30, 2005 at 10:44:39AM +0200, jean-frederic clere wrote:


Hi,

In apr-util I have problems with gen-build.py because build.conf does not 
contain the excepted data.


Where is build.conf created?



It's under version control.  What error do you see?


After svn checkout of apr/apr-util and httpd the error has disappaired, sorry 
for the noice.


Cheers

Jean-Frederic



joe

build.conf and gen-build.py

[jean-frederic clere]

Hi,

In apr-util I have problems with gen-build.py because build.conf does not 
contain the excepted data.


Where is build.conf created?

Cheers

Jean-Frederic

Re: Fwd: svn commit: r190009 - /httpd/httpd/branches/fips-dev/srclib/apr/buildconf

[jean-frederic clere]

William A. Rowe, Jr. wrote:

At 09:24 AM 6/13/2005, jean-frederic clere wrote:


William A. Rowe, Jr. wrote:
+   ltfindcmd=`sed -n \/=[^\\\`]/p;/libtool_m4=/{s/.*=/echo /p;q;}\ \


+$libtoolize`
+   ltfile=${LIBTOOL_M4-`eval $ltfindcmd`}
+   # Expecting the code above to be very portable, but just in case...
+   if [ -e $ltfile -o ! -f $ltfile ]; then


Should be the -e a -f?



if empty string or not a file.  My mistake.  Committed the
appropriate change; please retest?


It is now ok.



Bill  

Re: Fwd: svn commit: r190009 - /httpd/httpd/branches/fips-dev/srclib/apr/buildconf

[jean-frederic clere]

William A. Rowe, Jr. wrote:

Please, take a quick look and consider this patch.

It fixes BSD in particular, where we pick up bin/libtoolize15 but
grab (or entirely fail to grab) share/aclocal/libtool.m4, as it's
installed as share/aclocal/libtool15.m4.

I missed the other side of this patch, which is to prefer the order
of detecting libtool as glibtool glibtool15 glibtool14 libtool,
such that if libtool is a 13 or earlier flavor, we avoid it.



Log:

Examine the selected libtoolize in order to determine it's configured
libtool.m4 path, rather than gross assumptions.  Leaving the gross
assumptions as a fail-over if the structure of libtoolize script is
somehow borked.

Prefer, of course, any libtool that isn't libtool 1.3 or before, so
push 'libtoolize' to the end of the desireables list.

In the sandbox for some testing across platforms - will propose to
[EMAIL PROTECTED] once some measure of portability is confirmed

Modified:
  httpd/httpd/branches/fips-dev/srclib/apr/buildconf

Modified: httpd/httpd/branches/fips-dev/srclib/apr/buildconf
URL: 
http://svn.apache.org/viewcvs/httpd/httpd/branches/fips-dev/srclib/apr/buildconf?rev=190009r1=190008r2=190009view=diff
==
--- httpd/httpd/branches/fips-dev/srclib/apr/buildconf (original)
+++ httpd/httpd/branches/fips-dev/srclib/apr/buildconf Fri Jun 10 12:28:52 2005
@@ -45,8 +45,14 @@
if [ -f libtool.m4 ]; then 
  ltfile=`pwd`/libtool.m4

else
-   ltpath=`dirname $libtoolize`
-   ltfile=${LIBTOOL_M4-`cd $ltpath/../share/aclocal ; pwd`/libtool.m4}
+   ltfindcmd=`sed -n \/=[^\\\`]/p;/libtool_m4=/{s/.*=/echo /p;q;}\ \
+$libtoolize`
+   ltfile=${LIBTOOL_M4-`eval $ltfindcmd`}
+   # Expecting the code above to be very portable, but just in case...
+   if [ -e $ltfile -o ! -f $ltfile ]; then


Should be the -e a -f?

I have on Solaris8:
+++
[EMAIL PROTECTED]:~/apr sh buildconf
buildconf: checking installation...
buildconf: python version 2.3.3 (ok)
buildconf: autoconf version 2.59 (ok)
buildconf: libtool version 1.5.2 (ok)
Copying libtool helper files ...
buildconf: test: unknown operator /opt/SMAWPlus/share/aclocal/libtool.m4
+++


+ ltpath=`dirname $libtoolize`
+ ltfile=`cd $ltpath/../share/aclocal ; pwd`/libtool.m4
+   fi
fi
 
if [ ! -f $ltfile ]; then

Re: oo-dev Inquiry - Interest?

[jean-frederic clere]

William A. Rowe, Jr. wrote:
I'm posting to determine who in the apr project would 
be interested in a defining a common oo approach to apr
and hosting those efforts in this sphere within apr?

E.g.;
  * an [EMAIL PROTECTED] list, discussing and coming
to a common approach for exposing apr as an object
model.
  * a /repos/asf/apr/oo/ tree containing the implementations 
of this consensus, e.g. c++ wrapper, java org.apache.apr, 
perl xs bindings, php, python etc.  Perhaps some specific
threshold, say three individual contributors before a given 
binding is 'supported', would be useful.

This would obviously be with an invitation to our modperl
user community, since they have the most comprehensive wrapper
thus far, invitations to the other interested groups including
authors of several c++ bindings.
It seems to me this is a universal question with many specific
language solutions, that would best be addressed by the apr
community itself.
Comments?  Interest?
+1 for the java part.
Cheers
Jean-Frederic
Bill

Re: svn commit: r124075 - /apr/apr/trunk/threadproc/unix/signals.c

[jean-frederic clere]

Bill Stoddard wrote:
This is well outside my current knowledge, so take this comment for 
what's its worth (probably not much)...

Would it make more sense to properly set SIGPROCMASK_SETS_THREAD_MASK 
depending on whether APR_HAS_THREADS or not?

yes, but where to add:
+++
#if APR_HAS_THREADS
#define SIGPROCMASK_SETS_THREAD_MASK
#endif
+++
Jean-Frederic

Bill
[EMAIL PROTECTED] wrote:
Author: jfclere
Date: Tue Jan  4 00:57:44 2005
New Revision: 124075
URL: http://svn.apache.org/viewcvs?view=revrev=124075
Log:
sigprocmask should be used instead pthread_sigmask on nothreaded 
platforms.

Modified:
   apr/apr/trunk/threadproc/unix/signals.c
Modified: apr/apr/trunk/threadproc/unix/signals.c
Url: 
http://svn.apache.org/viewcvs/apr/apr/trunk/threadproc/unix/signals.c?view=diffrev=124075p1=apr/apr/trunk/threadproc/unix/signals.cr1=124074p2=apr/apr/trunk/threadproc/unix/signals.cr2=124075 

== 

--- apr/apr/trunk/threadproc/unix/signals.c(original)
+++ apr/apr/trunk/threadproc/unix/signals.cTue Jan  4 00:57:44 2005
@@ -409,7 +409,7 @@
 sigfillset(sig_mask);
 remove_sync_sigs(sig_mask);
 
-#if defined(SIGPROCMASK_SETS_THREAD_MASK)
+#if defined(SIGPROCMASK_SETS_THREAD_MASK) || ! APR_HAS_THREADS
 if ((rv = sigprocmask(SIG_SETMASK, sig_mask, NULL)) != 0) {
 rv = errno;
 }
@@ -435,7 +435,7 @@
 
 sigaddset(sig_mask, signum);
 
-#if defined(SIGPROCMASK_SETS_THREAD_MASK)
+#if defined(SIGPROCMASK_SETS_THREAD_MASK) || ! APR_HAS_THREADS
 if ((rv = sigprocmask(SIG_BLOCK, sig_mask, NULL)) != 0) {
 rv = errno;
 }
@@ -462,7 +462,7 @@
 
 sigaddset(sig_mask, signum);
 
-#if defined(SIGPROCMASK_SETS_THREAD_MASK)
+#if defined(SIGPROCMASK_SETS_THREAD_MASK) || ! APR_HAS_THREADS
 if ((rv = sigprocmask(SIG_UNBLOCK, sig_mask, NULL)) != 0) {
 rv = errno;
 }

Re: cvs commit: apr-util/include apu.h.in

[jean-frederic clere]

[EMAIL PROTECTED] wrote:
jfclere 2004/10/07 01:16:45
  Modified:.Makefile.in buildconf configure.in
   buildapu-iconv.m4
   include  apu.h.in
  Log:
  Allow to use apr-iconv.
I tried to get apr-iconv configured from httpd but that wasn't a good idea.
The lastest mail about the topic (in httpd-dev) and before my commit in apr-util 
was the following:
http://marc.theaimsgroup.com/?l=apache-httpd-devm=109719036119165w=2

What is not done is to check that the system iconv() is suitable but apr-iconv 
is be used only if --with-iconv points to apr-iconv sources.

Cheers
Jean-frederic

  
  Revision  ChangesPath
  1.98  +3 -3  apr-util/Makefile.in
  
  Index: Makefile.in
  ===
  RCS file: /home/cvs/apr-util/Makefile.in,v
  retrieving revision 1.97
  retrieving revision 1.98
  diff -u -r1.97 -r1.98
  --- Makefile.in	23 Aug 2004 20:22:18 -	1.97
  +++ Makefile.in	7 Oct 2004 08:16:45 -	1.98
  @@ -15,8 +15,8 @@
   APRUTIL_LIBS = @APRUTIL_LIBS@
   
   TARGET_LIB = [EMAIL PROTECTED]@.la
  -INSTALL_SUBDIRS = @APR_XML_DIR@
  -EXTRA_SOURCE_DIRS = @APR_XML_DIR@
  +INSTALL_SUBDIRS = @APR_ICONV_DIR@ @APR_XML_DIR@
  +EXTRA_SOURCE_DIRS = @APR_ICONV_DIR@ @APR_XML_DIR@
   [EMAIL PROTECTED]@
   APRUTIL_PCFILE = apr-util-$(APRUTIL_MAJOR_VERSION).pc
   APU_CONFIG = apu-$(APRUTIL_MAJOR_VERSION)-config
  @@ -29,7 +29,7 @@
   @INCLUDE_RULES@
   @INCLUDE_OUTPUTS@
   
  -CLEAN_SUBDIRS = test
  +CLEAN_SUBDIRS = test @APR_ICONV_DIR@
   
   CLEAN_TARGETS = exports.c export_vars.c aprutil.exp .make.dirs apu-config.out
   DISTCLEAN_TARGETS = config.cache config.log config.status libtool \
  
  
  
  1.14  +24 -0 apr-util/buildconf
  
  Index: buildconf
  ===
  RCS file: /home/cvs/apr-util/buildconf,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- buildconf	1 Jul 2004 22:45:06 -	1.13
  +++ buildconf	7 Oct 2004 08:16:45 -	1.14
  @@ -1,4 +1,20 @@
   #!/bin/sh
  +#
  +# Copyright 1999-2004 The Apache Software Foundation
  +#
  +# Licensed under the Apache License, Version 2.0 (the License);
  +# you may not use this file except in compliance with the License.
  +# You may obtain a copy of the License at
  +#
  +# http://www.apache.org/licenses/LICENSE-2.0
  +#
  +# Unless required by applicable law or agreed to in writing, software
  +# distributed under the License is distributed on an AS IS BASIS,
  +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  +# See the License for the specific language governing permissions and
  +# limitations under the License.
  +#
  +#
   
   # Default place to look for apr source.  Can be overridden with 
   #   --with-apr=[directory]
  @@ -63,6 +79,14 @@
   #
   echo Generating 'make' outputs ...
   $apr_src_dir/build/gen-build.py make
  +
  +#
  +# If apr-iconv, then go and configure it.
  +#
  +if test -d ../apr-iconv; then
  +  echo Invoking ../apr-iconv/buildconf.sh ...
  +  (cd ../apr-iconv; ./buildconf)
  +fi
   
   #
   # If Expat has been bundled, then go and configure the thing
  
  
  
  1.80  +15 -0 apr-util/configure.in
  
  Index: configure.in
  ===
  RCS file: /home/cvs/apr-util/configure.in,v
  retrieving revision 1.79
  retrieving revision 1.80
  diff -u -r1.79 -r1.80
  --- configure.in	2 Sep 2004 13:50:28 -	1.79
  +++ configure.in	7 Oct 2004 08:16:45 -	1.80
  @@ -96,6 +96,21 @@
   APR_ADDTO(CFLAGS, `$apr_config --cflags`)
   APR_ADDTO(CPPFLAGS, `$apr_config --cppflags`)
   
  +dnl
  +dnl  Find the APR-ICONV directory.
  +dnl
  +if test -d ../apr-iconv; then
  +  APR_SUBDIR_CONFIG(../apr-iconv,
  +[$apache_apr_flags --prefix=$prefix --exec-prefix=$exec_prefix --libdir=$libdir --includedir=$includedir --bindir=$bindir --datadir=$datadir --with-installbuilddir=$installbuilddir],
  +[--enable-layout=*|\'--enable-layout=*])
  +  APRUTIL_EXPORT_LIBS=$abs_srcdir/../apr-iconv/lib/libapriconv.la $APRUTIL_EXPORT_LIBS
  +  APRUTIL_INCLUDES=-I$abs_srcdir/../apr-iconv/include $APRUTIL_INCLUDES
  +  APR_ICONV_DIR=../apr-iconv
  +else
  +  APR_ICONV_DIR=
  +fi
  +AC_SUBST(APR_ICONV_DIR)
  +
   dnl Find LDAP library
   dnl Determine what DBM backend type to use.
   dnl Find Expat
  
  
  
  1.6   +26 -14apr-util/build/apu-iconv.m4
  
  Index: apu-iconv.m4
  ===
  RCS file: /home/cvs/apr-util/build/apu-iconv.m4,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- apu-iconv.m4	21 Jul 2002 11:09:12 -	1.5
  +++ apu-iconv.m4	7 Oct 2004 08:16:45 -	1.6
  @@ -22,33 +22,44 @@
   AC_DEFUN(APU_FIND_ICONV,[
   
   apu_iconv_dir=unknown
  +have_apr_iconv=0
   AC_ARG_WITH(iconv,[  --with-iconv[=DIR]path to iconv 

Re: cvs commit: apr/build jlibtool.c

[jean-frederic clere]

[EMAIL PROTECTED] wrote:
jfclere 2004/09/27 09:21:16
  Modified:buildjlibtool.c
  Log:
  Use -L path -llib_name instead of path/liblib_name.ext.
  That is still not ok because httpd would need something like:
  -Brpath=pathname or -Wl,-Brpath-pathname but we only have this information
  when building the library (when libtool is called with -rpath pathname).
Should I store the pathname in the *.la file (that is what the gnu 
libtool does)?
Cheers
Jean-Frederic
+++ CUT +++

Re: Patch to support OSD_EBCDIC_DF04_1 in expat

[jean-frederic clere]

Jeff Trawick wrote:
jean-frederic clere wrote:
Hi,
Find enclosed a patch that allows to parse xml documents encoded in 
EBCDIC (OSD_EBCDIC_DF04_1). Some days ago I already committed the need 
include files:
xml/expat/lib/map_osd_ebcdic_df04_1.h and 
xml/expat/lib/osd_ebcdic_df04_1.h

Any comments?

just a dumb question...  is this code being submitted to expat folks so 
that if we pick up later revision of expat we don't have to continue to 
main this code separately?


I have submitted a patch to the corresponding sourceforge project (987903).
Cheers
Jean-Frederic

Re: cvs commit: apr-util/xml apr_xml.c

[jean-frederic clere]

Joe Orton wrote:
On Wed, Jun 23, 2004 at 04:10:58PM +0200, jean-frederic clere wrote:
Why take a convset if this can only convert to EBCDIC? You know that the
tree is in UTF-8 so there is no other variable for the caller to
control.
The convset I have used is ap_hdrs_from_ascii. (APR_DEFAULT_CHARSET, 
ISO8859-1) that is fixed.

It's broken then - the XML parser returns UTF-8.
It looks like the code will silently corrupt any part of the DOM tree
which can't be entirely converted to EBCDIC, since it ignores the
_conv_buffer return values, which doesn't seem acceptable to me.
Ok, I have prepared the attached patch should I apply it?
joe


Index: apr_xml.c
===
RCS file: /home/cvs/apr-util/xml/apr_xml.c,v
retrieving revision 1.32
diff -u -r1.32 apr_xml.c
--- apr_xml.c   23 Jun 2004 14:36:41 -  1.32
+++ apr_xml.c   6 Jul 2004 08:38:12 -
@@ -896,29 +896,49 @@
 apr_xml_elem *ec;
 apr_text *t;
 apr_size_t inbytes_left, outbytes_left;
+apr_status_t status;
 
 inbytes_left = outbytes_left = strlen(e-name);
-apr_xlate_conv_buffer(convset, e-name,  inbytes_left, (char *) e-name, 
outbytes_left);
+status = apr_xlate_conv_buffer(convset, e-name,  inbytes_left, (char *) 
e-name, outbytes_left);
+if (status) {
+return status;
+}
 
 for (t = e-first_cdata.first; t != NULL; t = t-next) {
 inbytes_left = outbytes_left = strlen(t-text);
-apr_xlate_conv_buffer(convset, t-text, inbytes_left, (char *) 
t-text, outbytes_left);
+status = apr_xlate_conv_buffer(convset, t-text, inbytes_left, (char 
*) t-text, outbytes_left);
+if (status) {
+return status;
+}
 }
 
 for (t = e-following_cdata.first;  t != NULL; t = t-next) {
 inbytes_left = outbytes_left = strlen(t-text);
-apr_xlate_conv_buffer(convset, t-text, inbytes_left, (char *) 
t-text, outbytes_left);
+status = apr_xlate_conv_buffer(convset, t-text, inbytes_left, (char 
*) t-text, outbytes_left);
+if (status) {
+return status;
+}
 }
 
 for (a = e-attr; a != NULL; a = a-next) {
 inbytes_left = outbytes_left = strlen(a-name);
-apr_xlate_conv_buffer(convset, a-name, inbytes_left, (char *) 
a-name, outbytes_left);
+status = apr_xlate_conv_buffer(convset, a-name, inbytes_left, (char 
*) a-name, outbytes_left);
+if (status) {
+return status;
+}
 inbytes_left = outbytes_left = strlen(a-value);
-apr_xlate_conv_buffer(convset, a-value, inbytes_left, (char *) 
a-value, outbytes_left);
+status = apr_xlate_conv_buffer(convset, a-value, inbytes_left, (char 
*) a-value, outbytes_left);
+if (status) {
+return status;
+}
 }
 
-for (ec = e-first_child; ec != NULL; ec = ec-next)
-apr_xml_parser_convert_elem(ec, convset);
+for (ec = e-first_child; ec != NULL; ec = ec-next) {
+status = apr_xml_parser_convert_elem(ec, convset);
+if (status) {
+return status;
+}
+}
 return APR_SUCCESS;
 }
 
@@ -927,6 +947,7 @@
  apr_xml_doc *pdoc,
  apr_xlate_t *convset)
 {
+apr_status_t status;
 /* Don't convert the namespaces: they are constant! */
 if (pdoc-namespaces != NULL) {
 int i;
@@ -941,12 +962,14 @@
 if ( ptr == NULL)
 return APR_ENOMEM;
 inbytes_left = outbytes_left = strlen(ptr);
-apr_xlate_conv_buffer(convset, ptr, inbytes_left, ptr, 
outbytes_left);
+status = apr_xlate_conv_buffer(convset, ptr, inbytes_left, ptr, 
outbytes_left);
+if (status) {
+return status;
+}
 apr_xml_insert_uri(namespaces, ptr);
 }
 pdoc-namespaces = namespaces;
 }
-apr_xml_parser_convert_elem(pdoc-root, convset);
-return APR_SUCCESS;
+return apr_xml_parser_convert_elem(pdoc-root, convset);
 }
 #endif

Re: cvs commit: apr-util/xml apr_xml.c

[jean-frederic clere]

Joe Orton wrote:
[resend in case it gets through quicker]
On Tue, Jun 22, 2004 at 10:42:23AM -, [EMAIL PROTECTED] wrote:
 --- apr_xml.c	14 Jun 2004 15:13:14 -	1.30
 +++ apr_xml.c	22 Jun 2004 10:42:23 -	1.31
 @@ -30,17 +30,23 @@
  #include expat.h
  #endif
  
 +#include ascii.h
 +
  #define DEBUG_CR \r\n

ascii.h is an internal expat header, this broke the Unix build with an
external expat library.
Ok. I will #define ASCII_* instead including the ascii.h.
Why take a convset if this can only convert to EBCDIC? You know that the
tree is in UTF-8 so there is no other variable for the caller to
control.
The convset I have used is ap_hdrs_from_ascii. (APR_DEFAULT_CHARSET, 
ISO8859-1) that is fixed.
Passing the convset allows to convert to another charset.

Why does the DOM tree need to be converted into the local charset
in-place anyway?
I am running mod_dav on an EBCDIC mainframe. That is more easy to convert the 
DOM tree in-place than to change mod_dav everywhere.

#if APR_CHARSET_EBCDIC
/**
 * Convert parsed tree in EBCDIC 
 * @param p The pool to allocate out of
 * @param pdoc The apr_xml_doc to convert.
 * @param xlate The translation handle to use.
 * @return Any errors found during conversion.
 */
APU_DECLARE(apr_status_t) apr_xml_parser_convert_doc(apr_pool_t *p,
 apr_xml_doc *pdoc,
 apr_xlate_t *convset);
#endif

Re: Patch to support OSD_EBCDIC_DF04_1 in expat

[jean-frederic clere]

Jeff Trawick wrote:
jean-frederic clere wrote:
Hi,
Find enclosed a patch that allows to parse xml documents encoded in 
EBCDIC (OSD_EBCDIC_DF04_1). Some days ago I already committed the need 
include files:
xml/expat/lib/map_osd_ebcdic_df04_1.h and 
xml/expat/lib/osd_ebcdic_df04_1.h

Any comments?

just a dumb question...  is this code being submitted to expat folks so 
that if we pick up later revision of expat we don't have to continue to 
main this code separately?


And why are we using expat-1.95.2 (lastest version is 1.95.7)?

Re: cvs commit: apr-util/xml/expat/lib map_osd_ebcdic_df04_1.h

[jean-frederic clere]

Joe Orton wrote:
On Thu, May 27, 2004 at 08:19:00AM -, [EMAIL PROTECTED] wrote:
jfclere 2004/05/27 01:19:00
 Added:   xml/expat/lib map_osd_ebcdic_df04_1.h
 Log:
 Table for the OSD_EBCDIC_DF04_1 encoding.
 See http://www.iana.org/assignments/charset-reg/OSD-EBCDIC-DF04-1 for more
 information.

You added two of these files - are they being picked up by the expat
build system in some magical way which I can't fathom, or are they
actually unused?
I have a little more to commit.

 Revision  ChangesPath
 1.1  apr-util/xml/expat/lib/map_osd_ebcdic_df04_1.h
 
 Index: map_osd_ebcdic_df04_1.h
 ===
 static unsigned char ebcdic[] = { 
 /* 00 */ 0x00 ,0x01 ,0x02 ,0x03 ,0x85 ,0x09 ,0x86 ,0x7f ,0x87 ,0x8d ,0x8e ,0x0b ,0x0c ,0x0d ,0x0e ,0x0f ,
 /* 10 */ 0x10 ,0x11 ,0x12 ,0x13 ,0x8f ,0x0a ,0x08 ,0x97 ,0x18 ,0x19 ,0x9c ,0x9d ,0x1c ,0x1d ,0x1e ,0x1f ,
 /* 20 */ 0x80 ,0x81 ,0x82 ,0x83 ,0x84 ,0x92 ,0x17 ,0x1b ,0x88 ,0x89 ,0x8a ,0x8b ,0x8c ,0x05 ,0x06 ,0x07 ,
 /* 30 */ 0x90 ,0x91 ,0x16 ,0x93 ,0x94 ,0x95 ,0x96 ,0x04 ,0x98 ,0x99 ,0x9a ,0x9b ,0x14 ,0x15 ,0x9e ,0x1a ,
 /* 40 */ 0x20 ,0xa0 ,0xe2 ,0xe4 ,0xe0 ,0xe1 ,0xe3 ,0xe5 ,0xe7 ,0xf1 ,0x60 ,0x2e ,0x3c ,0x28 ,0x2b ,0x7c ,
 /* 50 */ 0x26 ,0xe9 ,0xea ,0xeb ,0xe8 ,0xed ,0xee ,0xef ,0xec ,0xdf ,0x21 ,0x24 ,0x2a ,0x29 ,0x3b ,0x9f ,
 /* 60 */ 0x2d ,0x2f ,0xc2 ,0xc4 ,0xc0 ,0xc1 ,0xc3 ,0xc5 ,0xc7 ,0xd1 ,0x5e ,0x2c ,0x25 ,0x5f ,0x3e ,0x3f ,
 /* 70 */ 0xf8 ,0xc9 ,0xca ,0xcb ,0xc8 ,0xcd ,0xce ,0xcf ,0xcc ,0xa8 ,0x3a ,0x23 ,0x40 ,0x27 ,0x3d ,0x22 ,
 /* 80 */ 0xd8 ,0x61 ,0x62 ,0x63 ,0x64 ,0x65 ,0x66 ,0x67 ,0x68 ,0x69 ,0xab ,0xbb ,0xf0 ,0xfd ,0xfe ,0xb1 ,
 /* 90 */ 0xb0 ,0x6a ,0x6b ,0x6c ,0x6d ,0x6e ,0x6f ,0x70 ,0x71 ,0x72 ,0xaa ,0xba ,0xe6 ,0xb8 ,0xc6 ,0xa4 ,
 /* a0 */ 0xb5 ,0xaf ,0x73 ,0x74 ,0x75 ,0x76 ,0x77 ,0x78 ,0x79 ,0x7a ,0xa1 ,0xbf ,0xd0 ,0xdd ,0xde ,0xae ,
 /* b0 */ 0xa2 ,0xa3 ,0xa5 ,0xb7 ,0xa9 ,0xa7 ,0xb6 ,0xbc ,0xbd ,0xbe ,0xac ,0x5b ,0x5c ,0x5d ,0xb4 ,0xd7 ,
 /* c0 */ 0xf9 ,0x41 ,0x42 ,0x43 ,0x44 ,0x45 ,0x46 ,0x47 ,0x48 ,0x49 ,0xad ,0xf4 ,0xf6 ,0xf2 ,0xf3 ,0xf5 ,
 /* d0 */ 0xa6 ,0x4a ,0x4b ,0x4c ,0x4d ,0x4e ,0x4f ,0x50 ,0x51 ,0x52 ,0xb9 ,0xfb ,0xfc ,0xdb ,0xfa ,0xff ,
 /* e0 */ 0xd9 ,0xf7 ,0x53 ,0x54 ,0x55 ,0x56 ,0x57 ,0x58 ,0x59 ,0x5a ,0xb2 ,0xd4 ,0xd6 ,0xd2 ,0xd3 ,0xd5 ,
 /* f0 */ 0x30 ,0x31 ,0x32 ,0x33 ,0x34 ,0x35 ,0x36 ,0x37 ,0x38 ,0x39 ,0xb3 ,0x7b ,0xdc ,0x7d ,0xda ,0x7e
 };
 
 
 

Patch to support OSD_EBCDIC_DF04_1 in expat

[jean-frederic clere]

Hi,
Find enclosed a patch that allows to parse xml documents encoded in EBCDIC 
(OSD_EBCDIC_DF04_1). Some days ago I already committed the need include files:
xml/expat/lib/map_osd_ebcdic_df04_1.h and xml/expat/lib/osd_ebcdic_df04_1.h

Any comments?
Cheers
Jean-Frederic
Index: xml/expat/lib/xmltok.c
===
RCS file: /home/cvs/apr-util/xml/expat/lib/xmltok.c,v
retrieving revision 1.1
diff -u -r1.1 xmltok.c
--- xml/expat/lib/xmltok.c  28 Feb 2001 14:41:26 -  1.1
+++ xml/expat/lib/xmltok.c  21 Jun 2004 14:24:53 -
@@ -860,6 +860,70 @@
 
 #undef PREFIX
 
+/* EBCDIC (OSD_EBCDIC_DF04_1) */
+#define PREFIX(ident) osd_ebcdic_df04_1_ ## ident
+
+/* Map for a one to one conversion */
+#include map_osd_ebcdic_df04_1.h
+static
+void osd_ebcdic_df04_1_toUtf16(const ENCODING *enc,
+   const char **fromP, const char *fromLim,
+   unsigned short **toP, const unsigned short *toLim)
+{
+  while (*fromP != fromLim  *toP != toLim)
+*(*toP)++ = (unsigned char)ebcdic[(unsigned char)*(*fromP)++];
+}
+
+static osd_ebcdic_df04_1_toUtf8(const ENCODING *enc,
+ const char **fromP, const char *fromLim,
+ char **toP, const char *toLim)
+{
+  while (*fromP != fromLim  *toP != toLim) {
+*(*toP)++ = ebcdic[(unsigned char)*(*fromP)];
+(*fromP)++;
+  }
+}
+
+
+#define MINBPC(enc) 1
+
+#define BYTE_TYPE(enc, p) SB_BYTE_TYPE(enc, p)
+
+#define BYTE_TO_ASCII(enc, p) (ebcdic[*(p)])
+
+#define IS_NAME_CHAR(enc, p, n) \
+ (((const struct normal_encoding *)(enc))-isName ## n(enc, p))
+#define IS_NMSTRT_CHAR(enc, p, n) \
+ (((const struct normal_encoding *)(enc))-isNmstrt ## n(enc, p))
+#define IS_INVALID_CHAR(enc, p, n) \
+ (((const struct normal_encoding *)(enc))-isInvalid ## n(enc, p))
+#define IS_NAME_CHAR_MINBPC(enc, p) (0)
+#define IS_NMSTRT_CHAR_MINBPC(enc, p) (0)
+#define CHAR_MATCHES(enc, p, c) (ebcdic[*(p)] == c)
+
+#include xmltok_impl.c
+
+#ifdef XML_NS
+static const struct normal_encoding osd_ebcdic_df04_1_ns = {
+  { VTABLE1, osd_ebcdic_df04_1_toUtf8, osd_ebcdic_df04_1_toUtf16, 1, 0, 0 },
+  {
+#include osd_ebcdic_df04_1.h
+  },
+  STANDARD_VTABLE(sb_)
+};
+#endif
+
+static const struct normal_encoding osd_ebcdic_df04_1 = {
+  { VTABLE1, osd_ebcdic_df04_1_toUtf8, osd_ebcdic_df04_1_toUtf16, 1, 0, 0 },
+  {
+#include osd_ebcdic_df04_1.h
+  },
+  STANDARD_VTABLE(sb_)
+};
+
+#undef MINBPC
+#undef PREFIX
+
 static
 int streqci(const char *s1, const char *s2)
 {
@@ -1363,6 +1427,7 @@
   UTF_16_ENC,
   UTF_16BE_ENC,
   UTF_16LE_ENC,
+  OSD_EBCDIC_DF04_1,
   /* must match encodingNames up to here */
   NO_ENC
 };
@@ -1385,6 +1450,9 @@
 static const char KW_UTF_16LE[] = {
   ASCII_U, ASCII_T, ASCII_F, ASCII_MINUS, ASCII_1, ASCII_6, ASCII_L, ASCII_E, 
'\0'
 };
+static const char KW_OSD_EBCDIC_DF04_1[] = {
+  ASCII_O, ASCII_S, ASCII_D, ASCII_UNDERSCORE, ASCII_E, ASCII_B, ASCII_C, 
ASCII_D, ASCII_I, ASCII_C, ASCII_UNDERSCORE, ASCII_D, ASCII_F,  ASCII_0,  
ASCII_4, ASCII_UNDERSCORE, ASCII_1, '\0'
+};
 
 static
 int getEncodingIndex(const char *name)
@@ -1396,6 +1464,7 @@
 KW_UTF_16,
 KW_UTF_16BE,
 KW_UTF_16LE,
+KW_OSD_EBCDIC_DF04_1,
   };
   int i;
   if (name == 0)
@@ -1504,6 +1573,11 @@
*encPtr = encodingTable[UTF_8_ENC];
return XML_TOK_BOM;
   }
+  break;
+case 0x4C6F:
+  /* ? in EBCDIC */
+  *encPtr = encodingTable[OSD_EBCDIC_DF04_1];
+  return XmlTok(*encPtr, state, ptr, end, nextTokPtr);
   break;
 default:
   if (ptr[0] == '\0') {
Index: xml/expat/lib/xmltok_ns.c
===
RCS file: /home/cvs/apr-util/xml/expat/lib/xmltok_ns.c,v
retrieving revision 1.1
diff -u -r1.1 xmltok_ns.c
--- xml/expat/lib/xmltok_ns.c   28 Feb 2001 14:41:26 -  1.1
+++ xml/expat/lib/xmltok_ns.c   21 Jun 2004 14:24:53 -
@@ -23,6 +23,7 @@
   ns(big2_encoding).enc,
   ns(big2_encoding).enc,
   ns(little2_encoding).enc,
+  ns(osd_ebcdic_df04_1).enc,
   ns(utf8_encoding).enc /* NO_ENC */
 };
 

Re: cvs commit: apr-util/xml apr_xml.c

[jean-frederic clere]

Joe Orton wrote:
On Fri, May 21, 2004 at 02:48:21PM +0200, jean-frederic clere wrote:
Joe Orton wrote:
On Fri, May 21, 2004 at 07:13:44AM -, [EMAIL PROTECTED] wrote:

jfclere 2004/05/21 00:13:44
Modified:xml  apr_xml.c
Log:
Print No parser. in errbuf when parser is NULL.

Why? Passing a NULL parser argument to apr_xml_parser_geterror sounds
like a good time to SIGSEGV.
Before commiting it I have looked in apache-2.0/server/util_xml.c: there 
is a apr_xml_parser_geterror()...

It's not valid (as far as I can see, needn't be valid) to pass a NULL
parser argument to apr_xml_parser_geterror().  What bug are you seeing
which prompted this change?
Sorry... If apr_xml_parser_create() returns NULL.
The bug only occurs in apr-util/test/testxml I will rollback the correction (in 
xml/apr_xml.c) and fix test/testxml.c.

That is the xml file that cores testxml:
+++
?xml version='1.0' encoding='utf-8'
tomcat-users
  role rolename=tomcat/
  role rolename=role1/
  user username=tomcat password=tomcat roles=tomcat/
  user username=both password=tomcat roles=tomcat,role1/
  user username=role1 password=tomcat roles=role1/
/tomcat-users
+++
joe

Re: cvs commit: apr/locks/unix proc_mutex.c

[jean-frederic clere]

Hi Ryan,
apr_proc_mutex_destroy is still in locks/unix/global_mutex.c.
Do I miss something?
Cheers
Jean-frederic
[EMAIL PROTECTED] wrote:
rbb 2002/11/20 13:11:43
  Modified:include  apr_proc_mutex.h
   include/arch/unix proc_mutex.h
   locks/unix proc_mutex.c
  Log:
  Register the proc_mutex cleanup with an exported API.  Most of this
  change is just a name change to make it very obvious what is happening.
  
  Revision  ChangesPath
  1.10  +8 -0  apr/include/apr_proc_mutex.h
  
  Index: apr_proc_mutex.h
  ===
  RCS file: /home/cvs/apr/include/apr_proc_mutex.h,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- apr_proc_mutex.h	10 Nov 2002 08:35:16 -	1.9
  +++ apr_proc_mutex.h	20 Nov 2002 21:11:43 -	1.10
  @@ -163,6 +163,14 @@
   APR_DECLARE(apr_status_t) apr_proc_mutex_destroy(apr_proc_mutex_t *mutex);
   
   /**
  + * Destroy the mutex and free the memory associated with the lock.
  + * @param mutex the mutex to destroy.
  + * @note This function is generally used to kill a cleanup on an already
  + *   created mutex
  + */
  +APR_DECLARE(apr_status_t) apr_proc_mutex_cleanup(void *mutex);
  +
  +/**
* Display the name of the mutex, as it relates to the actual method used.
* This matches the valid options for Apache's AcceptMutex directive
* @param mutex the name of the mutex
  
  
  
  1.11  +1 -1  apr/include/arch/unix/proc_mutex.h
  
  Index: proc_mutex.h
  ===
  RCS file: /home/cvs/apr/include/arch/unix/proc_mutex.h,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- proc_mutex.h	18 Nov 2002 01:59:03 -	1.10
  +++ proc_mutex.h	20 Nov 2002 21:11:43 -	1.11
  @@ -111,7 +111,7 @@
   apr_status_t (*acquire)(apr_proc_mutex_t *);
   apr_status_t (*tryacquire)(apr_proc_mutex_t *);
   apr_status_t (*release)(apr_proc_mutex_t *);
  -apr_status_t (*destroy)(apr_proc_mutex_t *);
  +apr_status_t (*cleanup)(void *);
   apr_status_t (*child_init)(apr_proc_mutex_t **, apr_pool_t *, const char *);
   const char *name;
   };
  
  
  
  1.21  +18 -23apr/locks/unix/proc_mutex.c
  
  Index: proc_mutex.c
  ===
  RCS file: /home/cvs/apr/locks/unix/proc_mutex.c,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- proc_mutex.c	18 Nov 2002 01:59:03 -	1.20
  +++ proc_mutex.c	20 Nov 2002 21:11:43 -	1.21
  @@ -63,6 +63,12 @@
   #define SEM_FAILED (-1)
   #endif
   
  +static apr_status_t proc_mutex_destroy(apr_proc_mutex_t *mutex)
  +{
  +return apr_pool_cleanup_run(mutex-pool, mutex, apr_proc_mutex_cleanup);
  +}
  +
  +
   static void proc_mutex_posix_setup(void)
   {
   }
  @@ -122,7 +128,7 @@
   sem_unlink((const char *) semname);
   new_mutex-interproc-filedes = (int)psem;	/* Ugg */
   apr_pool_cleanup_register(new_mutex-pool, (void *)new_mutex,
  -  proc_mutex_posix_cleanup, 
  +  apr_proc_mutex_cleanup, 
 apr_pool_cleanup_null);
   return APR_SUCCESS;
   }
  @@ -149,17 +155,6 @@
   return APR_SUCCESS;
   }
   
  -static apr_status_t proc_mutex_posix_destroy(apr_proc_mutex_t *mutex)
  -{
  -apr_status_t stat;
  -
  -if ((stat = proc_mutex_posix_cleanup(mutex)) == APR_SUCCESS) {
  -apr_pool_cleanup_kill(mutex-pool, mutex, proc_mutex_posix_cleanup);
  -return APR_SUCCESS;
  -}
  -return stat;
  -}
  -
   static apr_status_t proc_mutex_posix_child_init(apr_proc_mutex_t **mutex,
   apr_pool_t *cont,
   const char *fname)
  @@ -178,7 +173,7 @@
   proc_mutex_posix_acquire,
   NULL, /* no tryacquire */
   proc_mutex_posix_release,
  -proc_mutex_posix_destroy,
  +proc_mutex_posix_cleanup,
   proc_mutex_posix_child_init,
   posixsem
   };
  @@ -234,7 +229,7 @@
   }
   new_mutex-curr_locked = 0;
   apr_pool_cleanup_register(new_mutex-pool,
  -  (void *)new_mutex, proc_mutex_sysv_cleanup, 
  +  (void *)new_mutex, apr_proc_mutex_cleanup, 
 apr_pool_cleanup_null);
   return APR_SUCCESS;
   }
  @@ -294,7 +289,7 @@
   proc_mutex_sysv_acquire,
   NULL, /* no tryacquire */
   proc_mutex_sysv_release,
  -proc_mutex_sysv_destroy,
  +proc_mutex_sysv_cleanup,
   proc_mutex_sysv_child_init,
   sysvsem
   };
  @@ -399,7 +394,7 @@
   new_mutex-curr_locked = 0;
   apr_pool_cleanup_register(new_mutex-pool,
 (void *)new_mutex,
  -  proc_mutex_proc_pthread_cleanup, 
  +

Re: [STATUS] (apr-util) Wed Oct 2 23:45:41 EDT 2002

[jean-frederic clere]

Rodent of Unusual Size wrote:
APRUTIL LIBRARY STATUS: -*-text-*-
Last modified at [$Date: 2002/09/13 23:15:22 $]
Release:
0.9.2   : in progress
0.9.1   : Released as alpha on September 11, 2002
0.9.0   : Not released
2.0a9   : released December 12, 2000
RELEASE SHOWSTOPPERS:
* Separate apr build process so that apr-util can build on its own.
  Suggestions: Create an apr-build subproject and start using it.
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
* Solaris's Sun Freeware (sfw) package has a busted gcc/ld setup.
  This gcc passes -L/opt/sfw/lib to /usr/ccs/bin/ld, but does not 
  pass -R.  Therefore, when trying to run the code using a
  library from /opt/sfw/lib (say, libdb), the run-time linker
  will not look in /opt/sfw/lib and the program will die.
Status: Workaround is to add -R/opt/sfw/lib to LDFLAGS.
Should check latest sfw package set and see if Sun
may have fixed this.
Another work-around would be to add /opt/sfw/lib to the dynamic loader path via 
the command crle or directly in the /var/ld/ld.config file.
I have not try it with sfw but I use it for other softwares.

* GDBM usage of errno is not-thread-safe.  Fix.
Other bugs that need fixing:

Other features that need writing:
* possibly move test/testdbm* to util/dbu
  Justin says: Do we still want to do this?  testdate is now in test.
  Status: Greg +1 (volunteers)
Documentation that needs writing:
* API documentation
Status:
* doc the lifetimes of apr_dbm return values
Available Patches:
Open Issues:

Re: Built APR tarball?

[jean-frederic clere]

Luis Manuel Solla wrote:
Hello,
I've been looking for a *built* tarball of the APR module, but I can't 
find an
exact URL. I prefer built tarballs rather than source tarballs. Could anybody
indicate an URL?
	Just in case, I have installed Apache 1.3.26 and Tomcat 4.0.4
That is a Tomcat question.
You need the sources of APR because Tomcat will configure APR on its needs. (I 
am guessing you are using mod_webapp).

Thanks.

pcre in aprutil

[jean-frederic clere]

Hi,
We would like to use the pcre of httpd-2.0/srclib/pcre in mod_jk2 
(Jakarta-Tomcat).
I think there are no reason to have pcre in httpd-2.0 so I would like to move 
pcre to apr-util.

Any comments?
Cheers
Jean-frederic

Re: Sun forte compiler warnings

[jean-frederic clere]

Justin Erenkrantz wrote:
I tried compiling apr/apr-util with Sun's forte and two files in
the repository are a bit troublesome and may need some thought as
to how to fix them so that we don't emit warnings.
- apr/shmem/unix/shm.c - lots of code fragments result in unreachable
  code because we use #ifdef's and then after all the #ifdef's we
  return APR_ENOTIMPL.  Therefore, this results in the final return
  being unreachable (all code paths return before we hit the final
  APR_ENOTIMPL).  We really should be able to catch this not-impl
  case at pre-processor time, but some of the conditions are really
  convoluted.
That prevents the empty translation unit error messages :-)!
  
- apr-util/ldap/apr_ldap_compat.c - On machines with LDAPv3 libraries,
  this file essentially becomes a no-op which causes forte to return
  'empty translation unit.'  Eek.

Thoughts?  -- justin

Re: apr-config

[jean-frederic clere]

Pier Fumagalli wrote:
It's in the .libs directory... Libtool sucks.
Yep. I have a lot of problems with it because I have 3 compiler in my Solaris 
machine and 2 ld. Need 6 libtools :-((

I have used --link-libtool and basename to get the *.a filename.
It works on Linux.
I will test it on Solaris and ReliantUnix and hope it will works everywhere.
Pier
On Tuesday, Sep 3, 2002, at 09:49 Europe/London, jean-frederic clere wrote:
Hi,
I have some problems with apr-config in mod_webapp:
I am using apr-config --apr-la-file but it returns a result only if 
the .la file exist.

I am configuring mod_webapp and I need to know the name of the .la file.
mod_webapp uses the sources of APR or an installed version of APR.
I would like to avoid to make APR (when using APR sources) in the 
middle of the mod_webapp configure.

I would like to add a --apr-la-file-force that tells the .la file name 
even if the file does not exist.

Any comments?
Cheers
Jean-frederic

apr-config

[jean-frederic clere]

Hi,
I have some problems with apr-config in mod_webapp:
I am using apr-config --apr-la-file but it returns a result only if the .la file 
exist.

I am configuring mod_webapp and I need to know the name of the .la file.
mod_webapp uses the sources of APR or an installed version of APR.
I would like to avoid to make APR (when using APR sources) in the middle of 
the mod_webapp configure.

I would like to add a --apr-la-file-force that tells the .la file name even if 
the file does not exist.

Any comments?
Cheers
Jean-frederic

Re: apr-config

[jean-frederic clere]

Justin Erenkrantz wrote:
On Tue, Sep 03, 2002 at 10:49:02AM +0200, jean-frederic clere wrote:
Hi,
I have some problems with apr-config in mod_webapp:
I am using apr-config --apr-la-file but it returns a result only if the .la 
file exist.

I am configuring mod_webapp and I need to know the name of the .la file.
mod_webapp uses the sources of APR or an installed version of APR.
I would like to avoid to make APR (when using APR sources) in the middle 
of the mod_webapp configure.

I would like to add a --apr-la-file-force that tells the .la file name even 
if the file does not exist.

You want to use --link-libtool not --apr-la-file.  -- justin

Thanks

Re: atomics on solaris producing non-portable binaries

[jean-frederic clere]

Jeff Trawick wrote:
Aaron Bannert [EMAIL PROTECTED] writes:

For example, I have a build of APR from an Ultra5 running Solaris 5.6
that produces sparcv8plus binaries. These binaries do not work on an
older SparcStation5 machine that is running Solaris 5.7.

I'm glad somebody else noticed this :)  I had the fear that somebody
would put the atomic stuff all over Apache and then our build machine
for Solaris binaries caught on fire and had to be replaced with
something new and then we had screaming customers as soon as they
picked up a new build.

Is there still a way we can (automatically) produce atomics code while
preserving backward compatibility? At least we should be portable based
on OS rev (eg. Solaris 5.6 builds of APR should run on every 5.6
machine out there).

I don't know about automatic, but maybe some flag is needed to specify
the architecture level we should enable?
So if you want a binary build for 2.6 and above, on sparc7 and above,
then you build on 2.6 and pass the --with-cpu=sparc7 flag to configure
and it doesn't matter if you're building on the latest and greatest
CPU.  Is that workable?  I guess if you want brain-dead atomic stuff
you could say --with-cpu=generic.
I prefer the --with-cpu and suggest to default to generic.

Re: Volunteering to be RM, WAS: RE: Release 2.0.36 (fwd)

[jean-frederic clere]

Jim Jagielski wrote:
Forwarded message:
Justin Erenkrantz wrote:
The reason I suggested a hold to Sander on account of the atomics
is that we have a bunch of PRs relating to building atomics on
Solaris that haven't been (yet) resolved.
Hold on a tic... I think I see it... On the systems that fail,
I bet they are using GNUas. If so, then ASCPP is 'gcc -E' and thus
the modification of apr_atomic_sparc.s to apr_atomic_sparc.S fails.
If not using GNUas, apr_atomic_sparc.S simply *is* apr_atomic_sparc.s.
So, the problem is what is it in apr_atomic_sparc.s that makes GNUas
barf.
I am thinking of renaming the apr_atomic_sparc.s to apr_atomic_sparc.S and to 
adapt the Makefile  configure to prevent the strange copy mechanism...

Something like:
gcc -Wa,-xarch=v8plus -D_ASM -D__STDC__=0 -c apr_atomic_sparc.S -o
apr_atomic_sparc.lo
The native spro and Forte's version I have accept *.s as well as *.S files.
Any comments?
--
===
  Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
 A society that will trade a little liberty for a little order
will lose both and deserve neither - T.Jefferson

Re: gcc3 and Solaris atomic: (Was: Re: Volunteering to be RM, WAS: RE: Release 2.0.36)

[jean-frederic clere]

Jim Jagielski wrote:
Could you edit your Makefile (in atomic/solaris_sparc) to add the
'-traditional-cpp' option to 'gcc -E' and see what happens? (If
you could 'mv apr_atomic_sparc.S apr_atomic_sparc.S.bak' first so
we can compare that would be cool).
So:

$ gcc -v -traditional-cpp -Wa,-xarch=v8plus -D_ASM -D__STDC__=0 -c apr_atomic
Reading specs from /opt/SMAW/gnu/lib/gcc-lib/sparc-sun-solaris2.8/3.0.3/specs
Configured with: ./configure --prefix=/opt/SMAW/gnu : (reconfigured) ./configure 
--prefix=/opt/SMAW/gnu : (reconfigured) ./configure --prefix=/opt/SMAW/gnu : 
(reconfigured) ./configure --prefix=/opt/SMAW/gnu
Thread model: posix
gcc version 3.0.3
 /opt/SMAW/gnu/lib/gcc-lib/sparc-sun-solaris2.8/3.0.3/tradcpp0 -lang-asm -v 
-D__GNUC__=3 -D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=3 -Dsparc -Dsun -Dunix 
-D__svr4__ -D__SVR4 -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 
-D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4 -D__NO_INLINE__ 
-D__STDC_HOSTED__=1 -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc -D_ASM 
-D__STDC__=0 apr_atomic_sparc.S -o /var/tmp/ccDlMlua.s
GNU traditional CPP version 3.0.3

/opt/SMAW/gnu/lib/gcc-lib/sparc-sun-solaris2.8/3.0.3/../../../../sparc-sun-solaris2.8/bin/as 
-V -Qy -s -xarch=v8plus -o apr_atomic_sparc.lo /var/tmp/ccDlMlua.s
GNU assembler version 2.11.93.0.2 (sparc-sun-solaris2.8) using BFD version 
2.11.93.0.2 20020207
+++
command line: warning: __STDC__ redefined has dispaired.

+++
$ make
make[1]: Entering directory 
`/export/home/apache20/apache/httpd-2.0/srclib/apr/atomic/solaris_sparc'
gcc -E -traditional-cpp -D_ASM -D__STDC__=0 -  
/export/home/apache20/apache/httpd-2.0/srclib/apr/atomic/solaris_sparc/apr_atomic_sparc.s 
 apr_atomic_sparc.S
/opt/SMAW/gnu/bin/as -xarch=v8plus -K PIC -o apr_atomic_sparc.lo apr_atomic_sparc.S
make[1]: Leaving directory 
`/export/home/apache20/apache/httpd-2.0/srclib/apr/atomic/solaris_sparc'
+++

The diff.txt attachement is the result of diff of the gcc -traditional-cpp -E 
-D_ASM -D__STDC__=0 -   and the gcc -E  -D_ASM -D__STDC__=0 -  .
Funny no?
--- apr_atomic_sparc.S  Wed Apr 24 18:05:20 2002
+++ apr_atomic_sparc.wrong  Wed Apr 24 18:06:50 2002
@@ -1,4 +1,4 @@
-# 1 
+# 1 stdin
 !* 
 !* The Apache Software License, Version 1.1
 !*
@@ -50,7 +50,7 @@
 !* This software consists of voluntary contributions made by many
 !* individuals on behalf of the Apache Software Foundation.  For more
 !* information on the Apache Software Foundation, please see
-!* http://www.apache.org/.
+!* http:
 !*
 
 !*
@@ -62,96 +62,12 @@
 !*  section J.11 (page 333)
 !
 # 1 /usr/include/sys/asm_linkage.h 1 3
-
-
-
-
-
-
-
-
+# 9 /usr/include/sys/asm_linkage.h 3
 #pragma ident  @(#)asm_linkage.h  1.3697/09/28 SMI
 
 # 1 /usr/include/sys/stack.h 1 3
-
-
-
-
-
-
-
-
+# 9 /usr/include/sys/stack.h 3
 #pragma ident  @(#)stack.h1.1899/03/23 SMI
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-# 91 /usr/include/sys/stack.h 3
-
-
-# 103 /usr/include/sys/stack.h 3
-
-
-
-
-
-
-
-
-
-
-
-
-# 127 /usr/include/sys/stack.h 3
-
-
-
-
-
-
-
 # 12 /usr/include/sys/asm_linkage.h 2 3
 # 1 /usr/include/sys/trap.h 1 3
 
@@ -162,222 +78,8 @@
 
 
 #pragma ident  @(#)trap.h 1.2999/08/03 SMI
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
 # 13 /usr/include/sys/asm_linkage.h 2 3
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-# 54 /usr/include/sys/asm_linkage.h 3
-
-
-# 70 /usr/include/sys/asm_linkage.h 3
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-# 134 /usr/include/sys/asm_linkage.h 3
-
-
-# 144 /usr/include/sys/asm_linkage.h 3
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-# 603 /usr/include/sys/asm_linkage.h 3
-
-
-
-
-
-
-
-
-
-# 64  2 3
+# 64 stdin 2
 ! %o0  [input]   - the address of the value to increment
 ! %o1  [input]   - the increment delta value
 ! %o2  [local]   - work register (was %l0 in book)
@@ -386,7 +88,7 @@
 !
 !
 !
-.section   .text; .align 4; .global  apr_atomic_add_sparc; 
.type apr_atomic_add_sparc, #function; apr_atomic_add_sparc:  
+ENTRY(apr_atomic_add_sparc)
 
 ld [%o0], %o2   ! set o2 to current value
 _apr_atomic_add_sparc_loop:
@@ -402,7 +104,7 @@
 !
 !
 ! 
-.section   .text; .align 4; .global  apr_atomic_sub_sparc; 
.type apr_atomic_sub_sparc, #function; apr_atomic_sub_sparc:  
+ENTRY(apr_atomic_sub_sparc)
 
 ld [%o0], %o2
 _apr_atomic_sub_sparc_loop:
@@ -423,12 +125,11 @@
 ! %o2  [input]   - value to compare against
 ! %o0  [output]  - the return value
 !
-.section   .text; .align 4; .global  apr_atomic_cas_sparc; 
.type apr_atomic_cas_sparc, 

Re: cvs commit: apr Makefile.in

[jean-frederic clere]

Aaron Bannert wrote:
 
 On Tue, Mar 12, 2002 at 05:30:27PM -, [EMAIL PROTECTED] wrote:
  jfclere 02/03/12 09:30:27
 
Modified:.Makefile.in
Log:
make test fails because there is no subdirectory test in test.
 
Revision  ChangesPath
1.71  +0 -1  apr/Makefile.in
 
Index: Makefile.in
===
RCS file: /home/cvs/apr/Makefile.in,v
retrieving revision 1.70
retrieving revision 1.71
diff -u -r1.70 -r1.71
--- Makefile.in 11 Mar 2002 17:29:06 -  1.70
+++ Makefile.in 12 Mar 2002 17:30:27 -  1.71
@@ -123,7 +123,6 @@
 
 test: $(TARGET_LIB)
(cd test; make clean; make; \
 
 Why don't we just get rid of the above line and keep the next? IOW, why
 must we clean every time we test?

I have noted there is more to do: at least one test needs input.
And having the library as target of the directory is not good.
Probably the following is only acceptable:
test:
(cd test; make)
But of course that means the logic must be added in the makefile of the test
subdirectory.

 
-   cd test; \
for prog in `find . -type f -perm +u+x -name test* -print`; do \
./$$prog; \
if [ $$? -eq 255 ]; then \
 
 
 -a

Re: solaris 2.8 fails to compile two test programs

[jean-frederic clere]

Dale Ghent wrote:
 
 On 9 Mar 2002, Max Okumoto wrote:
 
 | % cc -V
 | cc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2
 
 Sun WorkShop is not supported on Solaris 8. You'll need to upgrade to the
 Sun Forte suite (sun compilers 6.0)

That will not help:
+++
/bin/sh /export/home/clere/apache/httpd-2.0/srclib/apr/libtool --silent
--mode=compile /opt/SUNWspro/WS6U1/bin/cc -g -mt   -DHAVE_CONFIG_H -DSOLARIS2=8
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT   -I../include  -c testrand.c  touch
testrand.lo
testrand.c, line 62: #error: Random support is not available.  Go punt.
cc: acomp failed for testrand.c
*** Error code 1
make: Fatal error: Command failed for target `testrand.lo'
Current working directory /export/home/clere/apache/httpd-2.0/srclib/apr/test
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory /export/home/clere/apache/httpd-2.0/srclib/apr/test
*** Error code 1
make: Fatal error: Command failed for target `test'
$ cc -V
cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11
usage: cc [ options] files.  Use 'cc -flags' for details
+++


 
 /dale

Re: solaris 2.8 fails to compile two test programs

[jean-frederic clere]

Dale Ghent wrote:
 
 On Tue, 12 Mar 2002, Justin Erenkrantz wrote:
 
 | I've also heard of Solaris patches to add /dev/random.  Those would
 | work too, I guess.   -- justin
 
 You know, I keep hearing this, too, and yet I scour sunsolve for them, and
 I dont see a single one.
 
 People might have it confused with the SUNWski package, which comes with
 the Sun Mail Server suite... it includes a randomness daemon that spews
 stuff out via /dev/random, which is a pipe rather than an actual device.
 
 /dale

I have used ./configure --with-egd=/var/run/egd-pool (and of course compiled and
installed prngd). That solves the random problem.

Now I have a problem with atomics:
+++
/bin/sh /export/home/apache20/apache/httpd-2.0/srclib/apr/libtool --silent
--mode=link  /opt/SUNWspro/bin/cc -g -mt   -DHAVE_CONFIG_H -DSOLARIS2=8
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT   -I../include -o testatomic
testatomic.lo ../libapr.la   -lm -lsocket -lnsl -lresolv  -ldl
ild: (undefined symbol) apr_atomic_inc -- referenced in the text segment of
testatomic.o
ild: (undefined symbol) apr_atomic_add -- referenced in the text segment of
testatomic.o
ild: (undefined symbol) apr_atomic_cas -- referenced in the text segment of
testatomic.o
ild: (undefined symbol) apr_atomic_set -- referenced in the text segment of
testatomic.o
ild: (undefined symbol) apr_atomic_init -- referenced in the text segment of
testatomic.o
make[2]: *** [testatomic] Error 5
make[2]: Leaving directory `/export/home/apache20/apache/httpd-2.0/srclib/apr/te
+++
Missing _sparc?

Cheers

Jean-frederic

Re: solaris 2.8 fails to compile two test programs

[jean-frederic clere]

Clere, Jean-Frederic wrote:
 
 Dale Ghent wrote:
 
  On Tue, 12 Mar 2002, Justin Erenkrantz wrote:
 
  | I've also heard of Solaris patches to add /dev/random.  Those would
  | work too, I guess.   -- justin
 
  You know, I keep hearing this, too, and yet I scour sunsolve for them, and
  I dont see a single one.
 
  People might have it confused with the SUNWski package, which comes with
  the Sun Mail Server suite... it includes a randomness daemon that spews
  stuff out via /dev/random, which is a pipe rather than an actual device.
 
  /dale
 
 I have used ./configure --with-egd=/var/run/egd-pool (and of course compiled 
 and
 installed prngd). That solves the random problem.
 
 Now I have a problem with atomics:
 +++
 /bin/sh /export/home/apache20/apache/httpd-2.0/srclib/apr/libtool --silent
 --mode=link  /opt/SUNWspro/bin/cc -g -mt   -DHAVE_CONFIG_H -DSOLARIS2=8
 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT   -I../include -o testatomic
 testatomic.lo ../libapr.la   -lm -lsocket -lnsl -lresolv  -ldl
 ild: (undefined symbol) apr_atomic_inc -- referenced in the text segment of
 testatomic.o
 ild: (undefined symbol) apr_atomic_add -- referenced in the text segment of
 testatomic.o
 ild: (undefined symbol) apr_atomic_cas -- referenced in the text segment of
 testatomic.o
 ild: (undefined symbol) apr_atomic_set -- referenced in the text segment of
 testatomic.o
 ild: (undefined symbol) apr_atomic_init -- referenced in the text segment of
 testatomic.o
 make[2]: *** [testatomic] Error 5
 make[2]: Leaving directory 
 `/export/home/apache20/apache/httpd-2.0/srclib/apr/te
 +++
 Missing _sparc?

I have fixed it in include/apr_atomic.h ;-)

 
 Cheers
 
 Jean-frederic

Re: Latest CVS on Solaris 8 - configure's cache-file problems

[jean-frederic clere]

Jeff Trawick wrote:
 
 Jim Jagielski [EMAIL PROTECTED] writes:
 
  Yep... Looks like it's no problem with 2.52.
 
  Anyone have hearburn if I adjust buildcheck.sh to make 2.52 the
  new requirement?
 
 at least a little, but I'm not exactly sure how much :)  In the 2.0.30
 timeframe a colleage was unable to get make distclean followed by a
 new ./configure configure to work on AIX when using autoconf 2.52.
 Backing down to autoconf 2.13 resolved the problem.  But maybe that
 has been fixed problem has subsequently been fixed (some stray file
 left around?).
 
 I didn't see an indication of which autoconf version you had problems
 with.  I just did cvs update and ./configure on Solaris 8 using
 autoconf 2.13 and so far it has gotten past the APR configure.
 
 Did configure ever work for you on that machine with autoconf  2.52?
 
 (I guess what I'd like to say is that no autoconf is perfect -- or
 perfectly supported by Apache+APR -- and that maybe some debugging is
 appropriate before we start disallowing a very common version of
 autoconf.)

On ReliantUnix autoconf 2.52 does not work.
./buildconf gives the following error:
+++
nawk: Tempcell list is curdled
nawk: Source line number 7
+++
2.13 works well.

 --
 Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
  Born in Roswell... married an alien...

Re: possible oversight

[jean-frederic clere]

MIS wrote:
 
 I may have found an oversight in the latest mod_webapp source distribution.
 The file .../webapp/apache-13/Makefile.in is looking for APR files, but
 according to http://apr.apache.org/ APR is only supported on Apache 2.x.

No, It is Apache Portable Runtime, if you read the page carefull you will note
that Subversion also uses it.
I think mod_webapp is too small to be mentioned on this APR page.
jakarta-commons-sandbox/daemon will also use APR.


  Am
 I mistaken?  If so I apologize for consuming your time.  So far I am unable
 to build the module for my Apache 1.3.22 server.  I have Tomcat 4.0.3
 running and I love it.
 
 Regards,
 
 Len Huppe
 Mesa MIS
 P 603-456-2002 x238
 F 603-456-2112
 [EMAIL PROTECTED]
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: Building APR

[jean-frederic clere]

B. W. Fitzpatrick wrote:
 
 On Tuesday, March 5, 2002, at 12:46  AM, Jason Filby wrote:
 
  Hey all
 
  Looks like you must have MSVC++ to build APR on Windows... isn't
  there some way to build it with MingW (GCC ported to win32) or some
  other Open Source compiler?
 
 I'm pretty sure that you *can*, but I would be a little leery of building
 a portability layer on top of another portability layer.
 
 -Fitz

gcc -mno-cygwin makes a code that uses native win32 dlls.

inttypes.h why?

[jean-frederic clere]

Hi,

I have noted (because I have a machine that does not have the file) that
mktemp.c includes inttypes.h but I do not see why.

I think the #include inttypes.h is useless or even bad.

I will remove it if nobody complains (Otherwise I will add APR_HAVE_INTTYPES_H).

Any comments?

Cheers

Jean-frederic

Re: cvs commit: apr/test testatomic.c

[jean-frederic clere]

Dale Ghent wrote:
 
 On Wed, 20 Feb 2002, Ian Holsman wrote:
 
 | jean-frederic clere wrote:
 |  It works only with the native as but not with gas.
 |
 | is this a problem on solaris?
 | doesn't every box come with 'as' out of the box?
 
 It doesnt install with the basic installation scheme. The SUNWsprot and
 SUNWbtool/SUNWbtoox packages need to be installed.
 
 The other caveat is that /usr/ccs/bin isnt in alot of peoples' paths, so
 it is overlooked, and they then install the (inferior) GNU binutils.
 
 /dale

I think it is possible to get the file assembled by gnu as... It just need to be
preprocessed by gnu cpp before.
+++
cpp -D_ASM -D__STDC__=0 $*.s  $*.S
as -xarch=v8plus -K PIC -q -o $@ $*.S
+++
Any comments? -Now I will add the need things in configure and makefile -

Cheers

Jean-Frederic

Re: cvs commit: apr/test testatomic.c

[jean-frederic clere]

Hi,

I have committed some changes but I am not happy...
Instead using cpp it would be better to use gcc directly:

gcc -Wa,-xarch=v8plus -D_ASM -D__STDC__=0 -c apr_atomic_sparc.S -o
apr_atomic_sparc.lo

I have just to change apr_atomic_sparc.s into apr_atomic_sparc.S. The native
solaris as accepts the *.S files.

Any comments?

Cheers

Jean-frederic

Clere, Jean-Frederic wrote:
 
 Dale Ghent wrote:
 
  On Wed, 20 Feb 2002, Ian Holsman wrote:
 
  | jean-frederic clere wrote:
  |  It works only with the native as but not with gas.
  |
  | is this a problem on solaris?
  | doesn't every box come with 'as' out of the box?
 
  It doesnt install with the basic installation scheme. The SUNWsprot and
  SUNWbtool/SUNWbtoox packages need to be installed.
 
  The other caveat is that /usr/ccs/bin isnt in alot of peoples' paths, so
  it is overlooked, and they then install the (inferior) GNU binutils.
 
  /dale
 
 I think it is possible to get the file assembled by gnu as... It just need to 
 be
 preprocessed by gnu cpp before.
 +++
 cpp -D_ASM -D__STDC__=0 $*.s  $*.S
 as -xarch=v8plus -K PIC -q -o $@ $*.S
 +++
 Any comments? -Now I will add the need things in configure and makefile -
 
 Cheers
 
 Jean-Frederic

Using APR in mod_webapp

[jean-frederic clere]

Hi,

I have a question:

mod_webapp from Tomcat uses APR:

Where should APR be downloaded from? - It must be a tarball because that is for
the ones that want to build mod_webapp on their own -
Until now I was adding apr to a subdirectory of mod_webapp and releasing the
corresponding tarball. (Normaly I am using an APR tagged for httpd-2.0).
Using the snapshot of APR http://cvs.apache.org/snapshots/apr/ does not sound
good for at least 2 reasons:
- The sources of Tomcat are always what is used to build the binaries.
- I am not sure that everyone is ready to mix a snapshot with a released
product.

Cheers

Jean-frederic

Re: Using APR in mod_webapp

[jean-frederic clere]

Sander Striker wrote:
 
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
  Behalf Of jean-frederic clere
 
  Hi,
 
  I have a question:
 
  mod_webapp from Tomcat uses APR:
 
  Where should APR be downloaded from? - It must be a tarball because that is 
  for
  the ones that want to build mod_webapp on their own -
  Until now I was adding apr to a subdirectory of mod_webapp and releasing the
  corresponding tarball. (Normaly I am using an APR tagged for httpd-2.0).
 
 Why are you moving away from that now?

Because mod_webapp has been released in jakarta-tomcat-connectors-4.0.2-src.
jakarta-tomcat-connectors hosts both mod_jk and mod_webapp but mod_jk does not
require APR.
That is why I am looking for a new location for APR.

  Because of the bug fixes in APR
 since the latest tag?  If so, why don't you get HEAD and use that?
 
  Using the snapshot of APR http://cvs.apache.org/snapshots/apr/ does not 
  sound
  good for at least 2 reasons:
  - The sources of Tomcat are always what is used to build the binaries.
  - I am not sure that everyone is ready to mix a snapshot with a released
  product.
 
 That second point will have to hold until we have an APR release.
 
  Cheers
 
  Jean-frederic
 
 Sander

Re: [PROPOSAL] apr_spipe_t - stream pipe IPC mechanism

[jean-frederic clere]

Aaron Bannert wrote:
 
 A stream pipe is a full-duplex pipe that can be used to communicate data,
 file descriptors and socket descriptors. When one of the pairs is used
 in a parent process and another in a child process it allows a form of
 interprocess communication. [straight from my apr_spipe_create comment]
 
 The main features of this API are:
 
 - datagram-style delivery of data and metadata (as a bundle)
 - can pass data efficiently, if possible (it prefers iovec)
 - can pass apr_file_t and apr_socket_t types
 
 The main use case for this API is to make the perchild MPM portable
 to platforms other than Linux.
 
 The name apr_spipe_t was chosen over something more broad, like
 apr_ipc_t because the author believes this name more accurately
 describes a type of IPC, in a world where we may implement other
 forms of IPC later.

Could this be extented to process that are not son processes? - AF_UNIX sockets
allow it -

 
 -aaron
 
 /* 
  * The Apache Software License, Version 1.1
  *
  * Copyright (c) 2000-2001 The Apache Software Foundation.  All rights
  * reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  *
  * 1. Redistributions of source code must retain the above copyright
  *notice, this list of conditions and the following disclaimer.
  *
  * 2. Redistributions in binary form must reproduce the above copyright
  *notice, this list of conditions and the following disclaimer in
  *the documentation and/or other materials provided with the
  *distribution.
  *
  * 3. The end-user documentation included with the redistribution,
  *if any, must include the following acknowledgment:
  *   This product includes software developed by the
  *Apache Software Foundation (http://www.apache.org/).
  *Alternately, this acknowledgment may appear in the software itself,
  *if and wherever such third-party acknowledgments normally appear.
  *
  * 4. The names Apache and Apache Software Foundation must
  *not be used to endorse or promote products derived from this
  *software without prior written permission. For written
  *permission, please contact [EMAIL PROTECTED]
  *
  * 5. Products derived from this software may not be called Apache,
  *nor may Apache appear in their name, without prior written
  *permission of the Apache Software Foundation.
  *
  * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
  * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
  * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
  * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
  * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
  * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
  * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
  * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
  * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
  * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  * SUCH DAMAGE.
  * 
  *
  * This software consists of voluntary contributions made by many
  * individuals on behalf of the Apache Software Foundation.  For more
  * information on the Apache Software Foundation, please see
  * http://www.apache.org/.
  */
 
 #ifndef APR_SPIPE_H
 #define APR_SPIPE_H
 
 #include apr.h
 #include apr_file_io.h
 #include apr_network_io.h
 #include apr_pools.h
 #include apr_errno.h
 
 #ifdef __cplusplus
 extern C {
 #endif /* __cplusplus */
 
 /**
  * @file apr_spipe.h
  * @brief APR Stream Pipe Routines
  */
 
 /**
  * @defgroup APR_SPIPE Stream Pipe Routines
  * @ingroup APR
  * @{
  */
 
 #define APR_SPIPE_BLOCK 0x1
 #define APR_SPIPE_NONBLOCK  0x2
 
 /**
  * Private, platform-specific data struture representing a stream pipe.
  */
 typedef struct apr_spipe_t apr_spipe_t;
 
 /**
  * Enumeration of the types of metadata that can be passed over a
  * stream pipe.
  */
 typedef enum {
 APR_SPIPE_NONE   = 0,
 APR_SPIPE_FILE   = 1,
 APR_SPIPE_SOCKET = 2
 } apr_spipe_msg_type_e;
 
 /**
  * Types of metadata that we can transfer across a stream pipe.
  * This is a union because we only want to pass one at a time.
  */
 typedef union {
 apr_file_t   *file;/* file descriptor to pass across pipe */
 apr_socket_t *sock;/* socket descriptor to pass across pipe */
 } apr_spipe_msg_metadata_u;
 
 /**
  * Structure of a message that can be passed over a stream pipe.
  * The major fields are optional, and may be NULL.
  */
 typedef struct {
 struct iovec *msg_iov; /* scatter/gather array, from struct msghdr */
 apr_size_t

Re: [PATCH] Add support for Unix domain sockets

[jean-frederic clere]

David Reid wrote:
 
 I've been up all night so this may be off base...
 
 AFAICR sockets using AF_UNIX are essentially local inter process
 communication channels?

They are local sockets. The difference is a little like the difference between
IPV4 and IPV6.
The socket() call need a different parameter and the addresses are different
(bind() and connect()).

 
 If this is the case then why are we having this discussion about adding more
 to the network_io and not simply talking about adding an ipc_ set of
 functions to apr that allow each platform to implement it in their own way,
 as we've done with all the other stuff in apr?  After all that's what apr is
 for isn't it? :)

That is only a small addition to the apr sockets.

An ipc_ should be in apr-util? That is a higher level layer.

 
 This may take a bit of getting the api correct (at least to allow it work on
 all platforms) but I'm sure we can manage it.
 
 david
 
 - Original Message -
 From: William A. Rowe, Jr. [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Cc: Justin Erenkrantz [EMAIL PROTECTED]; dev@apr.apache.org
 Sent: Friday, January 11, 2002 10:03 AM
 Subject: Re: [PATCH] Add support for Unix domain sockets
 
  From: jean-frederic clere [EMAIL PROTECTED]
  Sent: Friday, January 11, 2002 3:44 AM
 
 
   I would like to see this patch committed.
   I am using AF_UNIX sockets in mod_jk and it would be nice to do it thru
 APR
   instead my own code.
  
   About win32 support I am afraid I cannot help. But I think it is a
 little like
   IPV6 on IPV4 only machines: we should just say APR_LOCAL is not
 supported on
   win32.
 
  I could be convinced here [for a change :-]
 
  Since this is a fairly old addition to the -sockets- layer, I can't really
  stand in the way.  We aren't talking about specific platforms, but a
 sockets
  feature.  If winsock doesn't add it, their loss.
 
  We need to return APR_ENOTIMPL for that, I suppose.
 
  Bill
 
 

Re: [PATCH] Add support for Unix domain sockets

[jean-frederic clere]

Sander Striker wrote:
 
  From: David Reid [mailto:[EMAIL PROTECTED]
  Sent: 11 January 2002 13:21
  To: APR Dev List
  Subject: Re: [PATCH] Add support for Unix domain sockets
 
   David Reid wrote:
 
  I've been up all night so this may be off base...
 
  AFAICR sockets using AF_UNIX are essentially local inter process
  communication channels?
 
  They are local sockets. The difference is a little like the difference
  between IPV4 and IPV6.
  The socket() call need a different parameter and the addresses are
  different (bind() and connect()).
 
  Yeah, I know all of this :)  From memory they are normally used as IPC and
  that was what I was getting at.
 
 Indeed.

Could we add AF_UNIX sockets to win32? That sounds a better option.
If that needs some coding than  we could return ENOTIMPL util someone implements
it.

The idea to use AF_UNIX sockets in mod_jk is to speed up the actual AF_INET
socket commucations between Tomcat and Apache. A fail back to a normal socket
connection would be acceptable.

An other point is that AF_UNIX sockets are no used only in mod_jk but also in
mod_cgid and EGB connections (rand.c).

 
  If this is the case then why are we having this discussion about adding
  more to the network_io and not simply talking about adding an ipc_ set of
  functions to apr that allow each platform to implement it in their own
  way, as we've done with all the other stuff in apr?  After all that's what
  apr is for isn't it? :)
 
  That is only a small addition to the apr sockets.
 
  But that's NOT really the point is it?  The point is that not all the
  platforms can truly support this functionality and adding it just so we have
  it on some platforms and everyone else has to return ENOTIMPL seems to be
  crazy and against the very reason for APR.
 
 I agree.  We need a portable ipc mechanism.

My ReliantUnix has to return ENOTIMPL for IPV6 sockets that does not disturb me.
Why does it disturb so much when win32 has to return ENOTIMPL when using AF_UNIX
sockets?

 
  An ipc_ should be in apr-util? That is a higher level layer.
 
  OK, so apr-util, I could care less where it goes, it's more the concept that
  I'm concerned about.
 
 It belongs in APR, because otherwise you have to do runtime checks in apr-util
 to see if APR_ENOTIMPL is returned for unix domain sockets and then try the
 thing we have as a fallback for a different platform (yuck).

Agreed... This ipc_ could be shared memory pipes or whatever the system
supports. It has not to be unix domain sockets.

 
  david
 
 Sander

Re: [PATCH] Add support for Unix domain sockets

[jean-frederic clere]

Justin Erenkrantz wrote:
 
 On Fri, Jan 04, 2002 at 08:49:59PM -0500, Jeff Trawick wrote:
  I'm pretty sure that native Win32 does not have AF_UNIX, but then what
  would they need it for.  You could argue that APR could have a common
  API which on Unix might use AF_UNIX sockets and on Win32 might use
  named pipes.  I don't know what that API would be, though.
 
 Well, here is a use case for AF_UNIX sockets.  Does anyone have a use
 case for named pipes on Win32?  The code seemed close enough that it
 just made more sense to add the few bits here and there to try and
 get it to work.  I just don't think in native Unix code anymore.
 I like coding with APR much better.  =)
 
   This is needed for EGD support.
 
  not really...  You don't need this to do AF_UNIX sockets inside APR.
  A pure socket interface will avoid the pool issue too.
 
 Granted - we could do it in a non-portable fashion.  I just think the
 a_g_r_b prototype is wrong and if we introduce a more complicated
 entropy-gathering mechanism, it's going to need a pool too.
 
  If APR should have an interface to AF_UNIX sockets, that's fine, but
  that has been unclear.
 
 I think so.  I see no reason why it shouldn't have it.  In fact a
 lot of APR's socket code is supposing that the socket is IP-based.
 I think that's completely bogus.
 
   +#if APR_HAVE_UNIX_DOMAIN
   +#define APR_UNIX AF_UNIX
   +#endif
 
  Note that POSIX supposedly prefers AF_LOCAL to AF_UNIX.  But we
  already have APR_LOCAL :)  (What about APR_SOCKET_INET,
  APR_SOCKET_INET6, APR_SOCKET_LOCAL?  Or better yet, AF_INET, AF_INET6,
  AF_LOCAL? (Sorry, David))
 
 AF_LOCAL or PF_LOCAL aren't defined on Solaris.  =)  I think there
 are some platforms that have removed AF_ and gone to PF_.  So, I
 think it might be good to keep some level of indirection.
 
   Index: network_io/unix/sockets.c
   ===
   RCS file: /home/cvs/apr/network_io/unix/sockets.c,v
   retrieving revision 1.90
   +sock-local_addr-salen = sizeof(struct sockaddr_un);
 
  this doesn't work perfectly with AF_UNIX...  the size as passed to
  connect() should reflect the real path string once we know it...  but
  there is nothing we can do at this point anyway because we don't know
  the path string...
 
  Your EGD code would need to set salen to SUN_PATH(sa.sunix) before
  calling apr_connect().  And SUN_PATH() isn't provided everywhere, so
  grab the one from Stevens' (MHRIP) UNP2eV2.
 
 This leads me to believe that we should have an
 apr_sockaddr_set_path(...) function that hides these implementation
 details.
 
   +sock-local_addr-addr_str_len = 108;
 
  What about terminating '\0'?  Maybe it should be sizeof(sun_path) + 1?
 
 The address is defined to be char[108] in every header file I can
 find, so this seems to be the magic number.

On a FreeBDS I have:
+++
/*
 * Definitions for UNIX IPC domain.
 */
struct  sockaddr_un {
u_char  sun_len;/* sockaddr len including null */
u_char  sun_family; /* AF_UNIX */
charsun_path[104];  /* path name (gag) */
};
+++

 
  Where's the rest?  Yeah, we don't need it yet for EGD, but why bother
  until somebody is ready to implement a bunch of it at once so we can
  think through the API issues?  (starting with (1) should we have
  something that maps to an AF_UNIX socket on Unix and (2) should that
  something be APR sockets and (3) what do we do on non-Unix platforms?)
 
 This is why I posted it to the list.  =)  I think this may get
 implemented and fleshed out as the need arises.  This should allow
 it to connect, read, and write to a Unix domain socket.  If you
 want to get fancy and do accept and bind on them, you'll need to
 write/correct those functions.  -- justin

[Fwd: Noted a problem with configure on mod_webapp]

[jean-frederic clere]

Hi,

I have noted a APR question in TC user list, if what is said is true then we
have to arrange build/apr_common.m4

Any hints?

Cheers

Jean-frederic---BeginMessage---
Hi all.

This is more for developers, but here goes. OS is Tru64 UNIX 4.0F (a.k.a. 
Digital UNIX (a.k.a. DEC OSF/1)). I'm using native CC of Tru64. configure 
script in APR erroneously detects the presence of stdint.h on the system and 
that consequently bugs the whole mod_webapp.so.

mod_webapp.so, although built wouldn't load with a message:

Legba:/usr/local/apache/conf# /usr/local/apache/bin/apachectl configtest
Syntax error on line 218 of /usr/local/apache/conf/httpd.conf:
Cannot load /usr/local/apache/libexec/mod_webapp.so into server: Unresolved 
symbol in /usr/local/apache/libexec/mod_webapp.so: INT64_C

I have run the portion which detects INT64_C in stdint.h of the configure 
manually and it produces a wrong conclusion.

THE PROBLEM is in this:

cat conftest.$ac_ext _ACEOF
#line 18159 configure
#include confdefs.h

#include stdint.h
#ifdef INT64_C
YES_IS_DEFINED
#endif

_ACEOF

Please note that the portion of CPP directives (those three in the middle) is 
*indented*.

Well, this is not supported in Tru64's CC and frankly I don't know of a C 
language specification which allows it. To make myself perfectly clear, all C 
language specifications I've seen (KR C and ANSI C), insist on # sign of the 
CPP directive being in the first column or the first character on the line. You 
can indent the directive itself, but the # MUST be in the first column. DEC 
CC insists on this and ignores lines that have whitespace before #. So, 
something like this would be correct:

cat conftest.$ac_ext _ACEOF
#line 18159 configure
#include confdefs.h

#include stdint.h
#ifdef INT64_C
 YES_IS_DEFINED
#endif

_ACEOF

I'm guessing that GCC allows for indentation of CPP lines, but I still think it 
is against the specification. Reasoning like GCC is the major CC in the world, 
comply with it is something I would expect from Microsoft - and not from GCC, 
Apache or Tomcat supporters.

I know I could build GCC for Tru64 UNIX and save myself a lot of trouble in 
the future, but that would be 50-th meander in building some final-stage 
product on my machine, which is not only time-, but also nerve-consuming, as 
well.

For the time being I'll manually weed out all of you non-hackers, who are not 
fit to serve in my beloved corps (Full metal jacket-Stanley Kubrick). Of 
course, untaring sources from scratch...

Nix.


smime.p7s
Description: S/MIME cryptographic signature
---End Message---
Index: apr_common.m4
===
RCS file: /home/cvs/apache/apr/build/apr_common.m4,v
retrieving revision 1.21
diff -u -r1.21 apr_common.m4
--- apr_common.m4   2001/07/24 10:05:36 1.21
+++ apr_common.m4   2001/10/03 15:59:01
@@ -208,10 +208,10 @@
 for curhdr in $2
 do
   AC_EGREP_CPP(YES_IS_DEFINED, [
-  #include $curhdr
-  #ifdef $1
+#include $curhdr
+#ifdef $1
   YES_IS_DEFINED
-  #endif
+#endif
   ], ac_cv_define_$1=yes)
 done
   ])
@@ -227,10 +227,10 @@
 AC_DEFUN(APR_CHECK_DEFINE,[
   AC_CACHE_CHECK([for $1 in $2],ac_cv_define_$1,[
 AC_EGREP_CPP(YES_IS_DEFINED, [
-#include $2
-#ifdef $1
+#include $2
+#ifdef $1
 YES_IS_DEFINED
-#endif
+#endif
 ], ac_cv_define_$1=yes, ac_cv_define_$1=no)
   ])
   if test $ac_cv_define_$1 = yes; then
@@ -243,10 +243,10 @@
 dnl
 AC_DEFUN(APR_CHECK_APR_DEFINE,[
 AC_EGREP_CPP(YES_IS_DEFINED, [
-#include $2/include/apr.h
-#if $1
+#include $2/include/apr.h
+#if $1
 YES_IS_DEFINED
-#endif
+#endif
 ], ac_cv_define_$1=yes, ac_cv_define_$1=no)
 ])
 
@@ -437,8 +437,8 @@
 AC_MSG_CHECKING(for type of inbuf parameter to iconv)
 if test x$apr_iconv_inbuf_const = x; then
 APR_TRY_COMPILE_NO_WARNING([
-#include stddef.h
-#include iconv.h
+#include stddef.h
+#include iconv.h
 ],[
 iconv(0,(char **)0,(size_t *)0,(char **)0,(size_t *)0);
 ], apr_iconv_inbuf_const=0, apr_iconv_inbuf_const=1)

Re: Problems Compiling mod_webapp and APR on Solaris

[jean-frederic clere]

Clere Jean-Frederic FSC EP LP COM 5 wrote:
 
 Klaus Sonnenleiter wrote:
 
  Has anybody successfully compiled mod_webapp and/or the APR library on
  Solaris? I was able to compile everything without any trouble on a RedHat
  7.1 system. But when I tried the same version of the sources (tonight's
  CVS) on Solaris, it failed miserably (some output below). The errors seem
  to be related to the APR library and I've tried to use a more recent one
  which compiles without problems, but it creates conflicts when compiling
  the mod_webapp module (it requires a different number of parameters and I
  remember from a discussion here that it was considered safer to stay with
  the older library).
 
  TIA
 
  -- snip -
 
  Compiling sources in /home/klaus/jakarta-tomcat-connectors/webapp/apr...
  make[1]: Entering directory 
  `/home/klaus/jakarta-tomcat-connectors/webapp/apr'
  Making all in strings
  make[2]: Entering directory
  `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings'
  make[3]: Entering directory
  `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings'
  /bin/sh /home/klaus/jakarta-tomcat-connectors/webapp/apr/libtool --silent
  --mode
  =compile gcc-DHAVE_CONFIG_H -DSOLARIS2=7 -D_POSIX_PTHREAD_SEMANTICS
  -D_REENT
  RANT   -I../include -I../include/arch/unix  -c apr_cpystrn.c  touch
  apr_cpystrn.lo
  In file included from apr_cpystrn.c:55:
  ../include/apr.h:187: #error Can not determine the proper size for 
  apr_int64_t
  ../include/apr.h:242: #error Can not determine the proper size for ssize_t
  ../include/apr.h:245: #error Can not determine the proper size for size_t
  ../include/apr.h:254: #error Can not determine the proper size for 
  apr_int64_t
  make[3]: *** [apr_cpystrn.lo] Error 1
  make[3]: Leaving directory
  `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings'
  make[2]: *** [all-recursive] Error 1
  make[2]: Leaving directory
  `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings'
  make[1]: *** [all-recursive] Error 1
  make[1]: Leaving directory 
  `/home/klaus/jakarta-tomcat-connectors/webapp/apr'
  make: *** [apr-all] Error 2
 
  Compiling sources in /home/klaus/jakarta-tomcat-connectors/webapp/apr...
  make[1]: Entering directory 
  `/home/klaus/jakarta-tomcat-connectors/webapp/apr'
  Making all in strings
  make[2]: Entering directory
  `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings'
  make[3]: Entering directory
  `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings'
  /bin/sh /home/klaus/jakarta-tomcat-connectors/webapp/apr/libtool --silent
  --mode=compile gcc-DHAVE_CONFIG_H -DSOLARIS2=7
  -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT   -I../include
  -I../include/arch/unix  -c apr_cpystrn.c  touch apr_cpystrn.lo
  In file included from apr_cpystrn.c:64:
  /usr/include/string.h:43: warning: conflicting types for built-in function
  `memcpy'
  /usr/include/string.h:45: warning: conflicting types for built-in function
  `strcpy'
  /usr/include/string.h:51: warning: conflicting types for built-in function
  `memcmp'
  /usr/include/string.h:52: warning: conflicting types for built-in function
  `strcmp'
  apr_cpystrn.c:84: conflicting types for `apr_cpystrn'
  ../include/apr_strings.h:203: previous declaration of `apr_cpystrn'
  apr_cpystrn.c:126: conflicting types for `apr_tokenize_to_argv'
  ../include/apr_strings.h:224: previous declaration of `apr_tokenize_to_argv'
  apr_cpystrn.c:235: conflicting types for `apr_collapse_spaces'
  ../include/apr_strings.h:212: previous declaration of `apr_collapse_spaces'
  make[3]: *** [apr_cpystrn.lo] Error 1
  make[3]: Leaving directory
  `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings'
  make[2]: *** [all-recursive] Error 1
  make[2]: Leaving directory
  `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings'
  make[1]: *** [all-recursive] Error 1
  make[1]: Leaving directory 
  `/home/klaus/jakarta-tomcat-connectors/webapp/apr'
  make: *** [apr-all] Error 2
 
 I have fixed it try again with the lastest CVS of APR.

No, I can not have fixed all this I have only changed apr_cpystrn... My (wrong)
idea was the size_t changes between include/apr_strings.h and
strings/apr_cpystrn.c, but it should be apr_size_t, shouldn't it?

Re: libapr and --disable-shared?

[jean-frederic clere]

Pier P. Fumagalli wrote:
 
 jean-frederic clere at [EMAIL PROTECTED] wrote:
 
  DOH!  So why do you keep saying that you're against using sources...
  Since all those problems are simply fixed by using them
 
  No, I am not against using the APR sources, I was just thinking that the 
  time
  needed to change mod_webapp could have been used to fix APR. (But it is more
  complicated that I excepted it).
 
 Do you think I didn't think about it? So, can you roll back that -1 so I can
 commit some changes? Thanks :)

Yes, please commit the changes.

 
 Pier

Re: libapr and --disable-shared?

[jean-frederic clere]

Pier P. Fumagalli wrote:
 
 (me dumb when no reply-to header)
 
 Justin Erenkrantz at [EMAIL PROTECTED] wrote:
 
  [ Moving to [EMAIL PROTECTED] ]
 
 From where ? :)
 
  On Wed, Jul 04, 2001 at 05:48:42PM -0700, [EMAIL PROTECTED] wrote:
 
  APR doesn't install the library correctly yet.  Until we fix that, we need
  to use disable shared.  It is in the STATUS file to fix the install, and
  make APR a useful external library.  :-)
 
  BTW, which packages are you refering to?  The only ones I know of
  currently are Apache 2.0 and Subversion.  I would love to get a collection
  of known packages using APR.
 
  mod_webapp from Tomcat 4.0 relies on APR.  And, they require an
  installed version of APR.  They don't believe that the installation
  doesn't work.  =)  (I tried convincing them otherwise...)
 
 Yeah, that's a pain...
 
  I think Pier is working on switching mod_webapp to use the source, but I
  think J.F. Clere has voted against that in tomcat-dev (not sure though,
  he can prolly correct me if I'm misinterpreting his statements).
 
 I'm going to do it... And if he remembers his -1, he'll roll back :)

Well, I said that the problems we had in mod_webapp due to APR should be solved
in APR not in mod_webapp.
I think that not a -1 for using APR sources instead APR installation. It is just
a matter of configure/makefiles I am sure Pier will not -1 a proposal to support
both APR sources and APR installation in mod_webapp.

I am also worried with mod_webapp for Apache-2.0, what will happend when a
internal typedef of APR comming from httpd will be used by mod_webapp and will
be handled differently there because of different APR version?

 Out
 tomorrow or Friday...

I am not every happy to use APR sources in mod_webapp, because I use a libapr
and --disable-shared for mod_webapp on my test platforms (Linux and
ReliantUnix).

It did not work because APR needs some system libraries. To work-around this
problem I have added a LDFLAGS/CFLAGS in mod_webapp makefiles for that. I think
that the information about which system libraries are neeed should be provided
by APR in APRVARS. 

I have also tried with a shared libapr, but that was some weeks ago. I remember
MM problems and some system library missing.

 
 Pier

Re: libapr and --disable-shared?

[jean-frederic clere]

Pier P. Fumagalli wrote:
 
 Copying the Tomcat list  (barf barf, too much crossposting :) :)
 
 Pier
 
 jean-frederic clere at [EMAIL PROTECTED] wrote:
 
  I'm going to do it... And if he remembers his -1, he'll roll back :)
 
  Well, I said that the problems we had in mod_webapp due to APR should be
  solved in APR not in mod_webapp. I think that not a -1 for using APR sources
  instead APR installation. It is just a matter of configure/makefiles I am 
  sure
  Pier will not -1 a proposal to support both APR sources and APR installation
  in mod_webapp.
 
 Right _now_ the only way to be sure to build correctly, is to do it from the
 sources, and so that's what I'm going to do. If, in the future, the build
 and installation process for APR will allow us to build also from a possible
 APR distribution, I'll be more than happy to support it... But now, it's
 better to switch.
 
  I am also worried with mod_webapp for Apache-2.0, what will happend when a
  internal typedef of APR comming from httpd will be used by mod_webapp and 
  will
  be handled differently there because of different APR version?
 
 Who said that for Apache 2.0 there will be 2 different versions of APR? I
 never did (I actually said quite the contrary, that it would be cool to link
 against the HTTPd binary as they do in BeOS.

Now a day it is a little stricky: to link staticly against httpd we need a
config.m4 to put in httpd-2.0/modules/web_app and run autoconf to rebuild the
configure of httpd-2.0...

 
  I am not every happy to use APR sources in mod_webapp, because I use a 
  libapr
  and --disable-shared for mod_webapp on my test platforms (Linux and
  ReliantUnix).
 
 Hmmm... That's why you don't want to build mod_webapp using the APR sources?
 
  It did not work because APR needs some system libraries. To work-around 
  this
  problem I have added a LDFLAGS/CFLAGS in mod_webapp makefiles for that. I
  think that the information about which system libraries are neeed should 
  be
  provided by APR in APRVARS.
 
 You see? How can I get access to APRVARS if I don't use the APR sources?
 Should I just wait for APR to be released as 1.0 to start working on
 mod_webapp again? The _right_ way to do it _now_ is using APR from the
 sources... It's actually the _only_ simple way. As Apache 2.0 does.

Yes I agree.

 
  I have also tried with a shared libapr, but that was some weeks ago. I
  remember MM problems and some system library missing.
 
 DOH!  So why do you keep saying that you're against using sources...
 Since all those problems are simply fixed by using them

No, I am not against using the APR sources, I was just thinking that the time
needed to change mod_webapp could have been used to fix APR. (But it is more
complicated that I excepted it). 

 
 Pier

Re: cvs commit: apr-iconv/lib iconv.c iconv.h iconv_ccs.c iconv_ces_euc.c iconv_ces_iso2022.c iconv_int.c iconv_module.c iconv_uc.c

[jean-frederic clere]

Thanks for fixing all theses, specialy this one:
+++
   1.5   +1 -1  apr-iconv/lib/iconv_ccs.c
 
   Index: iconv_ccs.c
   ===
   RCS file: /home/cvs/apr-iconv/lib/iconv_ccs.c,v
   retrieving revision 1.4
   retrieving revision 1.5
   diff -u -r1.4 -r1.5
   --- iconv_ccs.c   2001/06/21 12:24:11 1.4
   +++ iconv_ccs.c   2001/06/28 05:45:01 1.5
   @@ -34,7 +34,7 @@
#include iconv.h   /* iconv_ccs_desc, iconv_ccs_module */
 
apr_status_t
   -iconv_ccs_event(struct iconv_module *mod, int event)
   +iconv_ccs_event(struct iconv_module *mod, int event, apr_pool_t *ctx)
{
/*   struct iconv_ccs_desc *desc =
+++
I should have noted it before!

Cheers

Jean-frederic
 
 
 
epc

[EMAIL PROTECTED] wrote:
 
 wrowe   01/06/27 22:45:06
 
   Modified:lib  iconv.c iconv.h iconv_ccs.c iconv_ces_euc.c
 iconv_ces_iso2022.c iconv_int.c iconv_module.c
 iconv_uc.c
   Log:
 More apr-ization (size/ssize/pools/stat etc)
 
   Revision  ChangesPath
   1.5   +9 -9  apr-iconv/lib/iconv.c
 
   Index: iconv.c
   ===
   RCS file: /home/cvs/apr-iconv/lib/iconv.c,v
   retrieving revision 1.4
   retrieving revision 1.5
   diff -u -r1.4 -r1.5
   --- iconv.c   2001/06/21 12:24:10 1.4
   +++ iconv.c   2001/06/28 05:45:00 1.5
   @@ -45,25 +45,25 @@
};
 
/*
   - * size_t *result is what the iconv() returns but it is cleaner to return
   + * apr_size_t *result is what the iconv() returns but it is cleaner to 
 return
 * a status.
 * APR_EBADF:   cd is not valid.
 * APR_BADARG: The ouput arguments are not valid.
 */
 
apr_status_t
   -apr_iconv(iconv_t cd, const char **inbuf, size_t *inbytesleft,
   - char **outbuf, size_t *outbytesleft, size_t *result)
   +apr_iconv(iconv_t cd, const char **inbuf, apr_size_t *inbytesleft,
   + char **outbuf, apr_size_t *outbytesleft, apr_size_t *result)
{
 struct iconv_converter *icp = (struct iconv_converter *)cd;
 
 if (icp == NULL) {
   - *result = (size_t) -1;
   + *result = (apr_size_t) -1;
 return(APR_EBADF);
 }
 if (outbytesleft == NULL || *outbytesleft == 0 ||
 outbuf == NULL || *outbuf == 0) {
   - *result = (size_t) -1;
   + *result = (apr_size_t) -1;
 return(APR_BADARG);
 }
 return ( icp-ic_desc-icd_conv(icp-ic_data,
   @@ -123,17 +123,17 @@
const char *from_charset, apr_pool_t *ctx, iconv_t **res)
{
 *res = iconv_open(to_charset, from_charset);
   - if (*res == (size_t) -1)
   + if (*res == (apr_size_t) -1)
 return apr_get_os_error();
 return APR_SUCCESS;
}
 
apr_status_t apr_iconv(iconv_t cd, const char **inbuf,
   -size_t *inbytesleft, char **outbuf,
   -size_t *outbytesleft, size_t *result)
   +apr_size_t *inbytesleft, char **outbuf,
   +apr_size_t *outbytesleft, apr_size_t *result)
{
 *result = iconv(cd , inbuf, inbytesleft, outbuf, outbytesleft);
   - if (*result == (size_t) -1)
   + if (*result == (apr_size_t) -1)
 return apr_get_os_error();
 return APR_SUCCESS;
}
 
 
 
   1.9   +7 -3  apr-iconv/lib/iconv.h
 
   Index: iconv.h
   ===
   RCS file: /home/cvs/apr-iconv/lib/iconv.h,v
   retrieving revision 1.8
   retrieving revision 1.9
   diff -u -r1.8 -r1.9
   --- iconv.h   2001/06/21 12:24:11 1.8
   +++ iconv.h   2001/06/28 05:45:00 1.9
   @@ -34,7 +34,11 @@
 
#include apr.h
#include apr_pools.h
   +#ifdef WIN32
   +#define ICONV_DEFAULT_PATH iconv
   +#else
#include apr_iconv_private.h /* contains ICONV_DEFAULT_PATH */
   +#endif
 
#include stddef.h
 
   @@ -50,7 +54,7 @@
/* __BEGIN_DECLS */
 
apr_status_t apr_iconv_open(const char *, const char *, apr_pool_t *, 
 iconv_t *);
   -apr_status_t apr_iconv(iconv_t, const char **, apr_size_t *, char **, 
 apr_size_t *, size_t *);
   +apr_status_t apr_iconv(iconv_t, const char **, apr_size_t *, char **, 
 apr_size_t *, apr_size_t *);
apr_status_t apr_iconv_close(iconv_t, apr_pool_t *);
 
/* __END_DECLS */
   @@ -88,7 +92,7 @@
 
/* _tbl_simple.c table_load_ccs() calls iconv_mod_load(...ctx) */
 
   -typedef int iconv_mod_event_t(struct iconv_module *, int, apr_pool_t *ctx 
 );
   +typedef int iconv_mod_event_t(struct iconv_module *, int, apr_pool_t *ctx);
 
struct iconv_module_desc {
 int imd_type;
   @@ -248,7 +252,7 @@
typedef  int  iconv_ces_nbits_t(struct iconv_ces *);
typedef  int  iconv_ces_nbytes_t(struct iconv_ces *);
 
   -typedef ssize_t iconv_ces_convert_from_ucs_t
   +typedef apr_ssize_t 

Re: problem with mod_webapp

[jean-frederic clere]

Aaron Bannert wrote:
 
 On Thu, Jun 28, 2001 at 06:35:29PM -0700, Justin Erenkrantz wrote:
   What if (random thoughts coming out now), instead of requiring people to
   build APR (since that seems the biggest source of problems), we don't 
   simply
   ask them where the tarball is, and then in our configure script, we
   configure it, and then build it together while building the module...
  
   In that way we won't have troubles with previous APR installations/builds,
   we _know_ what we're going to supply to the APR configure script and we
   solve all those troubles?
 
  Yup, that's what httpd-2.0 does.  Just require them to slap the apr
  sources in srclib (or something like that).
 
  APR isn't standalone just yet.  I was shocked when I saw that
  mod_webapp required an install of APR.  =)  -- justin

No problem, httpd-2.0 installed it for me ;-) 

 
 APR *will* be standalone, but since it is not yet completely stable it
 may at random times not be standalone. That may be unsatisfactory for
 j-t-c, or maybe that just means that we have to work harder to get
 APR to be standalone.
 
 Last time I built APR standalone for use with j-t-c I didn't have a
 problem with it (on Solaris 8/sparc and Linux/RH 7.1/x86). We just have
 to have docs that capture all the scenarios (which is much harder to do
 in scripts).

I am using normaly using the APR (static libraries) resulting of the httpd-2.0
installation. There are always small things to arrange but a part of changes
must be done in APR and a smaller part of them in mod_webapp.

Using APR sources like httpd-2.0 is dangerous: What will happend when mod_webapp
for Apache-2.0 will be available and that httpd-2.0 and mod_webapp use a
different APR version sources?

APRVARS problably need to be improved, but I am not sure using APR sources
instead APR installation really helps.

 
 Maybe I can post some doc updates from my experiences building that beast.
 
 -aaron

Re: problem launching apache 1.3.19 with apr lib

[jean-frederic clere]

Henri Delebecque wrote:
 
 hello,
 
 I have an Alpha server under Digital Unix 4.0d , running (or trying to):
 Apache 1.3.19
 apr_20010627114532
 Tomcat 4.0 b5
 
 like Markus Mailinglists [EMAIL PROTECTED], I have
 an error : Cannot load /usr.../mod_webapp.so into server: Unresolved
 symbol in /usr.../libapr.so: __eprintf while I try to launch Apache,
 while Tomcat works in standalone mode.
 
 I use also gcc to compile apr.
 
 Any idea ?

Try to add -lc to the LDFLAGS when building the mod_webapp.so
If it does not help, build a static libapr.a and rebuild mod_webapp.so.

 Thanks
 
 --
 __
 | Henri Delebecque[EMAIL PROTECTED] |
 | Webmaster   |
 | Supelec  Tel (33)  01.69.85.14.91   |
 | 3 rue Joliot-Curie  |
 | Plateau de Moulon Fax:(33) 01.69.85.12.34   |
 | 91190 Gif sur Yvette|
 | FRANCE  |
 |_|
 
 __
 | Henri Delebecque[EMAIL PROTECTED] |
 | Webmaster   |
 | Supelec  Tel (33)  01.69.85.14.91   |
 | 3 rue Joliot-Curie  |
 | Plateau de Moulon Fax:(33) 01.69.85.12.34   |
 | 91190 Gif sur Yvette|
 | FRANCE  |
 |_|

Re: inetd-type architecture?

[jean-frederic clere]

Michael Tokarev wrote:
 
 Luke Kenneth Casson Leighton wrote:
 
 []
  srvsvcd's job is also to handle the dependencies for service startup.
 
  we could look at the linux kernel 'Calculating module dependencies'
  code to get an algorithm to work out the startup order.
 
 Why, why, why this is needed  Why not to use runtime linker for
 this?  If some service a needs a routine from a service b, and a
 explicitly (and I mean: explicitly) knows that, why not link a with
 b, like this:
   ld -o a.so a.o ... b.so
 ?  If it is not obvious that a depends of functionality of b (maybe
 because there may be many b's implementations), then place that
 functionality to plain (shared) library (that is also have it's own
 dependances as well), and again, allow runtime linker to do ITS
 job.  Is there runtime linker now that can't load other libraries
 when loading some shared object?

Yes, or even plateforms with no real runtime linker.

 
 Or I completely missed the point here (probably)?
 
 Regards,
  Michael.

Re: apr unicode-16 lib.

[jean-frederic clere]

William A. Rowe, Jr. wrote:
 
 From: jean-frederic clere [EMAIL PROTECTED]
 Sent: Wednesday, June 13, 2001 11:48 AM
 
  Luke Kenneth Casson Leighton wrote:
  
   On Wed, Jun 13, 2001 at 09:57:41AM -0500, William A. Rowe, Jr. wrote:
  
Then let's not start adding things willy nilly.  We have apr_iconv due 
to
portability, let's build upon that.  It should be across character 
sets, so
we can handle this stuff in an opaque manner.
  
   ack.
 
  Great!
 
  By the way I am not 100% happy with apr-iconv, I am thinking of returning 
  status
  instead the actual size_t. Something like:
 
  apr_status_t apr_iconv(iconv_t cd, const char **inbuf, size_t
  *inbytesleft,
  char **outbuf, size_t *outbytesleft, size_t *num_change)
 
  Any comments? - If no one complains before tomorrow I will start doing these
  changes - (Well I have already started).
 
 If we can fail for more that a single reason, then yes, that's an 
 apr_status_t.
 
 Commit away :-)  We ought to start looking at compatibility to apr_xlate.c as 
 well,
 perhaps by tying to one module where we use the iconv package, and to another 
 module
 where we user apr_iconv.  Haven't given that enough thought yet.

I will commit tomorrow - Because what I have is not finished -
I am using apr_set_os_error() and apr_get_os_error() to get the status at the
place I want. That is too ugly to be committed!

Re: apr unicode-16 lib.

[jean-frederic clere]

William A. Rowe, Jr. wrote:
 
 From: Luke Kenneth Casson Leighton [EMAIL PROTECTED]
 Sent: Tuesday, June 12, 2001 10:22 AM
 
  for various reasons i am prompted to ask,
 
  how would the idea of having an apr_ucs16 set of routines,
  apr_wstrcat, apr_wstrcpy, apr_wtolower, apr_wtoupper etc.,
  be received?
 
 Well, since apr_isfoo apr_tofoo was 'reinvented', I don't see a
 huge problem.
 
  on nt, it's easy: straightforward usage of the NT
  wstrcat, wstrcpy etc. lines.
 
 These are the folks who never read the Security Implications of ucs-8
 leaving 40% of all IIS webservers still vulnerable, so I'm dubious :-)
 
  on unix, it's slightly more tricky, but easily doable.
  [and example code exists in samba, anyway:
  they've tried it there, but never yet completed it
  satisfactorily]
 
  iirc, glib has a unicode library, however it is ucs32 not
  ucs16, and depends on glib, which is an N-mbytes install,
  and not what i need, iow.
 
  how about it? :)
 
 Well, how about a simple question.  Why restrain ourselves to ucs2?
 (No such thing as ucs16/32, it's ucs2/4).
 
 Can iconv/apr_iconv provide this in a charset-opaque manner?

Well I have also started to think that apr-iconv could be a place to these
things...
We have there the size information.
The code could be:
apr_iconv_open(shift-jis,shift-jis,ctx);
apr_iconv_wstrcat(out,in);
...


  That is, if
 I want three 'characters' in shift-jis, can it give me the right number
 of bytes?  The reason is simple, Unicode is already splintered into a
 multi-word character set anyways.  I suspect it's easier to just get it
 right, knowing the apr_xlate that's been opened, and asking for the char
 len v.s. the byte len (sizeof) and providing the strcpy/cmp, etc.
 
 Bill

Re: avoiding find (was: Re: [PATCH] First pass at moving util_uri to apr-util...)

[jean-frederic clere]

Greg Stein wrote:
 
 On Mon, May 21, 2001 at 06:45:05PM -0700, Roy T. Fielding wrote:
  On Sun, May 20, 2001 at 06:52:18PM -0700, Greg Stein wrote:
   Since gen_uri_delims.lo is not destined for a library (.la), then it
   can/should simply use the .o suffix. That will also prevent the object 
   from
   appearing within libaprutil.la.
 
  I committed it with the .o suffix, but that auto-slurping of object files
  into the library is bogus.  Among other things, it assumes that a developer
  isn't doing any of their own work within the library.
 
  I would like to replace the find with an actual list of library objects.
  There aren't that many, and it isn't a hardship to require that people add
  names to Makefile.in when a new component is added to the library.
 
 Sure, whatever. I used the find to avoid having to list every darn file.
 That gets really difficult in APR itself (APRUTIL shouldn't be a problem)
 because the .o file used varies. Is it dso/aix/dso.lo or dso/unix/dso.lo ?
 
 APR used to record which directories were being built, copy all the .o files
 from those directories into an objs directory, then archive everything in
 that directory. That isn't much better than a find :-) (and arguably worse
 because of the copy; timestamp issues meant that APR would *always* rebuild
 the library)
 
 One idea might be to simply toss the whole recursive make thang. That would
 put the list of target objects into a single Makefile. APR's ./configure
 script would adjust the set of target objects as necessary. (although that
 gets a bit tricky because then you end up encoding the set of objects
 (destined for Makefile) within configure.in)

What about the idea:
Each Makefile has a list of objects it want to put in the library (TARGETS).
Would it be possible to archive these in an archive file (lib.a) and build our
library using this archive?
An archive file has a timestamp for each file so we could prevent the rebuild of
the library.

 
 Ah well. Go for it for APRUTIL. I think APR will be more difficult because
 of its variability.
 
 Cheers,
 -g
 
 --
 Greg Stein, http://www.lyra.org/

Re: tomcat4 / apache 1.3.x integration problem

[jean-frederic clere]

Markus Mailinglists wrote:
 
 Hello!
 Like some others I have a problem with connecting the tomcat 4 (beta 4 or 5) 
 with the apache 1.3.19.
 The computer is a solaris 8 (sparc) system with jdk1.3 and a gcc compiler
 I could successfully compile a mod_webapp.so file.
 Although after copying it to the apache/libexec folder and running apachectl 
 configtest  I get the error:
 libapr.so.0: symbol __eprintf: referenced symbol not found
 
 Can anyone help me with this error message?

Probably some flags missing, have a look in APRVARS... I have EXTRA_CFLAGS=-g
-mt but I am not using the gcc.
 
 
 For compiling the mod_webapp.so I had to compile the apr package from 
 apache.
 My guess is, that I don't have the matching version of it.
 On http://apr.apache.org/ I just go tthe latest snapshot 
 apr_20010523060225.tar.gz
 Is this a good one? Is there somewhere a ready distribution tar? And which 
 one works with tomcat4.
 
 Any help is appreciated,
 Markus Albrecht
 
 Email: [EMAIL PROTECTED]

Re: cvs commit: apr-iconv/lib iconv_module.c

[jean-frederic clere]

William A. Rowe, Jr. wrote:
 
 See apr/include/apr_errno.h for the appropriate templates, just follow right
 along :-)  EFTYPE would be appropriate all over, say if a loaded module 
 doesn't
 have the appropriate entry point or data export to be an apache module, etc.

Ok, I will add APR_EFTYPE to APR. and arrange apr_iconv

The patch for apr/include/apr_errno.h could be the one proposed in attachement.
Please check it.
 

 
 Bill
 
 - Original Message -
 From: jean-frederic clere [EMAIL PROTECTED]
 To: William A. Rowe, Jr. [EMAIL PROTECTED]
 Cc: dev@apr.apache.org
 Sent: Tuesday, May 22, 2001 4:18 AM
 Subject: Re: cvs commit: apr-iconv/lib iconv_module.c
 
  William A. Rowe, Jr. wrote:
  
jfclere 01/05/22 00:40:31
   
  Modified:lib  iconv_module.c
  Log:
  Change EFTYPE into APR_ICONV_EFTYPE (EFTYPE is used by FreeBSD).
   
  - return EFTYPE;
  + return APR_ICONV_EFTYPE;
  
   Guys, in case we missed the point from the earlier conversion, we have to
   quit inventing 'custom specific error codes' when plain old obvious codes
   can be assigned!!!  If that means APR_EFTYPE, then fine, but please, lets
   not get too specific!
 
  Apr-iconv logic was using EFTYPE to tell that the converter needs another
  converter.
  In FreeBSD I have found:
  #define EFTYPE  79  /* Inappropriate file type or 
  format */
 
  What should I do? Add APR_EFTYPE to APR, but the modules that uses it is an
  internal module of apr-iconv.
 
  
   Bill
 Index: apr/include/apr_errno.h
===
RCS file: /home/cvs/apache/apr/include/apr_errno.h,v
retrieving revision 1.64
diff -u -r1.64 apr_errno.h
--- apr/include/apr_errno.h 2001/05/19 22:47:28 1.64
+++ apr/include/apr_errno.h 2001/05/22 10:54:04
@@ -471,6 +471,12 @@
 #define APR_ENETUNREACH(APR_OS_START_CANONERR + 22)
 #endif
 
+#ifdef EFTYPE
+#define APR_EFTYPE
+#else
+#define APR_EFTYPE(APR_OS_START_CANONERR + 23)
+#endif
+
 
 #if defined(OS2)
 
@@ -582,6 +588,7 @@
 || (s) == APR_OS_START_SYSERR + SOCEHOSTUNREACH)
 #define APR_STATUS_IS_ENETUNREACH(s)((s) == APR_ENETUNREACH \
 || (s) == APR_OS_START_SYSERR + SOCENETUNREACH)
+#define APR_STATUS_IS_EFTYPE(s) (s) == APR_EFTYPE)
 
 /*
 Sorry, too tired to wrap this up for OS2... feel free to
@@ -741,6 +748,7 @@
 #define APR_STATUS_IS_ETIMEDOUT(s)   ((s) == APR_ETIMEDOUT)
 #define APR_STATUS_IS_EHOSTUNREACH(s)((s) == APR_EHOSTUNREACH)
 #define APR_STATUS_IS_ENETUNREACH(s) ((s) == APR_ENETUNREACH)
+#define APR_STATUS_IS_EFTYPE(s)  ((s) == APR_EFTYPE)
 
 #endif /* !def OS2 || WIN32 */
 

Re: Problems with APR under Linux...

[jean-frederic clere]

Greg Stein wrote:
 
 On Sat, May 19, 2001 at 01:05:17AM +0100, Pier P. Fumagalli wrote:
  Pier P. Fumagalli at [EMAIL PROTECTED] wrote:
 
   jean-frederic clere at [EMAIL PROTECTED] wrote:
  
   Pier P. Fumagalli wrote:
  
   I'm a dork, I sent it only to Bill without including the mailing list...
   Damn lack of a Reply-To header :) :)
  
   Pier
  
   [EMAIL PROTECTED] bin]$ ./httpd
   Syntax error on line 957 of /usr/local/apache/conf/httpd.conf:
   Cannot load /usr/local/apache/libexec/mod_webapp.so into server:
   /usr/local/apache/libexec/mod_webapp.so: undefined symbol: 
   pthread_sigmask
   [EMAIL PROTECTED] bin]$
  
   That's weird... Do anyone knows where this one could come from? It seems
   that pthread_sigmask is not found when talking about Linux, but that 
   seems
   really strange, since I don't use any threading function per se in 
   WebApp...
   (Might be called from apr_initialize?)
  
   I have no found exactly what happends but just add -lpthread in the
   (tomcat-connectors)/Makefile solves the problem:
  
   Ok, will add that into our autoconf/automake stuff. :) Thanks for the
   hint...
  
 Pier
 
  Jean-Federic  told me that the trick works for Linux, but not for other
  systems such as Reliant Unix... Is there a way to find out on which
  libraries APR relies on?
 
 Right. Adding -lpthread manually is absolutely the wrong thing for your app
 to do. That was poor advice.
 
 APR generates a shell script called APRVARS. That should have everything
 that you need for compiling your app, and for linking your app to APR and
 its dependent libraries.
 
 Note: it is best to compile your app with the flags from APRVARS so that you
 don't get skewed compile options between APR and your app. Yes, there are
 well-defined binary interfaces, but heck: APR figured it all out for you, so
 go ahead and use it :-)

Just a question, is there a HOW about How to use APR.

 
 Cheers,
 -g
 
 --
 Greg Stein, http://www.lyra.org/

Re: apr_memory_system.c;apr_memory_system.h

[jean-frederic clere]

Hi,

I am little confused... But these nice things have nothing to do with shared
memory, don't they?
So the locking issue is for threads.

Cheers

Jean-frederic

Sander Striker wrote:
 
 Ok, included are the latest memory system sources.
 
 Take a look at apr_tracking_memory_system.[ch] for
 an example on how to implement a memory system.
 
 The tracking memory system is a really trivial
 one that does somewhat the thing that apr pool
 does, only less efficient. It is provided as a
 guide, but could ofcourse be used.
 
 Ok, I didn't write a test program because I think
 you guys could do that easily yourselves. The
 documentation in the code should be clear enough,
 but there are a few issues that Luke would like to
 add (regarding locking). Luke, please state them
 here and I'm sure someone will copy them over in
 the final source.
 
 Usage example (lacks error checking):
 
   ...
   apr_memory_system_t *sms;
   ...
   apr_standard_memory_system_create(sms);
   ...
 
   ...
   void *mem;
 
   mem = apr_memory_system_malloc(sms, 100);
   ...
   [ do something with the memory ]
   ...
   apr_memory_system_free(sms, mem);
   ...
 
   ...
   apr_memory_system_t *tms;
   ...
   apr_tracking_memory_system_create(tms, sms);
   ...
 
   for (int n = 0; n  100; n++)
   {
 mem = apr_memory_system_malloc(tms, 100);
 
 [ do something with the memory ]
   }
 
   /* done with all the memory in tms,
* no free'ing needed since its tracking.
*/
   apr_memory_system_destroy(tms);
 
   [ do more alloc/free stuff with sms ]
 
   /* make sure everything is free'd first,
* since the standard memory system doesn't do tracking
*/
   apr_memory_system_destroy(sms);
 
 Hope this is clear enough, if not, ask me.
 
 Oh, ofcourse this again shows that function names and possibly
 type names are way too long. This was just done for clarity,
 not for convenience. I'd suggest shortening them.
 
 Sander
 
   
 
   Name: apr_memory_system.c
apr_memory_system.cType: unspecified type (application/octet-stream)
   Encoding: quoted-printable
 
   Name: apr_memory_system.h
apr_memory_system.hType: unspecified type (application/octet-stream)
   Encoding: quoted-printable
 
   Name: apr_stuff.h
apr_stuff.hType: unspecified type (application/octet-stream)
   Encoding: quoted-printable
 
Name: apr_tracking_memory_system.c
apr_tracking_memory_system.cType: unspecified type 
 (application/octet-stream)
Encoding: quoted-printable
 
Name: apr_tracking_memory_system.h
apr_tracking_memory_system.hType: unspecified type 
 (application/octet-stream)
Encoding: quoted-printable

Re: apr_memory_system.c;apr_memory_system.h

[jean-frederic clere]

Luke Kenneth Casson Leighton wrote:
 
 On Tue, May 08, 2001 at 12:32:04PM +0200, jean-frederic clere wrote:
  Hi,
 
  I am little confused... But these nice things have nothing to do with shared
  memory, don't they?
  So the locking issue is for threads.
 
 not quite just for threads.
 
 take this:
 
 shmem_pool = apr_pool_from_sms_init(shmem_sms);
 some_memory = ap_pool_alloc(shmem_pool, some_size);

Or something like:
apr_pool_create_shared(shmem_pool, NULL, myglobalkey);
some_memory = apr_palloc(shmem_pool, some_size);

 
 ... then, you pass the address and size of that memory
 over to some other process [not a thread] and start
 accessing it.

I think you have to pass the key myglobalkey and the size. If you want to get
the same memory area, a offset from the start of the memory is needed.

 
 ... or, better, you get the two processes to set up
 their variable, shmem_pool, as the same, and to return
 some_memory to access the same shared memory [not entirely
 happy with concept of overloading the ap_pool semantics
 to do this, ah well].

Ok, it means same key.

 
 between the two processes, you will need locking on
 the shared memory. (handled by the shmem_sms instance).

Like mm_lock() mm_unlock().

 
 that's nothing to do with threads.
 
 the allocation / management of blocks of shared memory
 requires shared memory to globally store a linked list
 etc. of the shared memory blocks, such that other
 shared-mem-memsys instances can access / manage it /
 provide access to the same shared memory blocks / pools.
 
 nothing to do with threads, although the techniques
 required to manage ordinary memory between threads are
 similar to those required to manage shared memory
 between processes.
 
 the complications are caused by the fact that any
 pointers stored in the shmem block have to be relative to
 the start of the shmem block, not to the memory they
 are mapped into.  [but this is standard procedure: i'm
 telling you nothing new, here].
 

Yes.

 luke

Re: cvs commit: apr/build apr_common.m4 apr_hints.m4 apr_network.m4 rules.mk.in

[jean-frederic clere]

[EMAIL PROTECTED] wrote:
[cut]
   1.4   +4 -3  apr/build/rules.mk.in
 
   Index: rules.mk.in
   ===
   RCS file: /home/cvs/apr/build/rules.mk.in,v
   retrieving revision 1.3
   retrieving revision 1.4
   diff -u -r1.3 -r1.4
   --- rules.mk.in   2001/03/07 22:09:16 1.3
   +++ rules.mk.in   2001/04/03 00:02:02 1.4
   @@ -68,8 +68,9 @@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
 
   [EMAIL PROTECTED]@ @OPTIM@
   [EMAIL PROTECTED]@ $(INCLUDES)
   [EMAIL PROTECTED]@
   [EMAIL PROTECTED]@
   [EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
 
   @@ -82,7 +83,7 @@
#
# Basic macro setup
#
   -COMPILE  = $(CC) $(CPPFLAGS) $(CFLAGS)
   +COMPILE  = $(CC) $(CPPFLAGS) $(CFLAGS) $(OPTIM) $(INCLUDES)
LT_COMPILE   = $(LIBTOOL) --mode=compile $(LTFLAGS) $(COMPILE) -c $  
 touch $@
 
LINK = $(LIBTOOL) --mode=link $(LTFLAGS) $(COMPILE) $(LDFLAGS) -o 
 $@
 
 

Hi,
 
This brokes configure when using CFLAGS=-I/usr/local/include and when
/usr/local/include contains a file that have the name of an APR include (In my
case mm.h and it is a old version of our mm.h).
I will change the order of the flags in COMPILE.

Cheers

Jean-frederic

libtool in apr/shmem/unix/mm

[jean-frederic clere]

Hi,

I have detected that the libtool files are in the cvs of apr/shmem/unix/mm...
config.guess, config.sub, libtool ...
That an old version of libtool (1.3.4).

I think that apr/shmem/unix/mm should work like the rest of apr: buildconf
should create the needed tools.

Cheers

Jean-frederic

Re: builconf APR and httpd2.0

[jean-frederic clere]

Means today...

I have retested it. It was not 100% OK, the shlibtool is not created, I
have probably missed a cp.

Find enclosed new patch :=(

Cheers

Jean-frederic

[EMAIL PROTECTED] wrote:
 
 I'll try to get this applied and committed today.  If I don't get to it
 until tomorrow, don't worry, it's on my short list.
 
 Ryan
 
 On Thu, 15 Mar 2001, jean-frederic clere wrote:
 
  Hi Ryan,
 
  I have fixed it - It works on my Linux Box -
 
  Find enclosed the patch for httpd-2.0
 
  Cheers
 
  Jean-frederic
 
  [EMAIL PROTECTED] wrote:
  
   This is most definately a bug.  APR should have a copy of the libtool
   files, and ANY APR application should just use those files.  There is no
   reason for httpd-2.0 to create links anyplace, it should just use APR's
   version.
  
   Ryan
  
   On Wed, 14 Mar 2001, jean-frederic clere wrote:
  
Hi,
   
I have noted that buildconf of httpd2.0 creates links for the libtool
needed elements and the APR one copies them in the build subdirectory:
+++
$ ls -lt
srclib/apr/build/ltconfig
-rwxr-xr-x   1 VTX3 Spain  97913 Mar 14 16:26
srclib/apr/build/ltconfig
$ ls -l
ltconfig
lrwxrwxrwx   1 VTX3 Spain 33 Mar 14 16:33 ltconfig -
/usr/local/share/libtool/ltconfig
$
+++
   
Is this a bug or a Feature?
   
Cheers
   
Jean-frederic
   
   
  
   ___
   Ryan Bloom  [EMAIL PROTECTED]
   406 29th St.
   San Francisco, CA 94131
   ---
 
 ___
 Ryan Bloom  [EMAIL PROTECTED]
 406 29th St.
 San Francisco, CA 94131
 ---Index: configure.in
===
RCS file: /home/cvs/apache/httpd-2.0/configure.in,v
retrieving revision 1.130
diff -u -r1.130 configure.in
--- configure.in2001/03/11 23:40:47 1.130
+++ configure.in2001/03/15 16:21:03
@@ -4,7 +4,7 @@
 AC_INIT(acinclude.m4)
 
 AC_CONFIG_HEADER(include/ap_config_auto.h)
-AC_CONFIG_AUX_DIR(.)
+AC_CONFIG_AUX_DIR(srclib/apr/build)
  
 dnl ## This is the central place where Apache's version should be kept.
 dnl AM_INIT_AUTOMAKE(apache, 2.0-dev)
@@ -20,6 +20,7 @@
 dnl Absolute source/build directory
 abs_srcdir=`(cd $srcdir  pwd)`
 abs_builddir=`pwd`
+aprbuild=$abs_srcdir/srclib/apr/build
 
 MKDIR=$abs_srcdir/srclib/apr/build/mkdir.sh
 
@@ -155,7 +156,7 @@
 APACHE_LIBTOOL_SILENT
 
 if test $apache_need_shared = yes; then
-  $SHELL $srcdir/ltconfig --output=shlibtool --disable-static --srcdir=$srcdir 
--cache-file=./config.cache $srcdir/ltmain.sh
+  $SHELL $aprbuild/ltconfig --output=shlibtool --disable-static 
--srcdir=$aprbuild --cache-file=./config.cache $aprbuild/ltmain.sh
   case $PLATFORM in
 *os390)
   CFLAGS=$CFLAGS -Wc,DLL,EXPORTALL
Index: build/build2.mk
===
RCS file: /home/cvs/apache/httpd-2.0/build/build2.mk,v
retrieving revision 1.30
diff -u -r1.30 build2.mk
--- build/build2.mk 2001/02/27 01:39:25 1.30
+++ build/build2.mk 2001/03/15 16:21:03
@@ -58,15 +58,13 @@
 
 TOUCH_FILES = mkinstalldirs install-sh missing
 
-LT_TARGETS = ltconfig ltmain.sh config.guess config.sub
-
 config_h_in = include/ap_config_auto.h.in
 apr_configure = srclib/apr/configure
 mm_configure = srclib/apr/shmem/unix/mm/configure
 pcre_configure = srclib/pcre/configure
 aprutil_configure = srclib/apr-util/configure
 
-APACHE_TARGETS = $(TOUCH_FILES) $(LT_TARGETS) configure $(config_h_in)
+APACHE_TARGETS = $(TOUCH_FILES) configure $(config_h_in)
 
 APR_TARGETS = $(apr_configure) $(mm_configure) $(aprutil_configure)
 
@@ -88,9 +86,6 @@
@echo dnl THIS FILE IS AUTOMATICALLY GENERATED BY buildconf $@
@echo dnl edits here will be lost $@
@cat acinclude.m4 $(libtool_m4)  $@
-
-$(LT_TARGETS):
-   libtoolize $(AMFLAGS) --force
 
 $(config_h_in): configure
 # explicitly remove target since autoheader does not seem to work 
Index: build/rules.mk
===
RCS file: /home/cvs/apache/httpd-2.0/build/rules.mk,v
retrieving revision 1.43
diff -u -r1.43 rules.mk
--- build/rules.mk  2001/02/26 04:38:18 1.43
+++ build/rules.mk  2001/03/15 16:21:03
@@ -188,7 +188,7 @@
rm -rf .libs
 
 distclean: distclean-recursive clean-x
-   rm -f config.cache config.log config.status config_vars.mk libtool \
+   rm -f config.cache config.log config.status config_vars.mk \
stamp-h Makefile shlibtool .deps $(DISTCLEAN_TARGETS)
 
 include $(builddir)/.deps

Re: builconf APR and httpd2.0

[jean-frederic clere]

Hi Ryan,

I have fixed it - It works on my Linux Box -

Find enclosed the patch for httpd-2.0

Cheers

Jean-frederic

[EMAIL PROTECTED] wrote:
 
 This is most definately a bug.  APR should have a copy of the libtool
 files, and ANY APR application should just use those files.  There is no
 reason for httpd-2.0 to create links anyplace, it should just use APR's
 version.
 
 Ryan
 
 On Wed, 14 Mar 2001, jean-frederic clere wrote:
 
  Hi,
 
  I have noted that buildconf of httpd2.0 creates links for the libtool
  needed elements and the APR one copies them in the build subdirectory:
  +++
  $ ls -lt
  srclib/apr/build/ltconfig
  -rwxr-xr-x   1 VTX3 Spain  97913 Mar 14 16:26
  srclib/apr/build/ltconfig
  $ ls -l
  ltconfig
  lrwxrwxrwx   1 VTX3 Spain 33 Mar 14 16:33 ltconfig -
  /usr/local/share/libtool/ltconfig
  $
  +++
 
  Is this a bug or a Feature?
 
  Cheers
 
  Jean-frederic
 
 
 
 ___
 Ryan Bloom  [EMAIL PROTECTED]
 406 29th St.
 San Francisco, CA 94131
 ---Index: configure.in
===
RCS file: /home/cvs/apache/httpd-2.0/configure.in,v
retrieving revision 1.130
diff -u -r1.130 configure.in
--- configure.in2001/03/11 23:40:47 1.130
+++ configure.in2001/03/15 16:21:03
@@ -4,7 +4,7 @@
 AC_INIT(acinclude.m4)
 
 AC_CONFIG_HEADER(include/ap_config_auto.h)
-AC_CONFIG_AUX_DIR(.)
+AC_CONFIG_AUX_DIR(srclib/apr/build)
  
 dnl ## This is the central place where Apache's version should be kept.
 dnl AM_INIT_AUTOMAKE(apache, 2.0-dev)
@@ -20,6 +20,7 @@
 dnl Absolute source/build directory
 abs_srcdir=`(cd $srcdir  pwd)`
 abs_builddir=`pwd`
+aprbuild=$abs_srcdir/srclib/apr/build
 
 MKDIR=$abs_srcdir/srclib/apr/build/mkdir.sh
 
@@ -155,7 +156,7 @@
 APACHE_LIBTOOL_SILENT
 
 if test $apache_need_shared = yes; then
-  $SHELL $srcdir/ltconfig --output=shlibtool --disable-static --srcdir=$srcdir 
--cache-file=./config.cache $srcdir/ltmain.sh
+  $SHELL $aprbuild/ltconfig --output=shlibtool --disable-static 
--srcdir=$srcdir --cache-file=./config.cache $aprbuild/ltmain.sh
   case $PLATFORM in
 *os390)
   CFLAGS=$CFLAGS -Wc,DLL,EXPORTALL
Index: build/build2.mk
===
RCS file: /home/cvs/apache/httpd-2.0/build/build2.mk,v
retrieving revision 1.30
diff -u -r1.30 build2.mk
--- build/build2.mk 2001/02/27 01:39:25 1.30
+++ build/build2.mk 2001/03/15 16:21:03
@@ -58,15 +58,13 @@
 
 TOUCH_FILES = mkinstalldirs install-sh missing
 
-LT_TARGETS = ltconfig ltmain.sh config.guess config.sub
-
 config_h_in = include/ap_config_auto.h.in
 apr_configure = srclib/apr/configure
 mm_configure = srclib/apr/shmem/unix/mm/configure
 pcre_configure = srclib/pcre/configure
 aprutil_configure = srclib/apr-util/configure
 
-APACHE_TARGETS = $(TOUCH_FILES) $(LT_TARGETS) configure $(config_h_in)
+APACHE_TARGETS = $(TOUCH_FILES) configure $(config_h_in)
 
 APR_TARGETS = $(apr_configure) $(mm_configure) $(aprutil_configure)
 
@@ -88,9 +86,6 @@
@echo dnl THIS FILE IS AUTOMATICALLY GENERATED BY buildconf $@
@echo dnl edits here will be lost $@
@cat acinclude.m4 $(libtool_m4)  $@
-
-$(LT_TARGETS):
-   libtoolize $(AMFLAGS) --force
 
 $(config_h_in): configure
 # explicitly remove target since autoheader does not seem to work 
Index: build/rules.mk
===
RCS file: /home/cvs/apache/httpd-2.0/build/rules.mk,v
retrieving revision 1.43
diff -u -r1.43 rules.mk
--- build/rules.mk  2001/02/26 04:38:18 1.43
+++ build/rules.mk  2001/03/15 16:21:03
@@ -188,7 +188,7 @@
rm -rf .libs
 
 distclean: distclean-recursive clean-x
-   rm -f config.cache config.log config.status config_vars.mk libtool \
+   rm -f config.cache config.log config.status config_vars.mk \
stamp-h Makefile shlibtool .deps $(DISTCLEAN_TARGETS)
 
 include $(builddir)/.deps

builconf APR and httpd2.0

[jean-frederic clere]

Hi,

I have noted that buildconf of httpd2.0 creates links for the libtool
needed elements and the APR one copies them in the build subdirectory:
+++
$ ls -lt
srclib/apr/build/ltconfig  
-rwxr-xr-x   1 VTX3 Spain  97913 Mar 14 16:26
srclib/apr/build/ltconfig 
$ ls -l
ltconfig
lrwxrwxrwx   1 VTX3 Spain 33 Mar 14 16:33 ltconfig -
/usr/local/share/libtool/ltconfig   
  
$ 
+++

Is this a bug or a Feature?

Cheers

Jean-frederic

Problem with apr-util/xml/expat

[jean-frederic clere]

Hi,

I have some problems with the Makefile on apr-util/xml/expat.
The option  -Wp,-MD,.deps/$(*F).pp is no understand neither on Solaris
nor on ReliantUnix.
On Solaris the fix is to use:
+++
  $(LTCOMPILE) -xM $  .deps/$(*F).pp;
\   
  $(LTCOMPILE) -c
$
+++
Instead of 
$(LTCOMPILE) -Wp,-MD,.deps/$(*F).pp -c
$   
On ReliantUnix the -xM option is -M, so I have:
+++
  $(LTCOMPILE) -M $  .deps/$(*F).pp;
\   
  $(LTCOMPILE) -c
$
+++
I am afraid we need a way to find how -Wp,-MD, option should be
processed.

Cheers

Jean-frederic