Re: Cross-compilation failure due to gen_test_char
Hi Arsen, On 20.11.2013 23:36, Arsen Chaloyan wrote: My understanding is the tool needs to be compiled natively no matter what the target platform is. correct - are you up to provide a patch to the configure script? we need to do something with vars like CC_FOR_BUILD etc. - but unfortunately I'm not so fluent with configure scripts ;-) BTW. we need same also for httpd - and I did at some time a new hack to configure which I wanted to discuss - but I cant find ATM ... greets, Günter.
Re: Which of y'all are working on un-APR-izing gen_test_char, and how will the rest of us know if it is stalled and needs help?
Hi, On 05.11.2013 22:51, Graham Leggett wrote: On 05 Nov 2013, at 11:04 PM, Jeff Trawick wrote: TIA! (ping) If nobody in the gen_test_char-with-traditional-Windows-build sub-thread knows what I'm talking about, please let me know. Maybe I am confusedabout the planned work. (Am on holiday and travelling, so have limited time, but this was reasonably straightforward) This patch removes the APR specific stuff (and therefore the chicken-and-egg problem) and Works for Me(™) on MacOSX 10.8. Is this good enough to work on Windows and other platforms (Linux, etc)? I would prefer to keep the unsigned char casts ... Gün.
Re: Timetable for APR 1.5 release?
On 29.10.2013 18:56, William A. Rowe Jr. wrote: Nope - simply /DCROSS_COMPILE in the [lib]apr.dsp/.mak files rather than pre-copying apr.h. I don't think that using apr feature detection and headers buys us anything in compiling code which should 'just work' on any compiler still in use in this century :) I suggested this already longer time ago for httpd as well - but only Stefan agreed so far ... as you seem to agree now as well we're 3 and I think we should push a change which removes APR dependency entirely from gen_test_char.c for all httpd + APR brances and make the code more simple. Gün.
APR/APU docs redirect to 0.9.x
Hi, I just found that from: http://apr.apache.org/docs/ if you click 'apr' or 'apr-util' these will redirect to the 0.9 docu ... shouldnt we redirect to recent APR 1.4 / APU 1.5 ? I think this is important since when I google for a function I always get there ... Gün.
Re: build-outputs.mk and generated headers
Hi Bert, On 03.06.2013 16:10, Bert Huijben wrote: +1 this is a problem with cross compiling. Spend a few hours multiple times to get an x64 build working on a Win32only the problem is that usally gen_test_char.c includes the APR/APU headers for no real reason, an thwn will fail because target = x64 while build where gen_test_char.exe should run is x86; but you can try: cl -DCROSS_COMPILE get_test_char.c this should enable to build a gen_test_char.exe for the build platform without APR/APU headers but just those from PSDK, and then you can create the test_char.h manually, or probably it works if you put the exe into the source tree (and hopefully it will not be rebuild); or it may work too if you add the -DCROSS_COMPILE to the gen_test_char.dsp ... Gün.
Re: build-outputs.mk and generated headers
Hi Graham, On 31.05.2013 23:34, Graham Leggett wrote: I have been putting together an apr_escape API based on the escaping and unescaping functions in httpd's util.c. So far so good. This code depends on the generation of a file called test_char.h, which is generated at build time by a small bit of code called gen_test_char.c. Httpd handles this bit fine, I need to reproduce this in the APR build. I really dont like this; this gen_test_char.c thingy is one of the problems we have with cross-compiling, and from my view it is not needed. If you look at the source of gen_test_char.c you can see that it usually includes the APR/APU headers only for getting some defines which are in ctype.h of each and every platform - so if we dont have these defines there, or no ctype.h at all for a platform, we simply can not support this platform. Then gen_test_char.c is kinda matured, and has not received any significant updates, so the output of gen_test_char was probably identical over the past 10+ years (ok, I've not actually checked the svn logs, so I might be wrong). I believe we could just check in the result test_char.h into svn, and if we ever have to change it we can re-generate it with gen_test_char and update in svn; we do similar with the regex headers in httpd which also were a bit problematic because of different flex versions, and I think this works fine. These are just my thoughts to tis topic - not a veto or such. Gün.
Re: 1.4.next next weekend or so?
On 26.04.2013 21:18, Jeff Trawick wrote: I can RM... coool! I was recently on hunting an old NetWare-only with apr_pool_parent_get() bug with Rainer, and he finally suggested a patch like this: Index: dbd/apr_dbd.c === --- dbd/apr_dbd.c (revision 1463267) +++ dbd/apr_dbd.c (working copy) @@ -102,8 +102,10 @@ } /* Top level pool scope, need process-scope lifetime */ -for (parent = pool; parent; parent = apr_pool_parent_get(pool)) - pool = parent; +for (parent = apr_pool_parent_get(pool); +parent && parent != pool; +parent = apr_pool_parent_get(pool)) + pool = parent; #if APU_DSO_BUILD /* deprecate in 2.0 - permit implicit initialization */ apu_dso_init(pool); Index: dbm/apr_dbm.c I verified that this fixes the NetWare crash while we believe that this shouldnt make a difference for all other platforms ... the same loop construct appears in 3 more files, where in apu_dso.c it looks slightly different ... I really would like to get these patches in before release since without I cant load mod_lua anymore due its dep to apr_dbd ... if nobody objects I would like to commit the below: Index: crypto/apr_crypto.c === --- crypto/apr_crypto.c (revision 1463267) +++ crypto/apr_crypto.c (working copy) @@ -100,7 +100,9 @@ } /* Top level pool scope, need process-scope lifetime */ -for (parent = pool; parent; parent = apr_pool_parent_get(pool)) +for (parent = apr_pool_parent_get(pool); + parent && parent != pool; + parent = apr_pool_parent_get(pool)) pool = parent; #if APU_DSO_BUILD /* deprecate in 2.0 - permit implicit initialization */ Index: dbd/apr_dbd.c === --- dbd/apr_dbd.c (revision 1463267) +++ dbd/apr_dbd.c (working copy) @@ -102,8 +102,10 @@ } /* Top level pool scope, need process-scope lifetime */ -for (parent = pool; parent; parent = apr_pool_parent_get(pool)) - pool = parent; +for (parent = apr_pool_parent_get(pool); +parent && parent != pool; +parent = apr_pool_parent_get(pool)) + pool = parent; #if APU_DSO_BUILD /* deprecate in 2.0 - permit implicit initialization */ apu_dso_init(pool); Index: dbm/apr_dbm.c === --- dbm/apr_dbm.c (revision 1463267) +++ dbm/apr_dbm.c (working copy) @@ -129,8 +129,10 @@ apr_pool_t *parent; /* Top level pool scope, need process-scope lifetime */ -for (parent = pool; parent; parent = apr_pool_parent_get(pool)) - pool = parent; +for (parent = apr_pool_parent_get(pool); + parent && parent != pool; + parent = apr_pool_parent_get(pool)) +pool = parent; /* deprecate in 2.0 - permit implicit initialization */ apu_dso_init(pool); for the last one in apu_dso.c I need to do some further testing 1st ... Gün.
time for APU 1.5.2?
Hi all, since the APU 1.5.1 apr_password_validate() bug is now fixed (thanks Rainer!), and our main site http://apr.apache.org/ still lists: The recommended releases of the several Apache Portable Runtime libraries are * APR 1.4.6, released Feb 14, 2012 * APR-util 1.5.1, released October 5, 2012 * APR-iconv 1.2.1, released November 26, 2007 I believe we shoud soon put another release APU 1.5.2 out ... would be great if we would couple it also with another APU 1.4.7 release ... anybody with the right resources (Linux autofoo) willing to RM? Gün.
Re: make check issues with AIX - willing to help but will need assistance to be efficient
Am 20.09.2012 18:52, schrieb Michael Felt: On the dev (x104) system, running as root - testbuckets succeeds; rerunning on x054, as root, testbuckets also succeeds. great! So, only testxlate is (still) standing in the way. IIRC this test needs some data files - any chance you missed to copy them over to the machine where you tested? Gün.
Re: which apr-util is really "desired" for the 2.2.X branch
Hi Michael, Am 20.09.2012 17:48, schrieb Michael Felt: this was about what to use with httpd today. And you answered that, if I understood correctly - package both httpd 2.2.X and httpd 2.4.X with apr-1.4.6 and apr-util-1.4.1 - because these "exist" officially. yep - though with 2.2.x you dont have to care at all since it ships with already with "desired" APR / APU (see below ./srclib); and even more nice is you can just call configure with --with-included-apr to use them ;-) for 2.4.x we did in the past provide httpd-2.4.x-deps tarballs which contain APR / APU, see: http://www.apache.org/dist/httpd/ Gün.
Re: make check issues with AIX - willing to help but will need assistance to be efficient
Hi Michael, Am 20.09.2012 10:34, schrieb Guenter Knauf: Am 20.09.2012 08:53, schrieb Michael Felt: Yes, unfortunately? or fortunately! hehe, I would say fortunately since that makes it no regression and therefore your issue might not be something to hold back 1.5.1 ;-) of course this doesnt mean that we shouldnt look into it; BTW. this test fails on NetWare too, so seems its a bit picky, whatever ... best is that you exclude this test for now so that you can proceed with testing in order to see what else fails; testdbd did also fail, or? then try: aputest -x testdbd -x testxlate Gün.
Re: make check issues with AIX - willing to help but will need assistance to be efficient
Am 20.09.2012 08:53, schrieb Michael Felt: Yes, unfortunately? or fortunately! hehe, I would say fortunately since that makes it no regression and therefore your issue might not be something to hold back 1.5.1 ;-) Gün.
Re: make check issues with AIX - willing to help but will need assistance to be efficient
Hi Michael, Am 16.09.2012 16:34, schrieb Michael Felt: make check of apr-util-1.5.1 returns: ... testdate: SUCCESS testmemcache: SUCCESS testxml : SUCCESS testxlate : |/bin/sh[17]: 10879096 Segmentation fault(coredump) Programs failed: testall make[1]: *** [check] Error 139 make[1]: Leaving directory `/data/prj/apr/apr-util-1.5.1/test' make: *** [check] Error 2 root@x104:[/data/prj/apr/apr-util-1.5.1] now what would be of interest is if apr-util-1.4.1 fails in the same way since testxlate is nothing new ... Gün.
Re: Incorrect value of APR_HAS_LARGE_FILES on win32
Hi,
Am 28.04.2012 16:25, schrieb Olivier Teuliere:
When cross-compiling a program for win32 (on linux, using mingw32),
the linking with apr-2 (svn version as of today) failed with the
following error:
/some/path/lib/libapr-2.a(apr_strings.o): In function `apr_strtoff@16':
/some/other/path/apr/strings/apr_strings.c:240: undefined reference to `_strtoi'
The error is very similar to the one in this old thread, which was
apparently never solved:
http://comments.gmane.org/gmane.comp.apache.apr.devel/12331
The macro APR_OFF_T_STRFN is defined like this for win32:
#if APR_HAS_LARGE_FILES
#ifdef APR_INT64_STRFN
#define APR_OFF_T_STRFN APR_INT64_STRFN
#else
#define APR_OFF_T_STRFN apr_strtoi64
#endif
#else
#if defined(_WIN32_WCE)
#define APR_OFF_T_STRFN strtol
#else
#define APR_OFF_T_STRFN strtoi
#endif
#endif
APR_HAS_LARGE_FILES is set to 0, so the last define is used and
APR_OFF_T_STRFN is defined to strtoi.
If I understand correctly, APR_HAS_LARGE_FILES should be set to 1
instead. This variable is set in include/apr.h, itself generated from
include/apr.h.in, using the autoconf variable aprlfs.
The following lines in configure.in (starting at line 1690) define aprlfs:
APR_CHECK_SIZEOF_EXTENDED([#include], off_t, 8)
if test "${ac_cv_sizeof_off_t}${apr_cv_use_lfs64}" = "4yes"; then
# Enable LFS
aprlfs=1
AC_CHECK_FUNCS([mmap64 sendfile64 sendfilev64 mkstemp64 readdir64_r])
elif test "${ac_cv_sizeof_off_t}" != "${ac_cv_sizeof_size_t}"; then
# unsure of using -gt above is as portable, can can't forsee where
# off_t can legitimately be smaller than size_t
aprlfs=1
else
aprlfs=0
fi
Here are the relevant values in my case:
ac_cv_sizeof_off_t = 8
ac_cv_sizeof_size_t = 8
apr_cv_use_lfs64 = yes
So with these tests, aprlfs is set to 0. Patching configure.in to set
it to 1 unconditionally defines APR_HAS_LARGE_FILES to 1, and it
solves my link problem, but I thought I would tell you, so you can
implement a more subtle fix to this problem. In particular, the
hard-coded "4yes" seems a bit strange to me, but I don't understand
the logic enough to propose a fix myself...
I can confirm this - just came over this failure few days ago;
but I hadnt the time to look closer into it ...
Günter.
Re: A bug with httpd-2.4.2 Win-x64
Hi Bing, you did hit the apr list - I think this should go to the httpd list instead ... ;-) Am 16.04.2012 14:32, schrieb Bing Swen: After building the httpd-2.4.2 x64 binaries with VS2010, I encountered a runtime error in the module libhttpd.dll, which alerts that a heap corruption occurred at somewhere: file D:\_bsDev\KSE\httpd-2.4.2\server\config.c line 680: free(ap_module_short_names[m->module_index]); The free() call always led to heap corruption like this: HeapFree(_crtheap, 0, pBlock); // access error with pBlock == NULL. My temp solution is commenting off this single line to get httpd.exe run. Please verify if it is a bug. Regards, Bing
Re: [VOTE] Release apr-util 1.4.1
Am 14.12.2011 11:40, schrieb Graham Leggett: Just to be clear, I don't have any access to a Windows system, never mind a Windows development environment, just like I don't have access to Netware either. I can't comment on any of these points because I'm not familiar enough with any of them to make any sort of modification. the problem is that those familar with those platforms should work harder on more automatism (see my other post for a possible way of doing that). All you can do for now is posting a reminder to the list if you have made changes which you think require further tweaks on the static build systems. Gün.
Re: [VOTE] Release apr-util 1.4.1
Am 14.12.2011 04:25, schrieb William A. Rowe Jr.: I'll check in these files for potential inclusion in a 1.4.2, as folks decided this mostly works now. But we really can't persist this mess for Netware or Win32 going on to APR 2.0. Seems overtime for Guenter and I, or other fresh blood, to get on the task of generating appropriate build files automagically. let me propose to work towards a concept we use with libcurl: 1) we have put all .c and .h files into a Makefile.inc 2) Makefile.am as well as all static makefiles (NetWare, MingW, OS400, etc.) directly pick up this Makefile.inc and build their object files list from that unless the platform uses non-gnu make 3) for MSVC we generate the makefiles/dsp with the release script which generates the file part from Makefile.inc + adds a header and footer to create a working nmake makefile and dsp. If one is interested into this concept get a libcurl clone from git and take a look. Gün.
Re: [VOTE] Release apr-0.9.20 as GA
Am 13.09.2011 18:25, schrieb Jeff Trawick: [ ] Release apr 0.9.20 as GA +1 NetWare no regression from 0.9.19
Re: [Vote] Release apr-util 1.3.11
Hi,
Am 28.04.2011 11:24, schrieb Rainer Jung:
On Sparc I use gcc 4.1.2. All builds are 32 Bit.
Concerning the hangs (unterminated loops in my case), I did some more
investigation for 1.3.10 and confirmed using GDB, that there actually
was a cycle in the cleanups:
(gdb) print c
$1 = (cleanup_t *) 0x38558
(gdb) print *c
$2 = {next = 0x38558, data = 0x38558, plain_cleanup_fn = 0x38710,
child_cleanup_fn = 0x38798}
so c == c->next and thus apr_pool_cleanup_kill looped.
I didn't check, whether that was still true for 1.3.11. I don't know why
c == c->next.
Concerning gcc: I use the same gcc for building on Solaris 8 and on
Solaris 10, even the same binary gcc files. I never observed a problem
on the single CPU Sparc 8 system, but did observer problems on Solaris
10 for 1.3.10 and for 1.3.11. Apart from the OS version the other major
difference is concurrency in hardware (used Niagara CPU with 6 or 8
cores and 4 times the number of strands when testing 1.3.10, and a more
traditional 2 CPU Sparc V240 when testing 1.3.11).
I hope I have some time to check older versions, like 1.3.9 etc. and
maybe also older apr (pool) versions to see, whether I can narrow down
the reason. Unfortunately until now, I could only reproduce the two
problems (unterminated loop, crash) when doing the testing as part of
the mass building, which takes time (a couple of hours). When running
testall after building even in loops, I could not reproduce the problems
...
I can only add that I get also sporadic segfaults (invalid mem access)
on NetWare with CodeWarrior compiler; and since otherwise httpd works
fine when comsuming same APR/APU I believe that something is wrong with
our test suite - it seems to me that it doesnt behave correctly in case
of errors, I mean that not allways return codes of a fucntion failure
are tested, and the test then runs into next function call with
paramters being NULL or something like that ...
also I believe that we fixed some of these already in 2.0 but not yet
backported;
though I had not the time yet to check into this deeper ...
anyway, I see no regression for NetWare - the failing tests are same as
with last release, so:
+1 for NetWare
builds and runs fine with APR-1.4.2-dev / httpd 2.2.18-dev.
Gün.
Re: [Vote] Release apr-util 1.3.11
Am 15.04.2011 12:29, schrieb Jeff Trawick: On Thu, Apr 14, 2011 at 8:01 PM, Bojan Smojver wrote: On Thu, 2011-04-14 at 19:55 -0400, Jeff Trawick wrote: [ ] Release apr-util 1.3.10 as GA I vote for that particular version without testing :-) Qt [ ] Release apr-util 1.3.11 as GA do we agree that is needed for MSVC in order to link tests statically? --- test/makefile.win (revision 835655) +++ test/makefile.win (working copy) @@ -87,7 +87,9 @@ !IF "$(MODEL)" == "static" PROGRAM_DEPENDENCIES = \ $(APR_PATH)\$(APROUTDIR)\apr-1.lib \ - ..\$(OUTDIR)\aprutil-1.lib + ..\$(OUTDIR)\aprutil-1.lib \ + $(API_PATH)\$(OUTDIR)\apriconv-1.lib \ + ..\xml\expat\lib\$(OUTDIR)\xml.lib STATIC_CFLAGS = /D APR_DECLARE_STATIC /D APU_DECLARE_STATIC STATIC_LIBS = odbc32.lib odbccp32.lib wldap32.lib !ELSE Gün.
Re: [vote] reset to apr-util 1.5.0-dev?
Am 15.04.2011 04:09, schrieb Dongsheng Song: [X] Bump to apr-util 1.5.0 for the next pre-2.0 release Use apr-utils 1.3 with apr 1.4, I felt very strange. /me too. I think it's reasonable to bump apr-util to 1.5, and used with apr 1.5. ha, and exactly this will then *not* happen with your vote, but instead we will then use apr-1.4.x (where we have currently no reason to go 1.5.x) with apr-1.5.x == as strange as before, only then APU looks advanced instead of behind :-) Gün.
Re: [vote] reset to apr-util 1.5.0-dev?
Am 15.04.2011 03:51, schrieb William A. Rowe Jr.: In order to disambiguate what was released by external entities from what the ASF APR Project has voted upon and released, I'd suggest that we best serve our users by 'skipping' apr-util 1.4.x, and at minimum, 1.4.0. sorry, but can you please explain what you mean here with 'external entities' ?? thanks, Gün.
Re: Patch for IPv6 on Windows before Vista
Am 12.04.2011 21:01, schrieb Jeff Trawick: On Tue, Apr 12, 2011 at 2:37 PM, Jeff Trawick wrote: On Thu, Jun 19, 2008 at 9:56 PM, Sob wrote: Hello, while experimenting with httpd and IPv6 on WinXP, I found out that it's not working well. In short, the code expects that IPv4 mapped addresses and IPV6_V6ONLY socket ... I just noticed that this is also tracked at https://issues.apache.org/bugzilla/show_bug.cgi?id=45321 a C&P from a recent IRC talk with Gregg L. Smith: Gregg: Hola, reading APR list Gregg: If the turn on IPv6 in apr 1.4.3, therefore 2.2.18, you are going to get a hell of a lot of Windows bug reports unless that patch by Sob is comitted Gregg: XP will be no problem till everyone reads (ah, I can do IPv6 now) and installs the IPv6 proto, at which point Apache will crash with a duplicate socket error /me: well, why dont you participate the discussion, and bring up your experiences? /me: well, you made your experience - tell us all!! Gregg: I do not feel like subscribing to apr, but trust me, I tested it a hundred times 2 years ago and know, this is the reason we have seperate downloads at the haus Gregg: copy that, paste it in a message and say this is the info you received from me via IRC which I just did :-) Gün.
Re: svn commit: r1086790 - /apr/apr/trunk/xml/apr_xml_internal.h
Am 11.04.2011 21:14, schrieb Jeff Trawick: how about changing the _ex to _internal? sure, sounds better ... Gün.
Re: svn commit: r1086790 - /apr/apr/trunk/xml/apr_xml_internal.h
Jeff, Niq,
Am 30.03.2011 01:26, schrieb Jeff Trawick:
On Tue, Mar 29, 2011 at 7:09 PM, Guenter Knauf wrote:
Am 30.03.2011 00:52, schrieb Guenter Knauf:
are you really sure this is the right thing? /me doubt ...
1. its in an internal header - if we want to expoert that function then
it should be moved to a public header
2. if you look into apr_xml.c you can find:
APR_DECLARE(apr_xml_parser *) apr_xml_parser_create(apr_pool_t *pool)
{
return apr_xml_parser_create_ex(pool,&start_handler,&end_handler,
&cdata_handler);
}
so why should something directly link against apr_xml_parser_create_ex() ?
I dont find any other reference to apr_xml_parser_create_ex() beside the one
in apr_xml.c; so I guess the linkage error happens because
apr_xml_parser_create_ex() is wrongly marked for export in the C file, or?
right, apr_xml_expat/libxml had API-style linkage
xml/apr_xml_expat.c:APR_DECLARE(apr_xml_parser *)
apr_xml_parser_create_ex(apr_pool_t *pool,
xml/apr_xml_libxml2.c:APR_DECLARE(apr_xml_parser *)
apr_xml_parser_create_ex(apr_pool_t *pool,
meanwhile, apr_xml_parser_create_ex() certainly *sounds* like an API
niq, is that to be exported eventually? otherwise, the APR_DECLARE()
can be ripped off and the two implementations be given a less
API-sounding name
I still dont believe we should export this function, and have just
created the patch to remove he APR_DECLARE() - if there's shortly some
proposal for a better name then I'll take that into account, otherwise I
will commit the removal only within a hour -- unless someone screams :-)
Gün.
Re: svn commit: r1086625 - in /apr/apr/branches: 1.3.x/include/apr.h.in 1.4.x/include/apr.h.in 1.5.x/include/apr.h.in
Am 11.04.2011 19:33, schrieb Jeff Trawick: most of this commit helps in that way, but there's a tiny amount which diverges (more like trunk apr.hw than branches/* apr.hw)... I'll address that shortly with some additional sync; just don't be surprised ;) naaa ... :-) and sorry I didnt pay enough attention to apr.hw in branches ... Gün.
Re: process.h
Am 08.04.2011 17:45, schrieb Jeff Trawick: process.h has a cute history 1.4.x: APR_HAVE defined in apr.hw/apr.h.in; the include is performed in apr.hw if defined so apr.h.in needs to add the include if defined for same app experience with the two build systems hehe, ans sorry I didnt dig that up self ... trunk: you removed the APR_HAVE_ and include from apr.hw; Günther added the APR_HAVE back to apr.h.in, so they're out of sync and need to be fixed fine with me not to include it everywhere, but the APR_HAVE has been useful (I think httpd uses that) so then my patch although intuitive without knowing history looks more like forward patch then ... :-) APR_WANT_GETPID for apr_want.h is the more appropriate interface for APR 2, but that still needs a visible APR_HAVE_PROCESS_H what's that bad to include an offical system header for one platform when we have it? If we would agree to make it equal with all 1.x / 2.x APR versions to include it from apr.h then we could axe a lot of 'ifdef APR_HAVE_PROCESS_H' from httpd trunk as well as 2.2.x ... Gün.
Re: signal.h on Windows
Am 08.04.2011 17:29, schrieb William A. Rowe Jr.: oh, and another bad thingy I found with APR on Windows is that ugly redefining of all the SIG* defines in apr_private.h - it simply doesnt work as it should, that means it only depends on the order of includes: if signal.h is included before apr_private.h then the wanted redefine happens, the other turn signal.h defines win which is not what is desgined as I guess; I found this with OpenWatcom which does not allow redefining macros ... (at least not with different values) any idea how to workaround this issue properly? I think that the only clean way would be to define our own APR_SIG* macros and use these, but that would then affect all platforms :-( Which could happen with 2.0 but not 1.x - anything more specific about how to avoid these collisions/load order issues for 1.x? well, I could try to disable signal.h completely, and then see which sources fail, and within these make sure that arch/private comes always 1st (but this would still not work with Watcom and other compilers which dont allow redefines), or we could always 1st inlcude apr.h to get the APR_HAVE_*, then in the middle the sytem headers, and finally arch/private and undef 1st all macros which need redefines ... or someone has a better idea?? Guen.
Re: To tag apr 1.4.3/-util 1.3.11?
Am 08.04.2011 08:02, schrieb William A. Rowe Jr.: Jeff, I've lost your thread, probably because it's half at httpd. Just so you know, I did get to spend my hours yesterday and today on 2008R2 with Visual Studio 2010 - mostly on the tasks of rebuilding a VM to which I had lost the admin password (damn 'password constraints'). I would like to spend some time tomorrow and Saturday morning wrapping up all our work, I have Steve's work ready to commit and will at least ensure Bert's suggestions are adopted, if not a wholesale fix to //unc/vol issues. Guenter, you have also make a ton of adjustments - are your changes ready to fly? Regarding netware: yes sir - all builds nicely, and I can now compile NetWare targets on Linux for all APR/APU and httpd HEAD/2.2.x versions. Regarding windows: I would like to cleanup some stuff in apr: http://people.apache.org/~fuankg/diffs/apr_cleanup.diff it makes no sense to me that we duplicate HAVE_* in arch/apr_private.h for which we have already APR_HAVE_* in apr.h[w] ... and comments on that? oh, and another bad thingy I found with APR on Windows is that ugly redefining of all the SIG* defines in apr_private.h - it simply doesnt work as it should, that means it only depends on the order of includes: if signal.h is included before apr_private.h then the wanted redefine happens, the other turn signal.h defines win which is not what is desgined as I guess; I found this with OpenWatcom which does not allow redefining macros ... (at least not with different values) any idea how to workaround this issue properly? I think that the only clean way would be to define our own APR_SIG* macros and use these, but that would then affect all platforms :-( Gün.
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES build/apr_rules.mk.in configure.in include/apr.h.in test/Makefile.in
Am 02.04.2011 23:54, schrieb William A. Rowe Jr.: When the compiler has the insight that it is binding against relocatable, loadable sections, it has a chance to change all references to a vtable in mutable heap, and leave the actual binary images alone. Failure to do this for data pointers is usually lethal. The inverse of what you suggest, compiling it all export whether it will be used statically or dynamically works out a bit better, but it's still worth performing two compilations. and that cant be forced by compiler switches like -fPIC and -msep-data ? Gün.
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES build/apr_rules.mk.in configure.in include/apr.h.in test/Makefile.in
Am 02.04.2011 20:29, schrieb William A. Rowe Jr.: On 4/2/2011 10:27 AM, Guenter Knauf wrote: *if* we want to do it 'right' in one pass then I believe we would need to build with APR_DECLARE_STATIC and then get the DDL linked with a .def file (which is close to what is done on Linux with the export*.c hacks); I would volunteer to modify our make_nw_exports.awk to be able to write a Windows .def file, but I would fail to integrate this into a configure build process ... :-( You know that leads to segfaults, and per-process modification of what are otherwise constant/shared .text pages, right? nope - I didnt yet ... Gün.
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES build/apr_rules.mk.in configure.in include/apr.h.in test/Makefile.in
Am 02.04.2011 16:59, schrieb Guenter Knauf: Am 02.04.2011 16:39, schrieb Jeff Trawick: If you want both static and dynamic: * two builds in two passes of APR * further hacks to allow the two builds to be co-resident in the install location, since apr-2-config needs to know whether or not to spit out APR_DECLARE_STATIC in CPPFLAGS (and possibly other, uninvestigated glitches to resolved) So yes, at present you get a dynamic build by default, and if you want a static build you need to add --disabled-shared as well to avoid current glitches. k, thats what I thought ... *if* we want to do it 'right' in one pass then I believe we would need to build with APR_DECLARE_STATIC and then get the DDL linked with a .def file (which is close to what is done on Linux with the export*.c hacks); I would volunteer to modify our make_nw_exports.awk to be able to write a Windows .def file, but I would fail to integrate this into a configure build process ... :-( Gün.
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES build/apr_rules.mk.in configure.in include/apr.h.in test/Makefile.in
Am 02.04.2011 16:59, schrieb Guenter Knauf: no, something which is kinda /me giving up on teaching configure to do it right . http://people.apache.org/~fuankg/mingw/MWGNUmakefile http://people.apache.org/~fuankg/mingw/MWGNUmakefile.inc with that makefile you have both static and dynamic within less the time than what configure only needs :-) and honestly I'm thinking this is brobably a better approach since what we now did while wasting countless hours is basically exactly same: overwrite configure tests manually :-( pros: - fast - build is 100% in sync with MSVC build (uses same apr.hw etc.) - easy to maintain for everyone who's familar with GNU make - no dependency on Python - no dependency on MSYS / bash / configure / m4 / ... cons: - extra maintenance of MWGNUmakefile.inc when source files are added or removed the cons can be axed if we would use separate makefile.inc for the configure builds as well where we list the source files and include these into the created Makefile ... - then we would in future only maintain changes at one place = makefile.inc one point which made me hack this makefile was to see how long it would take to create a working makefile which does the job, and that was done within ~2.5 hours; the other point is that I see not much sense in letting configure waste a huge amount of time for various tests which then finally get anyway overwritten - and if I look at our branches this becomes even worse because configure runs then twice (once for APR, once for APU) ... Gün.
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES build/apr_rules.mk.in configure.in include/apr.h.in test/Makefile.in
Am 02.04.2011 16:39, schrieb Jeff Trawick: If you want both static and dynamic: * two builds in two passes of APR * further hacks to allow the two builds to be co-resident in the install location, since apr-2-config needs to know whether or not to spit out APR_DECLARE_STATIC in CPPFLAGS (and possibly other, uninvestigated glitches to resolved) So yes, at present you get a dynamic build by default, and if you want a static build you need to add --disabled-shared as well to avoid current glitches. k, thats what I thought ... I'm not sure what you mean by that static makefile. Something that drives the configure+make+make-install twice? no, something which is kinda /me giving up on teaching configure to do it right . http://people.apache.org/~fuankg/mingw/MWGNUmakefile http://people.apache.org/~fuankg/mingw/MWGNUmakefile.inc with that makefile you have both static and dynamic within less the time than what configure only needs :-) and honestly I'm thinking this is brobably a better approach since what we now did while wasting countless hours is basically exactly same: overwrite configure tests manually :-( here's the build log with this makefile: http://people.apache.org/~fuankg/mingw/build_mingw32-trunk.txt.gz Gün.
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES build/apr_rules.mk.in configure.in include/apr.h.in test/Makefile.in
Hi Jeff, Am 02.04.2011 15:50, schrieb traw...@apache.org: +dnl If building static APR, both the APR build and the app build +dnl need -DAPR_DECLARE_STATIC to generate the right linkage from +dnl APR_DECLARE et al. +dnl If building dynamic APR, the APR build needs APR_DECLARE_EXPORT +dnl and the app build should have neither define. + +*-mingw* | *-cygwin*) +if test "$enable_shared" = "yes"; then +APR_ADDTO(INTERNAL_CPPFLAGS, -DAPR_DECLARE_EXPORT) +else +APR_ADDTO(CPPFLAGS, -DAPR_DECLARE_STATIC) +fi +;; esac h; without having this tested yet - wouldnt this require that the whole build uses two passes? What if you use: ./configure --shared --static ?? I've meanwhile created a static makefile which does exactly this, and therefore needs compile go with -DAPR_DECLARE_STATIC for creating the static lib, and another with -DAPR_DECLARE_EXPORT for creating the DLL ... Gün.
Re: FYI on "my" MinGW goals
Am 30.03.2011 01:56, schrieb William A. Rowe Jr.: This bit looks more important; checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes grep: /home/Administrator/apr/bldapr-1.4.x/libtool: No such file or directory $ ll bldapr-1.4.x/libtool -rwxr-xr-x 1 Administrator Administratoren 289K Mar 29 15:55 bldapr-1.4.x/libtool so this message seems un-important as well since later on all sources are compiled with libtool ... Gün.
Re: FYI on "my" MinGW goals
Bill, Am 30.03.2011 02:19, schrieb Guenter Knauf: Am 30.03.2011 01:59, schrieb William A. Rowe Jr.: One more thought, I am very curious how your results differ if ./buildconf is done on unix rather than in the wild west universe of mingw. pretty much same ... http://people.apache.org/~fuankg/mingw/build_w32_cross.txt.gz not a recent one (few days back) but same - no DLLs just the minute done a fresh build - at same link: http://people.apache.org/~fuankg/mingw/build_w32_cross.txt.gz and as you can see there now almost all warnings gone, but th eonlyx DDL build is expat; and that result is 100% same as wih MSYS on Windows ... seems that those who did the expat configure knew better than those who did apr/apu ... well, there's a huge scope for enhancement as it seems ... also our configure is at best 'unusual'; f.e. I have already compiled a couple of things successfully on MinGW/MSYS, f.e. such things like bintuils, libcurl, ...; and I did never come over any other configure stuff that depends on Python (yet) ... also I miss a bit good old times 10 years back with the first httpd 2.0 versions when I compiled them on Linux, and just only needed to call ./configure in httpd, and that configure found itself apr, and apr found itself apr-util, and all went without manual interaction ... but seems that these times are gone ... f.e. when I have: base /apr /apr-util why the heck cant apr automatically look for and find ../apr-util if it depends on it? Gün.
Re: FYI on "my" MinGW goals
Am 30.03.2011 01:59, schrieb William A. Rowe Jr.: On 3/29/2011 6:56 PM, William A. Rowe Jr. wrote: On 3/29/2011 6:24 PM, Guenter Knauf wrote: Am 30.03.2011 01:20, schrieb Guenter Knauf: Hi, Am 30.03.2011 01:14, schrieb William A. Rowe Jr.: 1 error generated. What is *that* about? :) un-important; with un-important I mean here that also with gcc where the includes are fine and pre-preocessing and compile of export*.c work still no DDL - and no DLL target in Makefile. This bit looks more important; checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes grep: /home/Administrator/apr/bldapr-1.4.x/libtool: No such file or directory One more thought, I am very curious how your results differ if ./buildconf is done on unix rather than in the wild west universe of mingw. pretty much same ... http://people.apache.org/~fuankg/mingw/build_w32_cross.txt.gz not a recent one (few days back) but same - no DLLs Gün.
Re: FYI on "my" MinGW goals
Am 30.03.2011 01:20, schrieb Guenter Knauf: Hi, Am 30.03.2011 01:14, schrieb William A. Rowe Jr.: 1 error generated. What is *that* about? :) un-important; with un-important I mean here that also with gcc where the includes are fine and pre-preocessing and compile of export*.c work still no DDL - and no DLL target in Makefile. Gün.
Re: FYI on "my" MinGW goals
Hi, Am 30.03.2011 01:14, schrieb William A. Rowe Jr.: 1 error generated. What is *that* about? :) On the wargs, I believe we are replacing that code; I'm creating a VC10environment for validation right now so I can better understand if the proposed fix forenviron allocs is going to be the solution to all of the msvcrXXX flavors. Provided it does, I'll get that committed very shortly. un-important; I saw it ans its because my clang installation is probably wrong; I had to add the mingw includes to CFLAGS, but when export.c is compiled it does only take CPPFLAGS into sccount - thereofre missing headers ... the clang build was just to see the remaining warnings better since clang is much more verbose than gcc and explains more detailed what goes wrong ... Gün.
Re: svn commit: r1086790 - /apr/apr/trunk/xml/apr_xml_internal.h
Am 30.03.2011 00:52, schrieb Guenter Knauf:
are you really sure this is the right thing? /me doubt ...
1. its in an internal header - if we want to expoert that function then
it should be moved to a public header
2. if you look into apr_xml.c you can find:
APR_DECLARE(apr_xml_parser *) apr_xml_parser_create(apr_pool_t *pool)
{
return apr_xml_parser_create_ex(pool, &start_handler, &end_handler,
&cdata_handler);
}
so why should something directly link against apr_xml_parser_create_ex() ?
I dont find any other reference to apr_xml_parser_create_ex() beside the
one in apr_xml.c; so I guess the linkage error happens because
apr_xml_parser_create_ex() is wrongly marked for export in the C file, or?
Gün.
Re: svn commit: r1086790 - /apr/apr/trunk/xml/apr_xml_internal.h
Hi Jeff,
Am 30.03.2011 00:29, schrieb traw...@apache.org:
Author: trawick
Date: Tue Mar 29 22:29:05 2011
New Revision: 1086790
URL: http://svn.apache.org/viewvc?rev=1086790&view=rev
Log:
fix linkage of apr_parser_create_ex() on Windows
Submitted by: Carlo Bramini
PR: tiny part of 46175
Modified:
apr/apr/trunk/xml/apr_xml_internal.h
Modified: apr/apr/trunk/xml/apr_xml_internal.h
URL:
http://svn.apache.org/viewvc/apr/apr/trunk/xml/apr_xml_internal.h?rev=1086790&r1=1086789&r2=1086790&view=diff
==
--- apr/apr/trunk/xml/apr_xml_internal.h (original)
+++ apr/apr/trunk/xml/apr_xml_internal.h Tue Mar 29 22:29:05 2011
@@ -43,8 +43,6 @@ struct apr_xml_parser {
XMLParserImpl *impl;
};
-
-
-apr_xml_parser *apr_xml_parser_create_ex(apr_pool_t*, void*, void*, void*);
+APR_DECLARE(apr_xml_parser *) apr_xml_parser_create_ex(apr_pool_t*, void*,
void*, void*);
#endif
are you really sure this is the right thing? /me doubt ...
1. its in an internal header - if we want to expoert that function then
it should be moved to a public header
2. if you look into apr_xml.c you can find:
APR_DECLARE(apr_xml_parser *) apr_xml_parser_create(apr_pool_t *pool)
{
return apr_xml_parser_create_ex(pool, &start_handler, &end_handler,
&cdata_handler);
}
so why should something directly link against apr_xml_parser_create_ex() ?
Gün.
Re: FYI on "my" MinGW goals
Am 28.03.2011 20:24, schrieb Guenter Knauf: and that seems to work - it skips the useless testing for *mingw* and sets the right typedef in apr.h, and the warning is then also gone; but not sure if its the right patch ... with this one and all the other recent fixes apr-1.4.x looks now pretty good - only 3 warnings remain now with misc/win32/start.c; I've just build a round with clang to make the issues a bit more clear: http://people.apache.org/~fuankg/mingw/build_w32_msys_clang.txt.gz if whe want to avoid further casts then we probably need to change wchar_t to apr_wchar_t - but that cant be done unconditionally because the presense of apr_wchar_t depends on an unicode_fs define ... Bill, are you in the mood to take a look at this? regarding the DLL prob: when I look into the created Makefile then I dont see any target for a shared library at all - only a target for the static lib exists ... also I think the whole stuff with creating export*.c files + arp.exp is nonsense for MingW - instead we should build with the proper defines for APR_DECLARE* and just link the DLL .. - but unfortunately I am not the right one to fix it this way with my still limited configure knowledge :-( Gün.
Re: FYI on "my" MinGW goals
Jeff, I found another serious prob with MinGW APR checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking target system type... i686-pc-mingw32 Configuring APR library Platform: i686-pc-mingw32 checking for working mkdir -p... yes APR Version: 1.4.3 . checking size of ino_t... 2 configure: using ino_t for ino_t argh!! And later of course: D:/MinGW/msys/1.0/home/Administrator/apr/apr-1.4.x/apr/file_io/win32/filestat.c: In function 'apr_file_info_get': D:/MinGW/msys/1.0/home/Administrator/apr/apr-1.4.x/apr/file_io/win32/filestat.c:466:19: warning: left shift count >= width of type and in apr.h I find: typedef ino_t apr_ino_t; this should be an unsigned __int64 -> apr.hw has: typedef apr_uint64_t apr_ino_t; configure.in has at line 1845: ino_t_value=ino_t APR_CHECK_SIZEOF_EXTENDED(AC_INCLUDES_DEFAULT, ino_t, $ac_cv_sizeof_long) if test $ac_cv_sizeof_ino_t = 4; then if test $ac_cv_sizeof_long = 4; then ino_t_value="unsigned long" else ino_t_value="unsigned int" fi fi AC_MSG_NOTICE([using $ino_t_value for ino_t]) how can we properly convince configure to use a 64-bit for MinGW here? I've hacked this: Index: apr/branches/1.4.x/configure.in === --- apr/branches/1.4.x/configure.in (Revision 1085987) +++ apr/branches/1.4.x/configure.in (Arbeitskopie) @@ -1842,15 +1842,24 @@ # releases did. To be correct, apr_ino_t should have been made an # ino64_t as apr_off_t is off64_t, but this can't be done now without # breaking ABI. -ino_t_value=ino_t -APR_CHECK_SIZEOF_EXTENDED(AC_INCLUDES_DEFAULT, ino_t, $ac_cv_sizeof_long) -if test $ac_cv_sizeof_ino_t = 4; then -if test $ac_cv_sizeof_long = 4; then -ino_t_value="unsigned long" -else -ino_t_value="unsigned int" + +# Per OS tuning... +case $host in +*mingw*) +ino_t_value=apr_int64_t +;; +*) +ino_t_value=ino_t +APR_CHECK_SIZEOF_EXTENDED(AC_INCLUDES_DEFAULT, ino_t, $ac_cv_sizeof_long) +if test $ac_cv_sizeof_ino_t = 4; then +if test $ac_cv_sizeof_long = 4; then +ino_t_value="unsigned long" +else +ino_t_value="unsigned int" +fi fi -fi +;; +esac AC_MSG_NOTICE([using $ino_t_value for ino_t]) # Checks for endianness and that seems to work - it skips the useless testing for *mingw* and sets the right typedef in apr.h, and the warning is then also gone; but not sure if its the right patch ... Gün.
Re: svn commit: r1085985 - /apr/apr/trunk/configure.in
Am 27.03.2011 23:36, schrieb William A. Rowe Jr.: On 3/27/2011 11:50 AM, fua...@apache.org wrote: Author: fuankg Date: Sun Mar 27 16:50:30 2011 New Revision: 1085985 URL: http://svn.apache.org/viewvc?rev=1085985&view=rev Log: Fixed mingw platform identifier to catch all cross compilers. +++ apr/apr/trunk/configure.in Sun Mar 27 16:50:30 2011 @@ -551,11 +551,11 @@ case $host in OSDIR="as400" eolstr="\\n" ;; - *-mingw*) + *mingw*) Might we need to distinguish 64 bit here? hmmm, if we can avoid it then we should ... f.e. if there's a define from the compiler like __MING64__ or such to determine 64-bit then we should use this to define our own WIN64, and same for MSVC too ... Gün.
APR_WANT_IOVEC in apr_want.h
I was just looking at this part again (BZ#50146):
#ifdef APR_WANT_IOVEC
#if APR_HAVE_IOVEC
#if APR_HAVE_SYS_UIO_H
#include
#endif
#else
struct iovec
{
void *iov_base;
size_t iov_len;
};
#endif
/* apr_want is included at several layers; redefining APR_HAVE_IOVEC
* now to ensure that our struct is not introduced several times.
*/
#undef APR_HAVE_IOVEC
#define APR_HAVE_IOVEC 1
#undef APR_WANT_IOVEC
#endif
I think setting APR_HAVE_IOVEC in case of defining struct iovec is
wrong; if apr_want.h is called a 2nd time then it does protect from
defining struct iovec again, but then the '#include ' plugs
in, and this might be only useless, or may clash on other things if the
system header is not self protected from including twice ...
therefore I think we should here define an independent macro like
APR_IOVEC_DEFINED:
#ifdef APR_WANT_IOVEC
#if APR_HAVE_IOVEC
#if APR_HAVE_SYS_UIO_H
#include
#endif
#else
#ifndef APR_IOVEC_DEFINED
#define APR_IOVEC_DEFINED
struct iovec
{
void *iov_base;
size_t iov_len;
};
#endif /* !APR_IOVEC_DEFINED */
#endif /* APR_HAVE_IOVEC */
#undef APR_WANT_IOVEC
#endif
I dont believe this fixes BZ#50146, but I think its better this way ...
comments?
Gün.
Re: svn commit: r1085978 - in /apr/apr/trunk: build/apr_hints.m4 configure.in
Jeff, can you please take a look at this commit and verify this is what you suggested, and that I did it right? If ok, should I proceed and apply all these to build/apr_hints.m4 across all branches? Gün. Am 27.03.2011 18:24, schrieb fua...@apache.org: Author: fuankg Date: Sun Mar 27 16:24:31 2011 New Revision: 1085978 URL: http://svn.apache.org/viewvc?rev=1085978&view=rev Log: Moved platform-specific stuff to build/apr_hints.m4. Modified: apr/apr/trunk/build/apr_hints.m4 apr/apr/trunk/configure.in Modified: apr/apr/trunk/build/apr_hints.m4 URL: http://svn.apache.org/viewvc/apr/apr/trunk/build/apr_hints.m4?rev=1085978&r1=1085977&r2=1085978&view=diff == --- apr/apr/trunk/build/apr_hints.m4 (original) +++ apr/apr/trunk/build/apr_hints.m4 Sun Mar 27 16:24:31 2011 @@ -442,16 +442,20 @@ dnl # Not a problem in 10.20. Ot APR_ADDTO(CPPFLAGS, [-DCYGWIN]) ;; *mingw*) +APR_ADDTO(CPPFLAGS, [-DWIN32]) APR_ADDTO(LDFLAGS, [-Wl,--enable-auto-import,--subsystem,console]) - APR_SETIFNULL(apr_lock_method, [win32]) - APR_SETIFNULL(apr_process_lock_is_global, [yes]) APR_SETIFNULL(have_unicode_fs, [1]) APR_SETIFNULL(have_proc_invoked, [1]) + APR_SETIFNULL(apr_lock_method, [win32]) + APR_SETIFNULL(apr_process_lock_is_global, [yes]) APR_SETIFNULL(apr_cv_use_lfs64, [yes]) APR_SETIFNULL(apr_cv_osuuid, [yes]) +APR_SETIFNULL(apr_cv_tcp_nodelay_with_cork, [no]) +APR_SETIFNULL(apr_thread_func, [__stdcall]) APR_SETIFNULL(ac_cv_o_nonblock_inherited, [yes]) APR_SETIFNULL(ac_cv_tcp_nodelay_inherited, [yes]) -APR_SETIFNULL(apr_thread_func, [__stdcall]) +APR_SETIFNULL(ac_cv_file__dev_zero, [no]) +APR_SETIFNULL(ac_cv_func_setpgrp_void, [no]) case $host in *mingw32*) APR_SETIFNULL(apr_has_xthread_files, [1]) Modified: apr/apr/trunk/configure.in URL: http://svn.apache.org/viewvc/apr/apr/trunk/configure.in?rev=1085978&r1=1085977&r2=1085978&view=diff == --- apr/apr/trunk/configure.in (original) +++ apr/apr/trunk/configure.in Sun Mar 27 16:24:31 2011 @@ -553,10 +553,6 @@ case $host in ;; *-mingw*) OSDIR="win32" - APR_ADDTO(CPPFLAGS,-DWIN32) - ac_cv_file__dev_zero="no" - ac_cv_func_setpgrp_void="no" - apr_cv_tcp_nodelay_with_cork="no" enable_threads="system_threads" eolstr="\\r\\n" file_as_socket="0" @@ -565,7 +561,6 @@ case $host in ;; *cygwin*) OSDIR="unix" - APR_ADDTO(CPPFLAGS,-DCYGWIN) enable_threads="no" eolstr="\\n" ;;
Re: svn commit: r1085937 - in /apr/apr: branches/1.3.x/configure.in branches/1.4.x/configure.in branches/1.5.x/configure.in trunk/configure.in
Am 27.03.2011 16:32, schrieb Jeff Trawick: On Sun, Mar 27, 2011 at 9:57 AM, wrote: Author: fuankg Date: Sun Mar 27 13:57:28 2011 New Revision: 1085937 URL: http://svn.apache.org/viewvc?rev=1085937&view=rev Log: Set APR_HAS_OS_UUID=1 for Windows builds. trunk build/apr_hints.m4 already sets this oh! But then I just see that apr_cv_use_lfs64 is then also setup twice ... do you want me to revert and change all branches to havwe these in build/apr_hints.m4? Gün.
Re: apr 1.3.x branch is dead, right?
Am 27.03.2011 16:25, schrieb Jeff Trawick: I was the last to T&R 1.3.x, slightly after the first 1.4.x release IIRC. I don't intend to do that again, and I'm not making any effort to maintain the branch. But that's just me. Does anyone else have any intentions to release 1.3.x, or otherwise believe that there is a need? (Günther?) no; I did only commit to 1.3.x cause I considered it to be still active, and therefore wanted to keep things in sync ... and btw. how about apu-1.4.x release? Gün.
Re: svn commit: r1084621 - in /apr/apr/trunk/xml: apr_xml.c apr_xml_expat.c apr_xml_internal.h apr_xml_libxml2.c
Am 23.03.2011 18:53, schrieb Jeff Trawick: On Wed, Mar 23, 2011 at 12:01 PM, wrote: Author: niq Date: Wed Mar 23 16:01:12 2011 New Revision: 1084621 URL: http://svn.apache.org/viewvc?rev=1084621&view=rev Log: Decouple apr_xml from reliance on Expat Build with expat and it's effectively unchanged. The alternative build with libxml2 is compatible to the point that it passes the test suite, but shouldn't be considered ready for primetime! how does one build only with expat? without libxml2 dev files, my build starts failing with xml/apr_xml_libxml2.c:20:27: error: libxml/parser.h: No such file or directory and I get: Building D:/projects/svn-httpd/apr-head/apr/xml Creating D:\projects\svn-httpd\apr-head\..\srclib\expat-2.0.1/lib/expat_config.h GEN obj_release/xml_cc.opt CC apr_xml.c CC apr_xml_expat.c ### mwccnlm Compiler: #File: apr_xml_expat.c # # 20: typedef enum XML_Error XML_Error; # Error:^ # undefined identifier 'XML_Error' Gün.
Re: [PATCH] tweak recent oracle-dbd-on-big-endian fix
Am 23.03.2011 20:27, schrieb Jeff Trawick: The type is available with 10.2.0.3 and 11.2.0.2 (and probably for eons). from 8.1.5 oratypes.h (2000-03-15): #define ub2 unsigned short #define sb2 signed short Gün.
Re: FYI on "my" MinGW goals
Am 21.03.2011 20:51, schrieb Jeff Trawick: On Mon, Mar 21, 2011 at 3:12 PM, William A. Rowe Jr. wrote: On 3/21/2011 12:56 PM, Jeff Trawick wrote: apr 1.4 doesn't link for me (undefined reference to CreateHardLinkW), That's odd, it's in kernel32.dll. A broken kernel32.dll.a/kernel32.lib file, perhaps? part of it was a missing define to say we're on NT>= some value (a commit from you ~1.5 years ago); without it, we skip over the defs in winbase.h) that may be all, but it is mixed in with a bunch of other backports to 1.4.x I wonder how you convince APR to link DLLs at all - for me that doesnt work, I only get a static lib ... what version are you using? I tried with relative new one: $ msysinfo msysinfo-1.3: Send this to the MSYS support list: MSYS 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 unknown; targ=MINGW32 GNU bash, version 3.1.17(1)-release (i686-pc-msys); ENV=.profile GNU Make 3.81This program built for i686-pc-msys; MAKE_MODE=unix gcc.exe (GCC) 4.5.2; targ=MINGW32 and also with mingw32-cross on SuSE 11.1 Linux: $ i686-pc-mingw32-gcc -v Using built-in specs. Target: i686-pc-mingw32 Configured with: ../configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=x86_64-suse-linux-gnu --host=x86_64-suse-linux-gnu --target=i686-pc-mingw32 --with-gnu-as --with-gnu-ld --verbose --without-newlib --disable-multilib --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --with-sysroot=/usr/i686-pc-mingw32/sys-root --enable-languages=c,c++,java,fortran,objc,obj-c++ --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-hash-synchronization Thread model: win32 gcc version 4.3.3 (GCC) the build logs look similar, and both build no DLLs ... here are the build logs and the script I used: http://people.apache.org/~fuankg/mingw/ Gün.
Re: FYI on "my" MinGW goals
Jeff, Am 21.03.2011 14:58, schrieb Jeff Trawick: * ensure it is viable to use the MinGW toolchain to build APR on 1.4.x-trunk for the purpose of (at least) me testing simple fixes and running the test suite and using gcc as another perspective on the Windows code * provide at least some help in the area of reviewing/testing to those willing to do the heavy lifting to make this a properly supported toolchain As part of that I anticipate backporting some fixes for MinGW to 1.4.x/1.5.x to support this, but with no implication that any code line fully/properly supports MinGW. More people will have to continue to help (and perhaps with it in somewhat better shape it will be more practical). how do you call configure? Separately in apr / apr-util, or in apr with some params? when I do it separately in apr-util I still get: Looking for apr source in /home/Administrator/apr-1.4.x/apr Creating include/private/apu_config.h ... Creating configure ... Generating 'make' outputs ... Traceback (most recent call last): File "D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py", line 230, in main() File "D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py", line 135, in main objects, _unused = write_objects(f, legal_deps, h_deps, files) File "D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py", line 172, in write_objects assert file[-2:] == '.c' AssertionError this is the same prob which I posted some days back already ... the assertion happens because the loop gets 2 times an empty value ... I think I could fix that with copying the whole autostuff from apr-HEAD into apr-1.4.x (though not sure, its been soem days, and was then otherwise busy). Gün.
Re: NW oddness
Am 21.03.2011 16:07, schrieb William A. Rowe Jr.: Just a few thoughts, it does look out of place in its current path. moved to bin. Gün.
Re: NW oddness
Bill, Am 21.03.2011 01:40, schrieb William A. Rowe Jr.: Just noticed; https://svn.apache.org/repos/asf/apr/apr/trunk/xml/expat_config.hnw It seems awfully strange to have in our apr source tree, as expat is now a dependency built separately from apr. Because it's useful to others to know how we built dependencies, I started a practice of putting build-diffs for win32 binary packages underneath http://www.apache.org/dist/httpd/binaries/win32/patches_applied/ and I'm wondering if something similar, at /dist/httpd and/or /dist/apr, might not be a better way to approach this fragment for netware? can you please tell me whats the benefit for the APR projects if you remove that file from there and put it elsewhere? This all sounds a little bit to me as if we are going to make it harder and harder to compile on any non-configure aware platforms, and I'm asking me why? With last discussion about build whoes on Win32 on httpd-dev it sounded the opposite that we wanted to make it easier, no? Gün.
Re: apr 1.4.3, apr-util 1.3.11
Hi Bill, Am 14.03.2011 18:39, schrieb William A. Rowe Jr.: On 3/14/2011 12:32 PM, Bert Huijben wrote: Any application that uses apr_filepath_merge() to get an absolute pathfrom a relative path is broken but only if the current directory before starting the application is based on a lower case drive letter. This is not a common condition, but this patch just fixes that specific error condition. It doesn't alter the comparison of paths It fixes an API bug. Yea, I think that apr_filepath_merge() and apr_filepath_get() are at the root of this real issue, and that the result, not the comparison, was what was broken. I have no real interest in ensuring that the path name manipulation in your test remains valid, but we agree there is an underlying, real issue here. I've seen 16 bit apps do similar things to corrupt the current path, and am looking at both cases together. I think since we agree that we have a bug with APR + we have a working fix for it we should go with the fix and backport it to all branches for now. Sure I agree with you that we should always look for root causes rather than intruducing workarounds - but what I not agree is to veto working fixes and delaying upcoming releases. Look, we had last release 2010-04-03, and in few days that means one year back! I strongly hope that we get this release now out before the year is full, and that are only few days! You can at any time later look for a better fix which covers more error cases, and we casn do another release in 2 months, but its not ok that we always hold back for these and that and keep fixes in trunk only. For others the time moves on, and our end users / consumers use releases rather than trunk code, and its not ok to do releases that seldom, and even more not ok that we then get in releases rushes and release APR, APU and two httpds at same time. Jeff has proposed to release now for 2nd time (last time was before christmas when I asked for), and we should this time get the babe out soon, and before we get next httpd release where Jim is urging for. And BTW I would really like to see a more regulary release intervall, f.e. at least all 4 months - regardless if we have only 1 fix since last release, or 100. My 3ct. Gün.
Re: svn:eol-style for autoconf stuff
Am 17.02.2011 01:13, schrieb Branko Čibej: On 17.02.2011 00:55, Guenter Knauf wrote: beside that even if all would work fine I dont know (yet) if subversion can be configured to use LF as native on windows platform, It's not, and not likely to be, until Windows conventions change. *but* you can take the Cygwin svn and it'll use LF as its "native" style (or maybe nowadays whatever Cygwin in general is configured to use, I can't recall how far those customizations went.) my Cygwin version from last year July does use LF as native ... and without that most likely you end up with a CRLF version since MinGW is targeted to build native windows binaries just like the MSVC toolchain ... Which is the sane thing to do. In the windows world, Cygwin is the one that does everything wrong by default, making it really hard to use in conjunction with native tools. MinGW plays much nicer there. But its shell not handling text line endings correctly is a bug. well, might be - but remember that its not only the shell, but a bunch of autoconf tools which then also would need to be modified to accept CRLF ... Gün.
Re: svn:eol-style for autoconf stuff
Bill, Am 17.02.2011 00:11, schrieb William A. Rowe Jr.: Text is text, scripts are text, mixed conventions make .diff's nearly unparsable, all of which are technical rationals. ok, thanks. Might I suggest, since you are working with an MSYS toolchain, that youfirst investigate why MSYS .sh does not parse text on windows, and yet the svn no idea, probably this is intended behavior since most projects only provide LF-style tarballs?? implementation for MSYS implementation does not export/check out in thesame unix convention? This is most certainly at odds. unfortunately I dont have a MSYS implementation of svn, and here the cat starts biting into its tail: 1 - up to now MSYS/MinGW support for APR/APU is incomplete/not fully working 2 - svn depends on APR/APU 3 - hard to build an MSYS/MinGW svn because of 1 beside that even if all would work fine I dont know (yet) if subversion can be configured to use LF as native on windows platform, and without that most likely you end up with a CRLF version since MinGW is targeted to build native windows binaries just like the MSVC toolchain ... anyway, I'm aware that the prob mainly exists because there's no svn binary yet available for MSYS/MinGW (at least I'm not aware of any). Also see that I personally have no prob with this - I have a Linux box as well as Cygwin which both do the 'right' (LF) checkout for MSYS ... (and of course I've also dos2unix/unix2dos binaries). I have now also posted to the subversion list if they are willing to support override of eol style with checkout too (as possible with export), and so far got one interesting reply about how git handles it: http://mail-archives.apache.org/mod_mbox/subversion-dev/201102.mbox/%3C20110216155244.GB3228@kytes%3E Gün.
Re: svn:eol-style for autoconf stuff
Bill, Am 16.02.2011 21:56, schrieb William A. Rowe Jr.: another observation on this topic: http://www.apache.org/dev/svn-eol-style.txt this config file suggests that we should treat *.ds? files as CRLF, and this is pretty much same as what I suggested for the autoconf files ... though at least APR/APU doesnt follow this recommendation, and *.ds? files are 'svn:eol-style native' in svn repo. This is precisely incorrect advice, neither apr, httpd nor tomcat are party to such nonsense (which makes the recommendation REALLY odd, because I'm just wondering who's left?) Have you ever tried to apply a patch containing diffs of files in alternating line end conventions? Surely not, or this nonsense wouldn't be debated. surely often enough - believe me. Preserving this metadata when moving files around, say between svn and git? Be real. The advise is wrong for the same reasons as LF format on Windows is wrong. Look, I started at these projects (helped start apr) when the windows guy was the windows guy, that aix guy was the aix guy, and on, and on, and on. It was horribly broken and the chances of building on all platforms at any given time was pretty slim. Today, dev@ who work with windows are willing to take a best guess at some config.m4 change, and our unix dev@ kin are willing to stub in what seems to be a proper .dsp file, just to see if it works. That is where we want to be, so all nonsense to the contrary particularly ticks me off, and that goes in both directions (win32 or unix text files). If you read the 100's of messages in the archives, you will be well aware this is a dead horse, and painting bikesheds is also very irritating. all the above was not needed to exlain since I didnt suggest to go that route - as you even quoted from my previous post further down; and anyway why should I suggest this? The *.ds? files are pretty much useless on any other platform than windows (so can be LF on any platform but windows), and on windows they are always properly checked out with 'svn:eol-style native' ... Although I **dont** want to suggest now here that we chance that - *if* the *.ds? files were 'svn:eol-style CRLF' in svn then our daily snapshots would work for Windows MSVC users too. If this is about snapshot builds, and checking out images on the wrong platform, then I want to be certain you are aware of the svn export --native-eol feature? It's trivial to post both .tar.gz and .zip files from our snapshot'er. if you would have read my reply you would know that I'm aware of - see my post from 2011-02-15 00:42 UTC - quote: > If you are foolish enough to mix vc ports of svn with cyg, or visa versa, > you have what is coming to you :) yeah, and since there's nowhere a MSYS SVN binary which would do it 'right' I would have to either use Cygwin then, or cant work directly from svn, but need to always do a 'svn export --native-eol LF' in order to get the configure scripts in 'right' format ... /end qoute beside that I have my own snapshots which Win32 MSVC folks prefer, and these are build with 'svn export --native-eol CRLF' on Linux: http://svwe20.itex.at/snapshots/ the 7zip archives are all CRLF. And that mostly because "our snapshot'er" doesnt do so. Ok, I stop now nerving you since you're anyway not willing to give me a technical background for your opinion ... Peace, Gün.
Re: svn:eol-style for autoconf stuff
Am 16.02.2011 16:48, schrieb Guenter Knauf: proposal: change all *.sh, *.m4, buildconf* and configure* scripts to 'svn:eol-style LF' result: a svn checkout will allways treat these files with LF format regardless of what svn thinks is native for the platform, and this seems correct to me. side effect: the _only_ side effect would be that it is then _required_ on windows to use a developer editor which supports LF formated files for editing autoconf files; but I cant imagine that anyone developing on windows platform uses an editor which is not aware of LF formatted files. For _all_ other platforms there would be no change since they anyway default to 'svn:eol-style LF'. another observation on this topic: http://www.apache.org/dev/svn-eol-style.txt this config file suggests that we should treat *.ds? files as CRLF, and this is pretty much same as what I suggested for the autoconf files ... though at least APR/APU doesnt follow this recommendation, and *.ds? files are 'svn:eol-style native' in svn repo. Although I **dont** want to suggest now here that we chance that - *if* the *.ds? files were 'svn:eol-style CRLF' in svn then our daily snapshots would work for Windows MSVC users too. Gün.
Re: svn:eol-style for autoconf stuff
Hi Bill, Am 15.02.2011 04:17, schrieb William A. Rowe Jr.: What you are proposing is overkill, handling textual information as a binary overkill?? I just ask for changing a svn format in the repo for a handful of files which need on _all_ platforms to be LF - isnt the svn:eol-style setting exactly for this purpose? resource, and I'm strongly -1 (if you hadn't noticed). oh, I got that - but nevertheless I would like that you explain to me on a technical aspect why my suggestion is bad and inacceptable; what you posted so far does not explain where you expect real problems, but sounds more like your personal dislike, and I believe that this is irrelevant for an ASF project. Also it *seems* a bit to me that you didnt really think about what I exactly proposed, and what it will cause, therefore I summarize it again below ... proposal: change all *.sh, *.m4, buildconf* and configure* scripts to 'svn:eol-style LF' result: a svn checkout will allways treat these files with LF format regardless of what svn thinks is native for the platform, and this seems correct to me. side effect: the _only_ side effect would be that it is then _required_ on windows to use a developer editor which supports LF formated files for editing autoconf files; but I cant imagine that anyone developing on windows platform uses an editor which is not aware of LF formatted files. For _all_ other platforms there would be no change since they anyway default to 'svn:eol-style LF'. Gün.
Re: buildconf fails for APU with MinGW
Am 15.02.2011 00:13, schrieb Guenter Knauf: Hi all, before we get out next version I really would like to get soem configure whoes fixed with the 1.4.x/1.3.x branches ... currently APU buildconf fails for me with MinGW in APR's genbuild.py: $ ./buildconf Looking for apr source in /projects/apr-1.4.x/apr Creating include/private/apu_config.h ... Creating configure ... Generating 'make' outputs ... Traceback (most recent call last): File "C:/MinGW/msys/1.0/projects/apr-1.4.x/apr/build/gen-build.py", line 230, in main() File "C:/MinGW/msys/1.0/projects/apr-1.4.x/apr/build/gen-build.py", line 135, in main objects, _unused = write_objects(f, legal_deps, h_deps, files) File "C:/MinGW/msys/1.0/projects/apr-1.4.x/apr/build/gen-build.py", line 172, in write_objects assert file[-2:] == '.c' AssertionError I've added a 'print file' to ./build/gen-build.py line 171 in order to see why the AssertionError happens, and this shows: ... strmatch/apr_strmatch.c uri/apr_uri.c xlate/xlate.c xml/apr_xml.c / so seems to me that some paths are not set properly, and we end up with a slash only which makes the "assert file[-2:] == '.c'" bail out ... I've added a hack which skips the slash, and then buildconf can continue (and BTW there follows another slash), but of course that doesnt fix the root cause why we get slashes instead of filenames ... I will see if I find some more time to investigate deeper what exaxtly fails in 1st place, but if someone who's more familar with gen-build.py has some hints what I could try quickly then please let me know ... Gün.
Re: svn:eol-style for autoconf stuff
Am 15.02.2011 14:28, schrieb Jonathan Leffler: On Mon, Feb 14, 2011 at 15:03, Guenter Knauf wrote: if you checkout apr/apu/httpd from Windows platform you might end up with buildconf + configure + friends with CRLF format due the fact that these are marked 'svn:eol-style native' ... see also BZ #46175 since these are shell scripts I believe they always need LF line endings regardless of the platform, or? If so I would like to change the svn:eol-style for these files to LF so that the get checked out in the right format ... please some comments on that! F.e. how about MacOSX? MacOS X is like any other Unix platform - it uses LF line endings as native. thanks for confirming. Günter.
Re: svn:eol-style for autoconf stuff
Bill, Am 15.02.2011 00:14, schrieb William A. Rowe Jr.: The answer is to use the correct tool on the correct platform, not to break the line endings for everyone vainly attempting to maintain the files in the text editors of the other platforms. please elaborate who are those 'everyone' folks, and what is the correct platform?? configure & friends are shell scripts - thus every platform which deals with shell scripts should also provide an editor which can edit them, no? what I talk about here mainly is windows, and I guess you know well about the situation on that platform ... If you are foolish enough to mix vc ports of svn with cyg, or visa versa, you have what is coming to you :) yeah, and since there's nowhere a MSYS SVN binary which would do it 'right' I would have to either use Cygwin then, or cant work directly from svn, but need to always do a 'svn export --native-eol LF' in order to get the configure scripts in 'right' format ... so please tell me exactly which platforms may be harmed by 'svn:eol-style LF' for the configure scripts; and please dont tell me now that you allways want to maintain these scripts from a windows box with notepad - then I will reply that you should use the 'right' editor which can handle LF files ... :-) Please see that I want to find a solution which works for most users with the stuff commonly available - and there are a couple of editors available which can handle LF files properly on windows, but so far I have not found a MSYS version of svn, and Cygwin seems a bit overkill just for getting svn only ... Gün.
buildconf fails for APU with MinGW
Hi all, before we get out next version I really would like to get soem configure whoes fixed with the 1.4.x/1.3.x branches ... currently APU buildconf fails for me with MinGW in APR's genbuild.py: $ ./buildconf Looking for apr source in /projects/apr-1.4.x/apr Creating include/private/apu_config.h ... Creating configure ... Generating 'make' outputs ... Traceback (most recent call last): File "C:/MinGW/msys/1.0/projects/apr-1.4.x/apr/build/gen-build.py", line 230, in main() File "C:/MinGW/msys/1.0/projects/apr-1.4.x/apr/build/gen-build.py", line 135, in main objects, _unused = write_objects(f, legal_deps, h_deps, files) File "C:/MinGW/msys/1.0/projects/apr-1.4.x/apr/build/gen-build.py", line 172, in write_objects assert file[-2:] == '.c' AssertionError also, I would like to know the exact steps required to make something equal to a release tarball from SVN - means what autoconf tool versions are required min/max, and is it only invoking buildconf, or is it more? Gün.
svn:eol-style for autoconf stuff
Hi, if you checkout apr/apu/httpd from Windows platform you might end up with buildconf + configure + friends with CRLF format due the fact that these are marked 'svn:eol-style native' ... see also BZ #46175 since these are shell scripts I believe they always need LF line endings regardless of the platform, or? If so I would like to change the svn:eol-style for these files to LF so that the get checked out in the right format ... please some comments on that! F.e. how about MacOSX? Gün.
Re: Apache APR build from SVN with MinGW /c/Users/zdavatz/software/apr/xml/expat/configure: No such file or directory
Zeno, Am 09.02.2011 10:45, schrieb Zeno Davatz: This time configure failed with: checking Expat 1.0/1.1... no adding "-L/usr/local/lib" to LDFLAGS setting INCLUDES to "-I/usr/local/include" checking Expat 1.95.x in /usr/local... no removed "-L/usr/local/lib" from LDFLAGS nulling INCLUDES configuring package in xml/expat now /bin/sh: /c/Users/zdavatz/software/apr/xml/expat/configure: No such file or directory configure failed for xml/expat As I remember you encountered a similar error. yes, that's because APR-2 does no longer include expat ... :-( I tried this: #!/bin/sh export PATH=/c/svn-win32-1.5.6/bin:$PATH svn co http://svn.apache.org/repos/asf/apr/apr/trunk apr-HEAD svn co http://svn.apache.org/repos/asf/apr/apr-util/branches/1.5.x/xml/expat apr-HEAD/xml/expat and ran buildconf.sh && ./configure && make inside the expat folder; though this gives still linking errors - need to look into that a bit closer ... but even when we pass this prob the next waits already - see my other post about break in waitio.c ... so for now it makes probably more sense to use httpd-2.3.10 package: http://httpd.apache.org/download.cgi#apache23 I fetched both httpd and httpd-dep packages, and only thing to solve then is the pcre dependency ... but this looks more promising ... Gün.
compile APR with MinGW
Hi, I've just tried to compile APR-HEAD with latest MSYS/MinGW, and so far buildconf + configure worked (tried with recent snapshot, not yet tested from SVN); compilation though breaks then in waitio.c: /bin/sh /home/Administrator/apr/libtool --silent --mode=compile gcc -g -O0 -DHAVE_CONFIG_H -DWIN32 -D_LARGEFILE64_SOURCE -I./i nclude -I/home/Administrator/apr/include/arch/win32 -I./include/arch/unix -I/home/Administrator/apr/include/arch/unix -I/home/Admi nistrator/apr/include -I/home/Administrator/apr/include/private -I/home/Administrator/apr/include/private -I/home/Administrator/ap r/xml/expat/lib -o support/unix/waitio.lo -c support/unix/waitio.c && touch support/unix/waitio.lo support/unix/waitio.c: In function 'apr_wait_for_io_or_timeout': support/unix/waitio.c:80:20: error: 'apr_file_t' has no member named 'pollset' support/unix/waitio.c:82:44: error: 'apr_file_t' has no member named 'pollset' support/unix/waitio.c:86:24: error: 'apr_file_t' has no member named 'pollset' make[1]: *** [support/unix/waitio.lo] Error 1 make[1]: Leaving directory `/home/Administrator/apr' make: *** [all-recursive] Error 1 looking at include/arch/win32/apr_arch_file_io.h the pollset member now depends on APR_FILES_AS_SOCKETS=1: http://svn.apache.org/viewvc?view=revision&revision=748080 while APR_FILES_AS_SOCKETS=0 from apr.h ... so does it make sense at all to compile support/unix/waitio.c for win32, or should we exclude WIN32 platform? --- support/unix/waitio.c.orig 2010-03-16 21:13:48 + +++ support/unix/waitio.c 2011-02-07 15:34:51 + @@ -22,7 +22,7 @@ /* The only case where we don't use wait_for_io_or_timeout is on * pre-BONE BeOS, so this check should be sufficient and simpler */ -#if !BEOS_R5 && !defined(OS2) +#if !BEOS_R5 && !defined(WIN32) #define USE_WAIT_FOR_IO #endif (did here replace OS2 exclude because Brian seems to have added now an own implementation support/os2/waitio.c ...) BTW. r748080 was not yet backported to APR 1.x so this prob exists only with HEAD ... Gün.
maybe time for 1.4.3 ?
1.4.2 was released April 3, 2010, and we had since then some fixes ... Gün.
Re: [VOTE] Release apr-0.9.19 and/or apr-util-0.9.18
Am 13.10.2010 18:54, schrieb Guenter Knauf: Am 13.10.2010 05:24, schrieb Jeff Trawick: After 3+ days: 2 binding votes in favor (need at least one more) 3 non-binding votes in favor no votes opposed +1 for NetWare as .18 already since non-configure build isnt affected by expat whoes ... :-) I thought that I had already separately voted for apr, but just checked mails, and seems I didnt; so here now: [+1] Release apr 0.9.19 as GA [+1] Release apr-util 0.9.19 as GA Gün.
Re: [VOTE] Release apr-0.9.19 and/or apr-util-0.9.18
Am 13.10.2010 05:24, schrieb Jeff Trawick: On Sat, Oct 9, 2010 at 10:19 AM, Jeff Trawick wrote: Tarballs/zips are at http://apr.apache.org/dev/dist/. As there are enclosed security fixes (already available separately) and wrowe wants to roll httpd 2.0 soon-ish to get those delivered to the bulk of our 0.9.x users, it would be great to wrap this up within 48 hours. (Comments on timing welcome.) +/-1 [ ] Release apr 0.9.19 as GA After 3+ days: 2 binding votes in favor (need at least one more) 3 non-binding votes in favor no votes opposed +1 for NetWare as .18 already since non-configure build isnt affected by expat whoes ... :-) Gün.
Re: apr 0.9.19/apr-util 0.9.18?
Am 08.10.2010 23:47, schrieb Rainer Jung: OK, done so far. First build tests on Solaris look good. I can even do an out of tree build. Building the tests might be broken for Windows and Netware, although I'm not aware of any obvious problem. no, all build fine for NetWare, great! All I needed to add was the build fix in APR, and then build was ok. thanks, Gün.
Re: why do we need this pain?
Am 07.10.2010 01:36, schrieb Mike Meyer: For the record - I'm against the change. RFC 2823 says the Reply-To header is an originator field, and the list is *not* the originator of the message. the list *is* the originator since it sends the mail to me, and not you personally, so this is probably again something to discuss ... though I really dont want to start flame wars now about if an RFC expresses things right or if its practical; for too many others its not practical and I think that counts. I have to deal with a bunch of other mailing lists, and with all I can just hit 'reply' without having to care about, so its really anoying that I have to care about with this one list - and in fact what happens is that I always 1st spam the original author before I realize after a while that I didnt hit the list (even just now happened). Also I find it equally annoying that I always get 2 identical mails from such lists: one via list, and one directly from author; not to mention other spamming effects such that the reciepient's mailer collects my mail address automatically (probably as default setting, and without knowing by the user), and in case of a virus attack my address is amongst those harvested by the virus ... Gün.
Re: apr-util 1.5.x -> trunk
Am 06.10.2010 18:20, schrieb Joe Orton: 1) The tip of development for the apr-util tree is what is currently branches/1.5.x. Yes, most of that code also exists in the apr tree. apr-util releases and branches do not come from the apr tree, they come from the apr-util tree. but here's the whole in the shoe: currently we have not yet considered APU 1.4.x ready to rock, thus we do stupid copy-over form APU 1.5.x to APU 1.4.x for no real benefit - the APU releases come from APU 1.3.x. 2) I have hard-coded into my brain the convention that the trunk is the trunk, not a branch named by its current version. I also have scripts which make this assumption. well, thats bad then since we have a trunk in each branch, so your hard-coded wires do probably anyway not fit to the model we have in SVN. I had also a bunch of scripts which I did already chane, not to mention the merge of 2.0 APR/APU. To me the whole terminology of trunk sucks: internally I have re-wrired to the model of what SVN calls it: HEAD = 2.0. But this doesnt any better, but just only another name; then again one can argue that each branch has its HEAD ... Anyway, regardless how we name it, and regardless if you rename 1.5.x to tunk or not - it doesnt save ud from stupid copying between the branches. But what would save us from this would be if we simply would delete either the 1.4.x or 1.5.x APU branch - isnt that something to consider? Also, wouldnt it be worth to consider some rework on the versioning system? Perhaps we should introduce something like APR_API / APU_API, and bumb these every time new functions get added, and so APR/APU consumers could easily check if the version found meets requirements rather than rely completely on version numbers. 3) The trunk called branches/1.5.x will have to be renamed to a trunk called branches/1.6.x if 1.5.x gets cut. Which is dumb. 4) Yes, "people" might get confused if they try to use apr-util's trunk with the APR 2.x, but, meh. We are the people who use the VCS and it should be arranged for our convenience. well, recent changes are hard to understand for lib consumers, and confusing: for almost a decade we have had coupled version numbers for APR/APU, and just now we have started to have two different branches of APR/APU with APR 1.4.x and APU 1.3.x releases ... I think we should kill one branch again: like you say development happens in 1.5.x, so probably we should then delete APU 1.4.x, copy over APU 1.3.x -> 1.4.x, and bring branch 1.3.x completely to bed, no? Maybe I have not thought about all details regarding API, so forgive - its just what I was thinking the last days when your suggestion came up ... my 3 ct. Gün. BTW. there also seems to be other ways how to deal with different branches in SVN, f.e. PHP has such a system with IIRC sparse checkout where you have all branches in one tree together, and can make changes to all branches simultanously (as I said IIRC).
Re: why do we need this pain?
Am 06.10.2010 21:40, schrieb Sander Temme: Please make Reply-To default to the list. It's a discussion list, with discussions taking place on-list. So responses should go to the list. ok, since we are 3 now who would like to have it changed, and the rest seems not to care about, how can we proceed? Whom do I have to ask for the change? who is list manager? Gün.
Re: [Vote] apr-util 1.5.x -> trunk
Am 06.10.2010 21:26, schrieb William A. Rowe Jr.: On 10/5/2010 2:40 AM, Joe Orton wrote: Any objection to renaming the apr-util 1.5.x branch to "trunk"? It is the trunk for that tree now. Counting up the opinions posted on the list... [ ] Rename 1.5.x to "trunk" jorton, rjung, minfrin, trawick, jim [x] apr/ is 'apr-util/ trunk', stub apr-util/trunk with guidance wrowe, niq, henryjen, poirier
why do we need this pain?
Hi all, with almost all other lists we have set the reply-to address to the list, so if you just hit reply then post goes to list as it should be - why the heck is that not true for the d...@apr list?? sure, I only need to take care of it, and hit 'reply to list', but too often I forget about - and as shown in the past it happens to a lot of others too every now and then ... is there any reason why we cant have this equal with all ASF lists? Gün.
Re: apr 0.9.19/apr-util 0.9.18?
Am 05.10.2010 22:58, schrieb Jeff Trawick: does anybody strongly believe that we should get expat fixed in 0.9.x (whether they have time or not)? /me asking dumb question: is it much more work than just copying over from 1.3 ? Gün.
Re: [vote] Release apr-util 1.3.10
Am 01.10.2010 15:22, schrieb Jeff Trawick: Due to the inclusion of a fix for a potential DOS that could affect some library consumers, I hope to get enough feedback within 24 hours to release. +/-1 [+1] Release apr-util 1.3.10 as GA with either patched APR 1.4.2 or yet unreleased APR 1.4.x from SVN APU 1.3.10 builds fine for NetWare; resulting lib runs fine as replacement for the bundled from httpd 2.2.16; server-info reports correctly: Server loaded APR Version: 1.4.2 Compiled with APR Version: 1.4.2 Server loaded APU Version: 1.3.10 Compiled with APU Version: 1.3.9 would be nice if we could get an APR 1.4.x release too for next httpd releases. Gün.
Re: intent to T&R apr-util 1.3.10 sometime Thursday
Am 01.10.2010 04:44, schrieb William A. Rowe Jr.: Gun - let's simply fix 1.3 and 1.5.x - tell me you are done - and I will svn rm the expat/ from 1.4 branch, cp it from the 1.5.x branch. but let's do thatwith builds already fixed instead of patching 2x, ok? I am done. Gün.
Re: intent to T&R apr-util 1.3.10 sometime Thursday
Am 01.10.2010 04:38, schrieb William A. Rowe Jr.: Hmmm? apr-util-1.4 isn't released. We are shipping this from www.apache.org/dist/apr/ ??? I know, but if I now modify 1.4 apr then I can no longer build 1.4 apu with any apr ... Joe, cant you just also update 1.4 apu right now? Gün.
Re: intent to T&R apr-util 1.3.10 sometime Thursday
Am 01.10.2010 02:51, schrieb Jeff Trawick: On Thu, Sep 30, 2010 at 7:47 PM, William A. Rowe Jr. wrote: On 9/30/2010 6:42 PM, Jeff Trawick wrote: Yep, looks like NetWare fixes for expat are in 1.5.x but not 1.3.x. I will probably wait for Günter to say something on the status there. That seems sensible, but the trees should be the same, probably applying his patches to 1.3 would be sufficient (Günter?) Bill, is Windows okay yet? Win32 expat tree seems correct with the next commit, but right now I'm working out just what happened to libaprutil's build to break its own linkage to xml.lib. Will update again a bit later this evening. That's cool; I expect to start back at it in the wee hours US EDT. I have a big prob now: as it seems we did only update 1.3 and 1.5, but not 1.4; but for NetWare we build always apr-util from apr build process, hence apr-util has no own (yet); but unless 1.4 gets also expat update I cant fix apr-1.4, or else it doesnt build anymore with apu-1.4 , argh ...! Gün.
Re: conditional in apr_thread_proc.h
Hi Rüdiger, Am 02.09.2010 08:27, schrieb Ruediger Pluem: I agree that we should fix this. But as I understand the versioning rules, this could be only done in trunk and 1.5 (not released), as otherwise we would change the API/ABI on platforms with APR_HAVE_STRUCT_RLIMIT undefined, correct? hmm, I thought adding a function is not a problem - only changing/removing - or? Gün.
how can this work?
in poll/unix.poll.c (which is also compiled for win32) we have:
/* Poll method pollcb.
* This is probably usable only for WIN32 having WSAPoll
*/
static apr_status_t impl_pollcb_create(apr_pollcb_t *pollcb,
apr_uint32_t size,
apr_pool_t *p,
apr_uint32_t flags)
{
#if APR_HAS_THREADS
return APR_ENOTIMPL;
#else
pollcb->fd = -1;
#ifdef WIN32
if (!APR_HAVE_LATE_DLL_FUNC(WSAPoll)) {
return APR_ENOTIMPL;
}
#endif
...
I'm asking me how we ever reach the '#ifdef WIN32' since
APR_HAS_THREADS=1 in apr.h[w] thus we never come to the '#else' case, or?
Gün.
conditional in apr_thread_proc.h
while checking for missing prototypes I just came over this in
apr_thread_proc.h:
#if APR_HAVE_STRUCT_RLIMIT
/**
* Set the Resource Utilization limits when starting a new process.
* @param attr The procattr we care about.
* @param what Which limit to set, one of:
*
* APR_LIMIT_CPU
* APR_LIMIT_MEM
* APR_LIMIT_NPROC
* APR_LIMIT_NOFILE
*
* @param limit Value to set the limit to.
*/
APR_DECLARE(apr_status_t) apr_procattr_limit_set(apr_procattr_t *attr,
apr_int32_t what,
struct rlimit *limit);
#endif
so the public API changes depending on APR_HAVE_STRUCT_RLIMIT which I
think is wrong; we need to remove the ifdef and all platforms which have
APR_HAVE_STRUCT_RLIMIT=0 need to provide a stub like in beos/proc.c:
APR_DECLARE(apr_status_t) apr_procattr_limit_set(apr_procattr_t *attr,
apr_int32_t what,
void *limit)
{
return APR_ENOTIMPL;
}
it seems that this stub is missing for win32 and os/2 ...
unfortunately this is a very old add, so it affects all APR versions:
http://svn.apache.org/viewvc/apr/apr/trunk/include/apr_thread_proc.h?r1=60147&r2=60146&pathrev=60147
comments?
Gün.
Re: Thread handle leak in APR
Hi Prathima, Am 20.08.2010 09:04, schrieb Prathima Dandapani -X (pdandapa - HCL at Cisco): Steps used to compile Apache is as follows. Run Setenv.cmd from the Windows-Server-2003-R2-Platform-SDK installed directory Run vcvars32.bat from VC++ installed directory. AFAICT this is the wrong order; first you need to call vcvars32.bat, then Setenv.cmd so that the PSDK paths are prepended. Gün.
Re: scan-build on apr/trunk
Am 31.07.2010 16:03, schrieb Stefan Fritsch: On Saturday 31 July 2010, Philip M. Gollucci wrote: http://p6m7g8.net/~pgollucci/sb/ I might take a stab at some of these next week. $ ./buildconf $ scan-build ./configure $ scan-build make -j12 One more issue found by gcc: Error handling in apr_memcache.c is broken: apr/memcache/apr_memcache.c:793: warning: comparison of unsigned expression< 0 is always false apr/memcache/apr_memcache.c:1368: warning: comparison of unsigned expression>= 0 is always true I've played a bit with recent OpenWatcom 1.9, and this compiler also found the above as well as a couple of others: http://people.apache.org/~fuankg/openwatcom/owc_w32_log.txt http://people.apache.org/~fuankg/openwatcom/owc_nw_log.txt if someone is interested in the prelimary makefiles these are also in same folder. Gün.
Re: [Patch] apr trunk doesn't install apu.h
Am 03.08.2010 08:44, schrieb William A. Rowe Jr.: On 8/3/2010 1:35 AM, Guenter Knauf wrote: fine so far, but also bad since shouldnt we at least make sure that APR itself builds without apu.h? There are still a bunch of headers which want to include apu.h - is it ok that I change them all to apr.h, or do I have to mimic this dummy apu.h creation? Yes, and yes (for external users). apu.h should be nothing but a stub, and there is no reason to actually generate the dummy header, it should simply exist in include/ (and did the last time I looked?). ah, ok - since we previously generated apu.h it was also cleaned away with make ... :) Now restored from svn and removed build rule, that looks better ... Gün.
Re: [Patch] apr trunk doesn't install apu.h
Am 06.06.2010 21:13, schrieb Rainer Jung: Subject says it all, more in the patch log message at: http://people.apache.org/~rjung/patches/apr-trunk-fix-broken-installation-of-apu_h.patch On the long term apu.h might go completely, but until now it is still referenced in a lot of installed header files. So e.g. httpd trunk doesn't compile against an installed apr 2 because apr_hooks.h includes apu.h. fine so far, but also bad since shouldnt we at least make sure that APR itself builds without apu.h? There are still a bunch of headers which want to include apu.h - is it ok that I change them all to apr.h, or do I have to mimic this dummy apu.h creation? Building C:/projects/svn-httpd/apr-head/build Generating nw_export.i ### mwccnlm Compiler: #File: nw_export.inc # -- # 5: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_base64.h # # 27: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_buckets.h # - # 28: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_date.h # -- # 35: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_dbd.h # - # 24: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_dbm.h # - # 20: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_hooks.h # --- # 20: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_ldap_url.h # -- # 35: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_md4.h # - # 44: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_xlate.h # --- # 20: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_md5.h # - # 50: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_reslist.h # - # 26: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_optional.h # -- # 20: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_queue.h # --- # 28: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_rmm.h # - # 32: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_sdbm.h # -- # 27: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_sha1.h # -- # 26: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_strmatch.h # -- # 24: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: #File: nw_export.inc # -- # 62: #include "apr_support.h" # Error: ^ # the file 'apr_support.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_thread_pool.h # - # 22: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_uri.h # - # 29: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_uuid.h # -- # 24: #include "apu.h" # Error: ^ # the file 'apu.h' cannot be opened ### mwccnlm Compiler: # In: ..\include\apr_xml.h # - # 32: #include "apu.h" # Error: ^ # the file 'apu.h' cannot b
Re: How to check current version of APR on Centos
Hi Ravi, Ravi Roy schrieb: > I hope that I am writing to right list for APR related question, > please forgive me in case my question is stupid, but I can not find > the real answer anywhere after googling a lot. > I have installed Apache Http Server 2.2.x on Centos 5.3 where APR is > also installed (As far as I know APR is installed by default with > Apache HTTP server). > > My question is how to check which version of APR is running on this > server. Kindly mark me in email since I am not subscribed to this > list. try: httpd -V this should give you something like that: Server version: Apache/2.2.15 (Linux/SUSE) Server built: Mar 19 2010 17:58:40 Server's Module Magic Number: 20051115:24 Server loaded: APR 1.3.8, APR-Util 1.3.9 Compiled using: APR 1.3.8, APR-Util 1.3.9 Architecture: 64-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="/srv/www" -D SUEXEC_BIN="/usr/sbin/suexec2" -D DEFAULT_PIDLOG="/var/run/httpd2.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="/var/run/accept.lock" -D DEFAULT_ERRORLOG="/var/log/apache2/error_log" -D AP_TYPES_CONFIG_FILE="/etc/apache2/mime.types" -D SERVER_CONFIG_FILE="/etc/apache2/httpd.conf" HTH, Gün.
Re: [VOTE] release apr-1.4.2?
Hi all, Jeff Trawick schrieb: > On Sun, Jan 24, 2010 at 6:45 PM, Guenter Knauf wrote: >> BTW. while I was on that found that in httpd's roll.sh the gpg signing >> part looks wrong to me - therefore I kept the way how the signing user >> is handled same as was before in apr's release.h; but I believe it >> should be fixed for httpd's roll.sh: > > I can't comment on the exact patch, but I had issues with this section > of httpd's roll.sh signing the mod_fcgid release currently in test and > had to comment out the setting of args. I have tested this signing section a bit more with gpg (the part which differs and looks wrong) and think it can be simplified like this: http://people.apache.org/~fuankg/testsigning/testsigning.sh.txt please everyone who has some mins test this test script with/without username argument, f.e.: ./testsigning.sh httpd-2.2.14 and: ./testsigning.sh httpd-2.2.14 yourname and then report back if it works or not, and which tool and version you used (gpg or pgp - I bindly assumed in the script that pgp also knows of --version) thanks, Gün.
Re: [VOTE] release apr-1.4.2?
Guenter Knauf schrieb:
> BTW. while I was on that found that in httpd's roll.sh the gpg signing
> part looks wrong to me - therefore I kept the way how the signing user
> is handled same as was before in apr's release.h; but I believe it
> should be fixed for httpd's roll.sh:
>
> --- roll.sh.orig2010-01-25 00:41:13.0 +0100
> +++ roll.sh 2010-01-25 00:41:13.0 +0100
> @@ -179,10 +179,8 @@
>done
> # no pgp found - check for gpg
> elif test -x "${gpg}"; then
> - if test -z "${user}"; then
> -args="--default-key ${args}"
> - else
> -args="-u ${user} ${args}"
> + if test -n "${user}"; then
> +args="--default-key ${user}"
>fi
>for file; do
> if test -f "${file}"; then
>
> comments?
hmmm, just looked at man page from gpg 2.0.9, and from that it looks as
if httpd's roll.sh is right, and apr's release.sh was/is therefore wrong:
--default-key name
Use name as the default key to sign with. If this option is not
used, the default key is the first
key found in the secret keyring. Note that -u or --local-user
overrides this option.
Gün.
Re: [VOTE] release apr-1.4.2?
Hi Jeff.
Jeff Trawick schrieb:
> (I hope this doesn't start another long hash format thread) perhaps
> Guenter would want to update the apr roll script (if there is one) to
> massage the md5 sums as appropriate for future releases :)
>
> apr-1.4.2.tar.bz2: 4B 00 E8 F7 0C 06 78 93 D0 75 57 79 62 65 6B 35
hehe, thanks for the hint! Just copied the relevant part from httpd's
roll.sh over to apr's release.h - hopefully without introducing errors
:) This also now adds sha1 sums to apr releases.
BTW. while I was on that found that in httpd's roll.sh the gpg signing
part looks wrong to me - therefore I kept the way how the signing user
is handled same as was before in apr's release.h; but I believe it
should be fixed for httpd's roll.sh:
--- roll.sh.orig2010-01-25 00:41:13.0 +0100
+++ roll.sh 2010-01-25 00:41:13.0 +0100
@@ -179,10 +179,8 @@
done
# no pgp found - check for gpg
elif test -x "${gpg}"; then
- if test -z "${user}"; then
-args="--default-key ${args}"
- else
-args="-u ${user} ${args}"
+ if test -n "${user}"; then
+args="--default-key ${user}"
fi
for file; do
if test -f "${file}"; then
comments?
Gün.
Re: [discuss] Releasing pre-release APR
Hi, William A. Rowe Jr. schrieb: > In light of current events, here's a policy statement I'd like to propose > for consideration (just a discussion item at this point); > > The APR project strongly discourages any release of the APR software > with modifications of the API. This includes shipping ".0-dev" pre > release source code which has not yet been adopted in an official APR > release. Any such use is in violation of the Apache APR trademark. > > Private releases which include API modifications must not use the name > Apache APR and must not use the same publicly installed library and header > file names, or must not be installed or configured to be installed to the > platform-specific, conventional shared paths such as /usr/bin/, > /usr/include, > %windir%\system32 etc. Nothing in this policy precludes the application > of patches or bug fixes conforming to the released API, although the Apache > APR project strongly encourages authors to submit such fixes to the project. > > Snapshots of the current development trees are available for a short period > of time at http://svn.apache.org/snapshots/, these are not provided for > redistribution. Developers are encouraged to test against these snapshots > or the SVN development tree, propose API enhancements and patches to the > project, and participate in the API discussion. See the guidelines at; > http://apr.apache.org/patches.html for additional details. > > thoughts?/ I think we need a way to distribute alpha releases, just same as what we do with httpd. Now what I'm trying to understand is how we really break machines of alpha testers? First of all I would never test alpha releases on a production machine, but instead use a dedicated test box for such, and I also expect everyone else doing so; or that they use a virtual machine, or a chroot environment (if that works). Second how do we break things, and what do we break? The installed libraries are most likely not a problem since they have a new so name, so nothing links against them. The installed headers are more a problem, and we should think of a way to workaround this. Isnt it possible to use versioned directories like 'apr-1.4' instead of just 'apr'? Then we could probably have more than one installed apr version side by side ... Another thing could be to default to static libraries, and only build shared ones if explicitly specified as argument to configure ... Gün.
Re: svn commit: r892141 - in /apr/apr/trunk/include: apr.hnw arch/netware/apr_private.h
Bill, William A. Rowe Jr. schrieb: > Guenter Knauf wrote: > I didn't say that. Refer to the prior commit message when this API was > added, this seemed to be a reasonable assumption. well, I admit that my commit message might be a bit misleading; but if you look at the revision: http://svn.apache.org/viewvc?view=revision&revision=663941 it makes more sense: the "added usage of threadsafe getpass_r()" refers to this part of the commit: http://svn.apache.org/viewvc/apr/apr/trunk/passwd/apr_getpass.c?r1=663941&r2=663940&pathrev=663941 while "enabled HAVE_GETPASS_R for NetWare platform" refers to this: http://svn.apache.org/viewvc/apr/apr/trunk/include/arch/netware/apr_private.h?r1=663941&r2=663940&pathrev=663941 > And I'm glad to learn that. Reverting now, thanks for clarifying this. thanks, seen your commit. > Sorry that I haven't see such an email, obviously by design. If the topic > of that email was technical discussion, such as this proposed refactoring > of apu_config.h + apu.h into the apr_put the rivate.h + apr.h, or support for > autoconf vs msvc vs scons, such a discussion would belong on this list. agreed, and I mixed it up -- it was only a sentence I got posted in a private IRC chat :) > Including apr.h from apr_private.h would be one such workaround, sure. ok, thanks for committing. > From my grep of the source tree, the apu.hnw file was never referenced, > so I presume the NWGNUmakefile schema wasn't building apr-2.0 in the > first place ;-? well, I did adopt recently for APR/APU merge; and prior to your changes all compiled fine; but now after your corrections I guess it will do again ... :) -- I will get told in IRC soon ..., hehe ... Sorry, but currently I am on another project, and thats the reason why I didnt fix it self directly. Another breakage I was told about is also fixed now with Ruediger's commit 892718. thanks, Gün.
Re: svn commit: r892141 - in /apr/apr/trunk/include: apr.hnw arch/netware/apr_private.h
Bill, William A. Rowe Jr. schrieb: > Guenter Knauf wrote: >>> -#include >>> -#if (CURRENT_NDK_THRESHOLD < 70906) >>> -#define getpass_r getpassword >>> -#endif >> can you please explain too me why you think that NetWare doesnt need this >> check / define any longer, and why you removed it? > > It's been far more than 1.5 years since this was added to the NDK; 2.0 will > be released probably ~6 months from now, certainly not quickly. > > So the older getpassword isn't threadsafe, getpass_r is present, and as I I really wonder from what you take this knowledge? > understand it, only a handful of individuals actually compile (vs. use) the > apr library on Netware. Oh, so this then makes it valid to break it?? getpassword is identical to getpass_r and therefore 100% threadsafe; I worked with the NetWare core developer to introduce getpass_r in addition to getpassword in oder to have a standard API. Unfortunately it turned out that newer NDKs have issues on multiprocessor AMD installations which forces me to fall back to an older NDK which doesnt have getpass_r. > Supporting older architectures isn't a goal of apr 2.0, AIUI. Using the > modern toolchain seems like a prerequisite. not in this case. > What are your thoughts? Would you like me to restore this legacy workaround? > [Nothing in this refactoring is suggesting backport to 1.x]. yes, please. In addition your other changes = moving header includes into apr.h breaks compilation and requires to include apr.h before apr_private.h within at least two source files, or to include apr.h in apr_private.h. (I admit that I assume this from a mail I got privately with topic 'Does Wrowe own APR?', I did not yet test it self). Bill, even when we have CTR with APR its not ok when you touch platform-specific files without testing, nor talking with the folks who actually care about the affected platform -- nobody else does such, and if its expected from me that I compile and test changes if I touch Linux or Win32 files I think its only fair to expect same from you too. thanks, Gün.
Re: svn commit: r892141 - in /apr/apr/trunk/include: apr.hnw arch/netware/apr_private.h
Bill, wr...@apache.org schrieb: > Author: wrowe > Date: Fri Dec 18 05:20:42 2009 > New Revision: 892141 > > URL: http://svn.apache.org/viewvc?rev=892141&view=rev > Log: > Netware changes; always include netware.h/library.h for > whatever local functions or types would be aliased, in > a public manner, and drop very stale references to flavors > which should not be in common use. > > It's not necessary to exclude by platform, is it? > > Modified: > apr/apr/trunk/include/apr.hnw > apr/apr/trunk/include/arch/netware/apr_private.h > > Modified: apr/apr/trunk/include/arch/netware/apr_private.h > URL: > http://svn.apache.org/viewvc/apr/apr/trunk/include/arch/netware/apr_private.h?rev=892141&r1=892140&r2=892141&view=diff > == > --- apr/apr/trunk/include/arch/netware/apr_private.h (original) > +++ apr/apr/trunk/include/arch/netware/apr_private.h Fri Dec 18 05:20:42 2009 > @@ -16,28 +16,13 @@ > > /* > * Note: > - * This is the windows specific autoconf-like config file > - * which unix would create at build time. > + * This is the netware-specific autoconf-like config file > + * which unix creates at ./configure time. > */ > > -#ifdef NETWARE > - > #ifndef APR_PRIVATE_H > #define APR_PRIVATE_H > > -/* Include the public APR symbols, include our idea of the 'right' > - * subset of the Windows.h header. This saves us repetition. > - */ > -#include "apr.h" > - > -#include > -#include > -#include > -#include > -#include > -#include > -#include > - > /* Use this section to define all of the HAVE_FOO_H > * that are required to build properly. > */ > @@ -71,19 +56,10 @@ > #define HAVE_WRITEV 1 > > #define HAVE_GETPASS_R 1 > -/* > - * check for older NDKs which have only the getpassword() function. > - */ > -#include > -#if (CURRENT_NDK_THRESHOLD < 70906) > -#define getpass_r getpassword > -#endif can you please explain to me why you think that NetWare doesnt need this check / define any longer, and why you removed it? thanks, Gün.
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Joe Orton schrieb: > Snapshots of the APR and APR-util 1.4.x trees have been distributed by > as part of the httpd 2.3.4 alpha release. Should the APR project treat > those snapshots as "releases" for versioning purposes? In other words, > should we ensure future APR/APR-util releases maintain source and binary > backwards compatibility with those snapshots as required by the > versioning guidelines, http://apr.apache.org/versioning.html? > > Please vote: > [X] No Gün.
Re: Prepared to tag apr 1.4.0 [NOT -util!]
Hi, William A. Rowe Jr. schrieb: I see good responses to the list from Branko, Joe and Jeff (and thanks for the bugfix Branko), so I'll proceed with this tonight, we'll have the usual 72hr vote, and then let's start this discussion over about the much larger changes in apr-util 1.4 ;) I think we should take a look into the apr/apu tests first; Ruediger mentioned this a while ago that we only report failures, but dont bail out but instead try to use NULL pointers where we expect to have valid pointers ...; therefore failing tests produce segfaults on some platforms ... Gün.
Re: Netware support
Hi Laurent, Laurent Charmet schrieb: > I wish to know if Apr 1.3.x compile on Netware, yes. > or if a .nlm is available, yes, its part of the httpd 2.2.x distros. > or a faq/wiki to compile Apr for Netware. no, not really; there comes a docu with httpd. but this is now a little bit outdated since I changed a few things ... > We use Apr on many > platforms with success, but some customers want a port of our product on > Netware. It's not easy because we use a windows cross compiler targeting > Netware. what compiler do you use? CodeWarrior is what the build process is currently designed for, but it should be possible to compile with OpenWatcom or gcc too, provided you rewrite the makefiles / build system. If you have further questions you can directly contact me. Günter.
