Re: apr-util RPM - I'm stuck
Joe Orton wrote: It should just work. Otherwise: - no need to run auto* in the spec file for apr-util if not including a bunch of configure.in patches ;) - again add NOTICE to %doc and remove the history from the %changelog - %check can build and run testall - %files needs to be adjust for apr-util-1.pc I have applied the above changes and committed the spec file. The rpm build bombs out like so however: /bin/sh /usr/lib/apr/build/libtool --silent --mode=link gcc -pthread -O2 -g -pipe -march=i386 -mcpu=i686 -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/usr/src/redhat/BUILD/apr-util-1.0.0/include -I/usr/src/redhat/BUILD/apr-util-1.0.0/include/private -I/usr/include/apr-1-version-info 0:0:0-o testrmm -no-install testrmm.lo ../libaprutil-1.la -lldap -llber -ldb-4.1 /usr/lib/libexpat.la /usr/lib/libapr-1.la -lrt -lcrypt -lpthread -ldllibtool: link: warning: `-version-info' is ignored for programs gcc -O2 -g -pipe -march=i386 -mcpu=i686teststrmatch.c -o teststrmatch In file included from teststrmatch.c:16: testutil.h:16:23: apr_pools.h: No such file or directory In file included from teststrmatch.c:16: testutil.h:37: syntax error before '*' token testutil.h:37: warning: data definition has no type or storage class testutil.h:41: syntax error before apr_status_t teststrmatch.c:18:17: apr.h: No such file or directory teststrmatch.c:19:25: apr_general.h: No such file or directory teststrmatch.c:20:26: apr_strmatch.h: No such file or directory teststrmatch.c:26:22: apr_want.h: No such file or directory apr-devel is installed and the file apr_pools.h can be found at /usr/include/apr-1. In the file ./test/teststrmatch.c the headers are defined as: #include apr.h #include apr_general.h #include apr_strmatch.h Should they not be #include apr.h [etc] Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: apr-config and apr-1-config
At 04:55 PM 7/1/2004, Joe Orton wrote: On Thu, Jul 01, 2004 at 11:45:44PM +0200, Graham Leggett wrote: Joe Orton wrote: I've noticed that the most recent CVS of 1.0.0 installs both /usr/bin/apr-config, and /usr/bin/apr-1-config. Is this intentional? Yes, for the moment. How do you suggest the RPM should handle this? - at the moment installing a v0 RPM and a v1 RPM simultaneously will cause a conflict. Should we just leave it as is for now? Yes, just leave it for the moment I guess. If we leave it, and side-by-side installs are broken, this does not seem like a good initial release point for 1.0 :( Bill
Re: apr_finfo_t ctime field
William A. Rowe, Jr. wrote: As we approach APR 1.0 --- is it time to address the ambiguity between ctime, which is actually the inode file time stamp for unix, and the creation time stamp for win32? Persisting either ctime will propogate the confusion, I suggest splitting them into intime and crtime. Opinions? I'll offer an APR 1.0 patch tommorow based on feedback. Yes, yes, yes. Sorry I didn't notice this before. This would be a very good change. -- Brane
Re: apr-iconv 1.0
While we're on the subject of apr-iconv...
I'd like to reconsider the use of the APR_ICONV_PATH environment
variable. It turns out it's evil if you have to install two different
versions of apr_iconv in parallel. Also, on Windows, there's an issue of
different runtime libraries used by different compilers, and in
Subversion (or rather TortoiseSVN), we've seen instances where these can
interfere because of the use of this env. var.
Therefore I propose to change the way apr_iconv looks for the loadable
conversion modules in 1.0.
* Remove APR_ICONV_PATH
* On Unix, hardcode the path to the modules, using standard
configury. The default would be ${prefix}/lib/apr-iconv-${major},
or some such.
* On Windows, we'd calculate the path relative to the location of
the libapriconv-1.dll library; e.g.,
GerModuleFileName(0)/apr-iconv. Alternatively, the application
could pass in the root path, but we'd have to add an
initialization API -- we'd need something like that for the
statically-linked version.
Thoughts? I think 1.0 is an auspicious time to make this change,
especially if we declare apr-iconv to be an implementation detail of
apr_xlate.
William A. Rowe, Jr. wrote:
I'd like to suggest we hold our horses on apr-util and apr-iconv 1.0 - they
are seperate subsets with their own set of issues.
APR 1.0 does not require apr-util or apr-iconv, there is no dependency.
So no holdup of David's plans.
I'm proposing we switch around apr-iconv's interface to:
1) change typedef void *apr_icon_t; to an incomplete type, e.g.
typedef struct apr_icon_t apr_icon_t;
2) consistently use an apr_icon_t * or (for create) apr_icon_t **
as the arguments to the exposed functions.
3) reorder apr_iconv_open to pass the new apr_iconv_t ** placeholder
as the first not last arg, consistent with apr.
4) drop apr_pool_t argument from _close, that should use the same pool
as the associated _open.
I'm not suggesting using the apr_iconv_open()ed pool for xlate operations,
those may be in a frequently recycled pool, as oppsed to a long lived
pool used for apr_iconv_open (_close).
Of course, the apr_pool_t *p becomes a member of our internal apr_iconv_t
structure.
Thoughts?
Bill
-- Brane
apr-iconv RPM spec file + supporting changes
Hi all,
The attached patch attempts to bring apr_iconv more in line with the
build structure of apr and apr-util, and includes a spec file.
- The Makefile.in has been patched to prepend ${DESTDIR} onto the output
paths on make install.
- The ./buildconf has been altered to create the apr-iconv.spec file
from apr-iconv.spec.in in the same way it is done on apr and apr-util.
- A spec file has been added.
- build/get-version.sh has been added from apr/apr-util to be consistent
(and make the spec file work)
For some reason apr-iconv's make all target does not do anything on my
platform (Linux RHEL3), but this is a separate issue unrelated to the
changes above.
Comments?
Regards,
Graham
--
? Makefile
? apr-iconv.spec
? autom4te.cache
? build/get-version.sh
? build/rpm
? build/rules.mk
? ccs/Makefile
? ces/Makefile
? lib/Makefile
? util/Makefile
Index: Makefile.in
===
RCS file: /home/cvs/apr-iconv/Makefile.in,v
retrieving revision 1.6
diff -u -r1.6 Makefile.in
--- Makefile.in 26 Sep 2003 07:47:13 - 1.6
+++ Makefile.in 2 Jul 2004 00:11:13 -
@@ -26,25 +26,25 @@
MKINSTALLDIRS=$(abs_srcdir)/build/mkdir.sh
install:
- if [ ! -d $(includedir) ]; then \
- $(MKINSTALLDIRS) $(includedir); \
+ if [ ! -d $(DESTDIR)$(includedir) ]; then \
+ $(MKINSTALLDIRS) $(DESTDIR)$(includedir); \
fi; \
- cp -p $(abs_srcdir)/include/*.h $(includedir); \
- cp -p $(abs_srcdir)/lib/*.h $(includedir); \
- cp -p $(abs_builddir)/lib/*.h $(includedir); \
+ cp -p $(abs_srcdir)/include/*.h $(DESTDIR)$(includedir); \
+ cp -p $(abs_srcdir)/lib/*.h $(DESTDIR)$(includedir); \
+ cp -p $(abs_builddir)/lib/*.h $(DESTDIR)$(includedir); \
if [ ! -d $(lib_prefix) ]; then \
- $(MKINSTALLDIRS) $(lib_prefix); \
+ $(MKINSTALLDIRS) $(DESTDIR)$(lib_prefix); \
fi;
- (cd lib; $(LIBTOOL) --mode=install cp $(TARGET_LIB) $(lib_prefix))
- if [ ! -d $(libdir) ]; then \
- $(MKINSTALLDIRS) $(libdir); \
+ (cd lib; $(LIBTOOL) --mode=install cp $(TARGET_LIB) $(DESTDIR)$(lib_prefix))
+ if [ ! -d $(DESTDIR)$(libdir) ]; then \
+ $(MKINSTALLDIRS) $(DESTDIR)$(libdir); \
fi; \
- (cd ccs; for i in *.la; do $(LIBTOOL) --mode=install cp $$i $(libdir); done)
- (cd ces; for i in *.la; do $(LIBTOOL) --mode=install cp $$i $(libdir); done)
- if [ ! -d $(exec_prefix) ]; then \
- $(MKINSTALLDIRS) $(exec_prefix); \
+ (cd ccs; for i in *.la; do $(LIBTOOL) --mode=install cp $$i $(DESTDIR)$(libdir); done)
+ (cd ces; for i in *.la; do $(LIBTOOL) --mode=install cp $$i $(DESTDIR)$(libdir); done)
+ if [ ! -d $(DESTDIR)$(exec_prefix) ]; then \
+ $(MKINSTALLDIRS) $(DESTDIR)$(exec_prefix); \
fi; \
- (cd util; $(LIBTOOL) --mode=install cp iconv $(exec_prefix))
+ (cd util; $(LIBTOOL) --mode=install cp iconv $(DESTDIR)$(exec_prefix))
docs:
mkdir ./docs
Index: buildconf
===
RCS file: /home/cvs/apr-iconv/buildconf,v
retrieving revision 1.3
diff -u -r1.3 buildconf
--- buildconf 26 Sep 2003 07:47:13 - 1.3
+++ buildconf 2 Jul 2004 00:11:13 -
@@ -60,3 +60,21 @@
echo autoconf failed
exit 1
fi
+
+# Create RPM Spec file
+if [ -f `which cut` ]; then
+ echo rebuilding rpm spec file
+ ( REVISION=`build/get-version.sh all include/api_version.h API`
+VERSION=`echo $REVISION | cut -d- -s -f1`
+RELEASE=`echo $REVISION | cut -d- -s -f2`
+if [ x$VERSION = x ]; then
+ VERSION=$REVISION
+ RELEASE=1
+fi
+cat ./build/rpm/apr-iconv.spec.in | \
+sed -e s/API_VERSION/$VERSION/ \
+-e s/API_RELEASE/$RELEASE/ \
+ apr-iconv.spec )
+fi
+
+exit 0
%define apiver 1
Summary: Apache Portable Runtime ICONV Charset Conversion library
Name: apr-iconv
Version: API_VERSION
Release: API_RELEASE
License: Apache Software License
Group: System Environment/Libraries
URL: http://apr.apache.org/
Source0: %{name}-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
BuildPrereq: autoconf, libtool, doxygen, apr-devel = 0:{version}-{release}
BuildPrereq: perl
%description
The mission of the Apache Portable Runtime (APR) is to provide a
free library of C data structures and routines. This library
allows conversion between various charsets (character encoding schemes)
and the command line utility (iconv).
%package devel
Group: Development/Libraries
Summary: APR iconv library development kit
Requires: apr-iconv = %{version}-%{release}, apr-devel
#Requires: openldap-devel, db4-devel, expat-devel
%description devel
This package provides the support files which can be used to
build applications using the APR iconv library. The mission
of the Apache Portable Runtime (APR) is to provide a free
library of C data structures and routines.
%prep
%setup -q
%build
%configure --prefix=/usr \
--with-apr=%{_prefix} \
--includedir=%{_includedir}/apr-%{apiver} \
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make %{?_smp_mflags} install
Re: cvs commit: apr-util/build/rpm apr-util.spec.in
On Thu, Jul 01, 2004 at 10:45:06PM -, [EMAIL PROTECTED] wrote: ... +++ buildconf 1 Jul 2004 22:45:06 - 1.13 @@ -74,3 +74,20 @@ # Remove autoconf cache again rm -rf autom4te*.cache + +# Create RPM Spec file +if [ -f `which cut` ]; then + echo rebuilding rpm spec file + ( REVISION=`build/get-version.sh all include/apu_version.h APU` +VERSION=`echo $REVISION | cut -d- -s -f1` +RELEASE=`echo $REVISION | cut -d- -s -f2` +if [ x$VERSION = x ]; then + VERSION=$REVISION + RELEASE=1 +fi +cat ./build/rpm/apr-util.spec.in | \ +sed -e s/APU_VERSION/$VERSION/ \ +-e s/APU_RELEASE/$RELEASE/ \ + apr-util.spec ) +fi There is no need for the parens. That's just some extra baggage... Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: apr-config and apr-1-config
On Thu, Jul 01, 2004 at 05:38:34PM -0500, William A. Rowe, Jr. wrote: At 04:55 PM 7/1/2004, Joe Orton wrote: On Thu, Jul 01, 2004 at 11:45:44PM +0200, Graham Leggett wrote: Joe Orton wrote: I've noticed that the most recent CVS of 1.0.0 installs both /usr/bin/apr-config, and /usr/bin/apr-1-config. Is this intentional? Yes, for the moment. How do you suggest the RPM should handle this? - at the moment installing a v0 RPM and a v1 RPM simultaneously will cause a conflict. Should we just leave it as is for now? Yes, just leave it for the moment I guess. If we leave it, and side-by-side installs are broken, this does not seem like a good initial release point for 1.0 :( for the moment Joe said it *twice*. Was it that non-obvious? -- Greg Stein, http://www.lyra.org/
RE: remaining issues prior to 1.0?
While researching -ctime thoughts on list... (the entire thread might be enlightening to review for those who want some weekend reading :) Nearly a year ago, At 11:09 AM 6/25/2003, William A. Rowe, Jr. wrote: At 03:27 AM 6/25/2003, Marc M. Adkins wrote: * emulating the daemon/services foo within the Win32 port... but call it a 'nice to have' ... I will try to dedicate cycles to this over the summer. It's not exactly a showstopper. Can you expand on this? Are you talking about the usual Windows doesn't fork problem, emulating Windows services on Linux, getting process data (memory size, CPU %, etc.) or something else entirely? Just curious. although I would *really* like to deal with fork() ... it isn't practical (topic for another thread). I was restricting my focus to mapping Service 'Events' - Unix Signals, such as stop, start, shutdown, and marking Apache as 'already daemonized' when you start as a service. My only headache - I spent some time trying to find how we can safely assert that this WinNT/2K/XP/2003 process is running within the SCM (NT kernel service control manager). The short answer so far; it isn't very pretty. If we knew that, we would have APR react and start a service control thread, and then enter the NT event processing loop. On the Win9x side, implement daemonize_process to dismiss the window and mark the process as a 'psuedo-service'. Again, the hidden window we create to track Apache shutting down would trigger our 'unix' signals. so it looks on NT as apr_app_initialize() \- Running as service? \- Spin up service monitor and nt eventlog capture thread for stderr \- In service monitor thread, call into the SCM to be called back. \- Fix the argv[] based on the ServiceStart args. and then react to service control signals to the monitor thread based on our apr_signals() API. The only other two big thorns left in APR? File Create time isn't the same as the inode modified ctime. And we don't have an API to map ACL management between implementations, nor a way for Win32 to handle setuid(). In Win32's case, we need the account 'password' to deal with a setuid() request. The first is a real bug to fix, the second is perhaps beyond the scope of releasing 1.0. And in hind site - I don't see any reason we can't implement signals on win32 using the existing API. The ctime issue was brought up again and seems to be pretty important. And mapping ACL's on HPUX/Win32 and Linux/SE seems like it's own ballgame that would
Re: apr-iconv 1.0
At 06:41 PM 7/1/2004, Branko Čibej wrote: Thoughts? I think 1.0 is an auspicious time to make this change, especially if we declare apr-iconv to be an implementation detail of apr_xlate. The nifty bit is, if we declare apr-iconv to be an internal, implementation detail of apr_xlate - we are free to adopt your suggestions in 1.0.1 :) What is troubling us most, at this instant, are those things that change the API in such a way that developer's code would be broken fixing the problems of APR 1.0.0. As long as they are internal details (default pathing, etc) then we won't be troubled by getting it right a little later. Bill
Re: apr_finfo_t ctime field
Wow - and time is almost gone. Sorry this got no response until today, I'm not sure the powers that be really care for this change to go in until 2.0 at this point (it's an eliminated ctime and added crtime intime member of a transparent structure that's user-allocated.) Would be really nice to see one more bit of feedback before I commit such a change - amazes me we are the only two folks considering this issue. Sander Striker on 4/27/03 and Brian Pane the day after pondered this a while, but apparently we are the only two with any real concern about the ambiguity. Anyone else care to chime in? At 06:28 PM 7/1/2004, Branko Čibej wrote: William A. Rowe, Jr. wrote: As we approach APR 1.0 --- is it time to address the ambiguity between ctime, which is actually the inode file time stamp for unix, and the creation time stamp for win32? Persisting either ctime will propogate the confusion, I suggest splitting them into intime and crtime. Opinions? I'll offer an APR 1.0 patch tommorow based on feedback. Yes, yes, yes. Sorry I didn't notice this before. This would be a very good change. -- Brane
Re: apr-config and apr-1-config
At 07:29 PM 7/1/2004, Greg Stein wrote: On Thu, Jul 01, 2004 at 05:38:34PM -0500, William A. Rowe, Jr. wrote: If we leave it, and side-by-side installs are broken, this does not seem like a good initial release point for 1.0 :( for the moment Joe said it *twice*. Was it that non-obvious? No, it was obvious. However another party is rolling what he hopes to be the initial release on Friday, on his schedule. So if we *release* on Fri this would not be good. If it gets fixed next week and we can hold the release till next week, all would be lovely. Competing interests - and my message wasn't directed at Joe or Graham who have been working hard at the rpm/parallel install issues. It was directed at David who was hoping (expecting?) to roll an RC3 candidate today. Bill Bill
RE: remaining issues prior to 1.0?
At 02:24 AM 7/2/2004, William A. Rowe, Jr. wrote: [...] And in hind site - I don't see any reason we can't implement signals on win32 using the existing API. The ctime issue was brought up again and seems to be pretty important. And mapping ACL's on HPUX/Win32 and Linux/SE seems like it's own ballgame that would ... be it's own incremental version bump, e.g. 1.1 or whatnot. No need to hold up 1.0. Sorry, full of incomplete thoughts today - it's been a long week. Bill
Re: apr-iconv RPM spec file + supporting changes
On Fri, Jul 02, 2004 at 02:21:45AM +0200, Graham Leggett wrote: The attached patch attempts to bring apr_iconv more in line with the build structure of apr and apr-util, and includes a spec file. Dumb question - why a spec file? What platform do you want to run this on which doesn't have a native iconv()? You only need apr-iconv on platforms which don't have an iconv() at all. joe
Re: apr-iconv RPM spec file + supporting changes
Joe Orton wrote: Dumb question - why a spec file? What platform do you want to run this on which doesn't have a native iconv()? You only need apr-iconv on platforms which don't have an iconv() at all. Ok, I was not aware of that. Which platforms require iconv()? In other words, are there any Unix-like platforms out there (Solaris, Darwin, any others?) that might support RPM _and_ require iconv()? Regards, Graham --
apr-util RPM build failure: install.sh
Hi all, While trying to build the apr-util RPM, the build bombs out because it cannot find install.sh. To fix this should I: - Install install.sh into apr-config --installbuilddir in apr-devel, and then modify apr-util to look for install.sh inside apr-config --installbuilddir. - Install a copy of install.sh into the apr-util ./build directory. The second option seems to be the cleanest option, and more consistent. The build fails like so: + ./configure --host=i686-redhat-linux-gnu --build=i686-redhat-linux-gnu --target=i386-redhat-linux --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --with-apr=/usr --includedir=/usr/include/apr-1 --with-ldap --without-gdbm configure: error: cannot find install-sh or install.sh in build ./build error: Bad exit status from /var/tmp/rpm-tmp.39612 (%build) Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: apr-util RPM build failure: install.sh
On Fri, Jul 02, 2004 at 01:35:22PM +0200, Graham Leggett wrote: While trying to build the apr-util RPM, the build bombs out because it cannot find install.sh. To fix this should I: - Install install.sh into apr-config --installbuilddir in apr-devel, and then modify apr-util to look for install.sh inside apr-config --installbuilddir. - Install a copy of install.sh into the apr-util ./build directory. The apr-util ./buildconf already does this second option. joe
Re: apr-util RPM build failure: install.sh
Joe Orton wrote: - Install install.sh into apr-config --installbuilddir in apr-devel, and then modify apr-util to look for install.sh inside apr-config --installbuilddir. - Install a copy of install.sh into the apr-util ./build directory. The apr-util ./buildconf already does this second option. I don't follow: The second option was that I manually add install.sh to the apr-util/build directory (buildconf not being involved in this at all). There is no install.sh file there right now. As it stands now, when I build apr-util, it doesn't look for install.sh in apr-config --installbuilddir. Only when I add the install.sh file to apr-util/build does it work. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: apr-util RPM build failure: install.sh
On Fri, Jul 02, 2004 at 01:51:04PM +0200, Graham Leggett wrote: Joe Orton wrote: - Install install.sh into apr-config --installbuilddir in apr-devel, and then modify apr-util to look for install.sh inside apr-config --installbuilddir. - Install a copy of install.sh into the apr-util ./build directory. The apr-util ./buildconf already does this second option. I don't follow: The second option was that I manually add install.sh to the apr-util/build directory (buildconf not being involved in this at all). There is no install.sh file there right now. If there isn't, that's a problem in the tarball you're using. buildconf must have been run *before* creating the tarball, that's part of the release process. There is a build/install.sh in the apr-util-1.0.rc2.tar.gz which David posted. joe
Re: apr-util RPM build failure: install.sh
Joe Orton wrote: If there isn't, that's a problem in the tarball you're using. buildconf must have been run *before* creating the tarball, that's part of the release process. There is a build/install.sh in the apr-util-1.0.rc2.tar.gz which David posted. Was it checked in correctly? [EMAIL PROTECTED] apr-util-1.0.0]$ cvs -z9 update build/install.sh Password: cvs server: nothing known about build/install.sh The above directory contains HEAD. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: apr-iconv RPM spec file + supporting changes
On Fri, Jul 02, 2004 at 11:17:00AM +0200, Graham Leggett wrote: Joe Orton wrote: Dumb question - why a spec file? What platform do you want to run this on which doesn't have a native iconv()? You only need apr-iconv on platforms which don't have an iconv() at all. Ok, I was not aware of that. Which platforms require iconv()? In other words, are there any Unix-like platforms out there (Solaris, Darwin, any others?) that might support RPM _and_ require iconv()? Old Unixes and non-Unixes don't have iconv(), so yes, there is certainly a set of platforms on which RPM will build but there is no native iconv(). It's not a big deal, just so long as you're aware that you probably don't *need* apr-iconv, and it's probably better to use the native iconv() where available. Regards, joe
apr-util build error - xlate.c
Hi all, While trying to build apr-util from HEAD (as an RPM), the build bombs out like so: /bin/sh /usr/lib/apr/build-1/libtool --silent --mode=compile gcc -pthread -O2 -g -pipe -march=i386 -mcpu=i686 -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/usr/src/redhat/BUILD/apr-util-1.0.0/include -I/usr/src/redhat/BUILD/apr-util-1.0.0/include/private -I/usr/include/apr-1-o xlate/xlate.lo -c xlate/xlate.c touch xlate/xlate.lo xlate/xlate.c:61: syntax error before iconv_t xlate/xlate.c:61: warning: no semicolon at end of struct or union xlate/xlate.c: In function `apr_xlate_cleanup': xlate/xlate.c:91: dereferencing pointer to incomplete type xlate/xlate.c:91: `iconv_t' undeclared (first use in this function) xlate/xlate.c:91: (Each undeclared identifier is reported only once xlate/xlate.c:91: for each function it appears in.) xlate/xlate.c:92: dereferencing pointer to incomplete type xlate/xlate.c: In function `check_sbcs': xlate/xlate.c:119: dereferencing pointer to incomplete type xlate/xlate.c:129: dereferencing pointer to incomplete type xlate/xlate.c:129: dereferencing pointer to incomplete type xlate/xlate.c:130: dereferencing pointer to incomplete type xlate/xlate.c:131: dereferencing pointer to incomplete type xlate/xlate.c:132: dereferencing pointer to incomplete type It bombs out here: #if APU_HAVE_ICONV iconv_t ich; --- #elif APU_HAVE_APR_ICONV The platform is Linux (RHEL3). Anyone know what might be causing this, or is it something stupid I've done? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: apr-util build error - xlate.c
On Fri, Jul 02, 2004 at 02:34:22PM +0200, Graham Leggett wrote: Hi all, While trying to build apr-util from HEAD (as an RPM), the build bombs out like so: /bin/sh /usr/lib/apr/build-1/libtool --silent --mode=compile gcc -pthread -O2 -g -pipe -march=i386 -mcpu=i686 -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/usr/src/redhat/BUILD/apr-util-1.0.0/include -I/usr/src/redhat/BUILD/apr-util-1.0.0/include/private -I/usr/include/apr-1-o xlate/xlate.lo -c xlate/xlate.c touch xlate/xlate.lo xlate/xlate.c:61: syntax error before iconv_t iconv.h hasn't been included... probably some configure screwup. Do you have apr-iconv installed? If so try removing it and building again.
Re: apr-iconv RPM spec file + supporting changes
Joe Orton wrote: Old Unixes and non-Unixes don't have iconv(), so yes, there is certainly a set of platforms on which RPM will build but there is no native iconv(). It's not a big deal, just so long as you're aware that you probably don't *need* apr-iconv, and it's probably better to use the native iconv() where available. Cool. I am running into a hassle testing this though. On my platform (Linux) apr-iconv isn't needed, and so make does nothing. This causes make install to bomb out when an attempt is made to build an RPM. What would be far more user friendly is if a suitable friendly error message (eg this platform already supports iconv(), and so apr-iconv is not required and cannot be built) be output on make so that it doesn't fail in a strange way. Any ideas on how to achieve this? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
testall.c is in the attic?
I am trying to build testall.dsw on Windows XP. testall.dsw fails to build because testall.obj isn't available. Is the test suite available in the HEAD of the branch or APR_1_0_RC2? testall.c is in the Attic. Configuration: testall - Win32 Debug Microsoft (R) Program Maintenance Utility Version 6.00.9782.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include globalmutexchild.c globalmutexchild.c link /nologo globalmutexchild.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include sendfile.c sendfile.c link /nologo sendfile.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include proc_child.c proc_child.c link /nologo /debug /subsystem:console /machine:I386 proc_child.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include tryread.c tryread.c link /nologo tryread.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include occhild.c occhild.c link /nologo occhild.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include sockchild.c sockchild.c link /nologo sockchild.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testlockperf.c testlockperf.c link /nologo testlockperf.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testshmproducer.c testshmproducer.c link /nologo testshmproducer.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testshmconsumer.c testshmconsumer.c link /nologo testshmconsumer.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testmutexscope.c testmutexscope.c link /nologo testmutexscope.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib NMAKE : fatal error U1073: don't know how to make 'testall.obj' Stop. Error executing NMAKE. testall.exe - 1 error(s), 0 warning(s) © 2004 OpenLink Financial Copyright in this message and any attachments remains with us. It is confidential and may be legally privileged. If this message is not intended for you it must not be read, copied or used by you or disclosed to anyone else. Please advise the sender immediately if you have received this message in error. Although this message and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Open Link Financial, Inc. for any loss or damage in any way arising from its use.
Re: testall.c is in the attic?
testall.c was replaced when the testsuite moved to abts. ABTS does the same thing as testall, only much cleaner. Ryan On Fri, 2 Jul 2004, Ed Holyat wrote: I am trying to build testall.dsw on Windows XP. testall.dsw fails to buil= d because testall.obj isn't available. Is the test suite available in the HEAD of the branch or APR_1_0_RC2? testall.c is in the Attic. Configuration: testall - Win32 Debug-= --- Microsoft (R) Program Maintenance Utility Version 6.00.9782.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include globalmutexchild.c globalmutexchild.c link /nologo globalmutexchild.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include sendfile.c sendfile.c link /nologo sendfile.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include proc_child.c proc_child.c link /nologo /debug /subsystem:console /machine:I386 proc_child.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.= lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include tryread.c tryread.c link /nologo tryread.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include occhild.c occhild.c link /nologo occhild.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include sockchild.c sockchild.c link /nologo sockchild.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testlockperf.c testlockperf.c link /nologo testlockperf.obj ..\LibD\apr-1.lib kernel32.lib advapi32.li= b ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testshmproducer.c testshmproducer.c link /nologo testshmproducer.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testshmconsumer.c testshmconsumer.c link /nologo testshmconsumer.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testmutexscope.c testmutexscope.c link /nologo testmutexscope.obj ..\LibD\apr-1.lib kernel32.lib advapi32.= lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib NMAKE : fatal error U1073: don't know how to make 'testall.obj' Stop. Error executing NMAKE. testall.exe - 1 error(s), 0 warning(s) =A9 2004 OpenLink Financial Copyright in this message and any attachments remains with us. It is confidential and may be legally privileged. If this message is not intended for you it must not be read, copied or used by you or disclosed to anyone else. Please advise the sender immediately if you have received this message in error. Although this message and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Open Link Financial, Inc. for any loss or damage in any way arising from its use.
RE: testall.c is in the attic?
How Do I build it on Windows? -Original Message- From: Ryan Bloom [mailto:[EMAIL PROTECTED] Sent: Friday, July 02, 2004 11:10 AM To: dev@apr.apache.org Subject: Re: testall.c is in the attic? testall.c was replaced when the testsuite moved to abts. ABTS does the same thing as testall, only much cleaner. Ryan On Fri, 2 Jul 2004, Ed Holyat wrote: I am trying to build testall.dsw on Windows XP. testall.dsw fails to buil= d because testall.obj isn't available. Is the test suite available in the HEAD of the branch or APR_1_0_RC2? testall.c is in the Attic. Configuration: testall - Win32 Debug-= --- Microsoft (R) Program Maintenance Utility Version 6.00.9782.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include globalmutexchild.c globalmutexchild.c link /nologo globalmutexchild.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include sendfile.c sendfile.c link /nologo sendfile.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include proc_child.c proc_child.c link /nologo /debug /subsystem:console /machine:I386 proc_child.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.= lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include tryread.c tryread.c link /nologo tryread.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include occhild.c occhild.c link /nologo occhild.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include sockchild.c sockchild.c link /nologo sockchild.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testlockperf.c testlockperf.c link /nologo testlockperf.obj ..\LibD\apr-1.lib kernel32.lib advapi32.li= b ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testshmproducer.c testshmproducer.c link /nologo testshmproducer.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testshmconsumer.c testshmconsumer.c link /nologo testshmconsumer.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testmutexscope.c testmutexscope.c link /nologo testmutexscope.obj ..\LibD\apr-1.lib kernel32.lib advapi32.= lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib NMAKE : fatal error U1073: don't know how to make 'testall.obj' Stop. Error executing NMAKE. testall.exe - 1 error(s), 0 warning(s) =A9 2004 OpenLink Financial Copyright in this message and any attachments remains with us. It is confidential and may be legally privileged. If this message is not intended for you it must not be read, copied or used by you or disclosed to anyone else. Please advise the sender immediately if you have received this message in error. Although this message and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Open Link Financial, Inc. for any loss or damage in any way arising from its use. © 2004 OpenLink Financial Copyright in this message and any attachments remains with us. It is confidential and may be legally privileged. If this message is not intended for you it must not be read, copied or used by you or disclosed to anyone else. Please advise the sender immediately if you have received this message in error. Although this message and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Open Link Financial, Inc. for any loss or
Re: testall.c is in the attic?
I don't build using the dsw on Windows, so I don't know. I always use Makefile.win. So, I just type: nmake /f Makefile.win and it works. We should collapse the build system to have just a single way to build the tests on Windows. Ryan On Fri, 2 Jul 2004 11:14:06 -0400 , Ed Holyat [EMAIL PROTECTED] wrote: How Do I build it on Windows? -Original Message- From: Ryan Bloom [mailto:[EMAIL PROTECTED] Sent: Friday, July 02, 2004 11:10 AM To: dev@apr.apache.org Subject: Re: testall.c is in the attic? testall.c was replaced when the testsuite moved to abts. ABTS does the same thing as testall, only much cleaner. Ryan On Fri, 2 Jul 2004, Ed Holyat wrote: I am trying to build testall.dsw on Windows XP. testall.dsw fails to buil= d because testall.obj isn't available. Is the test suite available in the HEAD of the branch or APR_1_0_RC2? testall.c is in the Attic. Configuration: testall - Win32 Debug-= --- Microsoft (R) Program Maintenance Utility Version 6.00.9782.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include globalmutexchild.c globalmutexchild.c link /nologo globalmutexchild.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include sendfile.c sendfile.c link /nologo sendfile.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include proc_child.c proc_child.c link /nologo /debug /subsystem:console /machine:I386 proc_child.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.= lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include tryread.c tryread.c link /nologo tryread.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include occhild.c occhild.c link /nologo occhild.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include sockchild.c sockchild.c link /nologo sockchild.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testlockperf.c testlockperf.c link /nologo testlockperf.obj ..\LibD\apr-1.lib kernel32.lib advapi32.li= b ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testshmproducer.c testshmproducer.c link /nologo testshmproducer.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testshmconsumer.c testshmconsumer.c link /nologo testshmconsumer.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testmutexscope.c testmutexscope.c link /nologo testmutexscope.obj ..\LibD\apr-1.lib kernel32.lib advapi32.= lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib NMAKE : fatal error U1073: don't know how to make 'testall.obj' Stop. Error executing NMAKE. testall.exe - 1 error(s), 0 warning(s) =A9 2004 OpenLink Financial Copyright in this message and any attachments remains with us. It is confidential and may be legally privileged. If this message is not intended for you it must not be read, copied or used by you or disclosed to anyone else. Please advise the sender immediately if you have received this message in error. Although this message and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Open Link Financial, Inc. for any loss or damage in any way arising from its use. © 2004 OpenLink Financial Copyright in this message and any attachments remains
RE: testall.c is in the attic?
It really doesn't matter, it is still looking for testall.obj. the dsw uses nmake /f Makefile.win all I am up to date from the APR_1_0_RC2 branch and I also tried HEAD. Am I missing something? C:\local\src\apr\APR_1_0_RC2\apr\testnmake /f Makefile.win Microsoft (R) Program Maintenance Utility Version 6.00.9782.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include globalmutexchild.c globalmutexchild.c link /nologo globalmutexchild.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include sendfile.c sendfile.c link /nologo sendfile.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include proc_child.c proc_child.c link /nologo /debug /subsystem:console /machine:I386 proc_child.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include tryread.c tryread.c link /nologo tryread.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include occhild.c occhild.c link /nologo occhild.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include sockchild.c sockchild.c link /nologo sockchild.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testlockperf.c testlockperf.c link /nologo testlockperf.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testshmproducer.c testshmproducer.c link /nologo testshmproducer.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testshmconsumer.c testshmconsumer.c link /nologo testshmconsumer.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib cl /nologo /c /MDd /W3 /GX /Zi /Od /DWIN32 /D_DEBUG /D_WINDOWS /DAPR_DECLARE_STATIC /I ../include testmutexscope.c testmutexscope.c link /nologo testmutexscope.obj ..\LibD\apr-1.lib kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib NMAKE : fatal error U1073: don't know how to make 'testall.obj' Stop. C:\local\src\apr\APR_1_0_RC2\apr\test cvs server: Examining . === File: .cvsignoreStatus: Up-to-date Working revision:1.52 Repository revision: 1.52/home/cvspublic/apr/test/.cvsignore,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) === File: MakeWin32Make.awk Status: Up-to-date Working revision:1.3 Repository revision: 1.3 /home/cvspublic/apr/test/MakeWin32Make.awk,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) === File: Makefile.in Status: Up-to-date Working revision:1.163 Repository revision: 1.163 /home/cvspublic/apr/test/Makefile.in,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) === File: Makefile.win Status: Up-to-date Working revision:1.21 Repository revision: 1.21/home/cvspublic/apr/test/Makefile.win,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) === File: NWGNUmakefile Status: Up-to-date Working revision:1.5 Repository revision: 1.5 /home/cvspublic/apr/test/NWGNUmakefile,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) === File: READMEStatus: Up-to-date Working revision:1.6 Repository revision: 1.6
Re: apr-config and apr-1-config
At 07:29 PM 7/1/2004, Greg Stein wrote: On Thu, Jul 01, 2004 at 05:38:34PM -0500, William A. Rowe, Jr. wrote: If we leave it, and side-by-side installs are broken, this does not seem like a good initial release point for 1.0 :( for the moment Joe said it *twice*. Was it that non-obvious? No, it was obvious. However another party is rolling what he hopes to be the initial release on Friday, on his schedule. So if we *release* on Fri this would not be good. If it gets fixed next week and we can hold the release till next week, all would be lovely. Competing interests - and my message wasn't directed at Joe or Graham Damn. Competing interests? So, no-one else wants to get 1.0 out teh door. Wow, must have been in dream land for a long, long time then... who have been working hard at the rpm/parallel install issues. It was directed at David who was hoping (expecting?) to roll an RC3 candidate today. Well, some form of explanation of the above would be more helpful than cryptic comments. 1/10 on helpfulness. david
Re: apr-util 1.0 rc2
David Reid wrote: Tagged! The rpm spec files for apr and apr-util are now working, can the relevant files be included inside RC3? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: apr-util 1.0 rc2
David Reid wrote: Tagged! The rpm spec files for apr and apr-util are now working, can the relevant files be included inside RC3? Having just gotten home (to a torrent of emails as per usual) and seen that apparently there is more dissent about even tagging RC3 today... In simple terms, I see no problem with including them at all. When RC3 is rolled I'll include them. david
Re: apr-config and apr-1-config
David Reid [EMAIL PROTECTED] writes: [...] Damn. Competing interests? So, no-one else wants to get 1.0 out teh door. Wow, must have been in dream land for a long, long time then... The s/apr-config/apr-1-config/ is certainly going to generate extra work for apr applications that currently build fine with either 0.9 or HEAD. For example apxs and all apxs-dependent apache modules that want to support httpd-2.2 will need to use something better than APR_CONFIG=`$APXS -q APR_BINDIR`/apr-config However, IMO it's absolutely worth the extra effort because the name change will guarantee httpd-2.0's apxs still supplies such modules with the right apr lib. -- Joe Schaefer
Re: apr-config and apr-1-config
On Fri, 2004-07-02 at 12:52 -0400, Joe Schaefer wrote: David Reid [EMAIL PROTECTED] writes: [...] Damn. Competing interests? So, no-one else wants to get 1.0 out teh door. Wow, must have been in dream land for a long, long time then... The s/apr-config/apr-1-config/ is certainly going to generate extra work for apr applications that currently build fine with either 0.9 or HEAD. For example apxs and all apxs-dependent apache modules that want to support httpd-2.2 will need to use something better than APR_CONFIG=`$APXS -q APR_BINDIR`/apr-config However, IMO it's absolutely worth the extra effort because the name change will guarantee httpd-2.0's apxs still supplies such modules with the right apr lib. This is a separate issue for APXS. It needs another -q item added in 2.1 telling us the name of the binary, not just the directory. (to allow a parallel install of APR, and possibly httpd-2.0/2.1) -Paul Querna
Re: apr-config and apr-1-config
At 11:20 AM 7/2/2004, you wrote: At 07:29 PM 7/1/2004, Greg Stein wrote: On Thu, Jul 01, 2004 at 05:38:34PM -0500, William A. Rowe, Jr. wrote: If we leave it, and side-by-side installs are broken, this does not seem like a good initial release point for 1.0 :( for the moment Joe said it *twice*. Was it that non-obvious? No, it was obvious. However another party is rolling what he hopes to be the initial release on Friday, on his schedule. So if we *release* on Fri this would not be good. If it gets fixed next week and we can hold the release till next week, all would be lovely. Competing interests - and my message wasn't directed at Joe or Graham Damn. Competing interests? So, no-one else wants to get 1.0 out teh door. Wow, must have been in dream land for a long, long time then... Speed/Schedule of releasing 1.0 v.s. Completeness/Interoperability w/ 0.9. I for one am glad you've put folks feet to the fire so to speak, and laid out an ambitious plan for release of 1.0 this month :) Sometimes, until you try to implement, what seemed just fine in a build system turns out to be ineffective when confronted with rolling usable rpm's, deploying side by side with previous versions, etc. It wasn't until apr-1.0 that the apr/httpd side has ever really considered side-by-side installation issues, since we need the legacy 0.9 for some time to support httpd 2.0, and will need 1.0 installed and ready for httpd 2.1+, svn, jakarta-jk2 and so forth. Graham's RPM efforts have put a magnifying glass to every open parallel install issue - I think it's wonderful that he created the perfect example case whether he intended to, or not :) who have been working hard at the rpm/parallel install issues. It was directed at David who was hoping (expecting?) to roll an RC3 candidate today. Well, some form of explanation of the above would be more helpful than cryptic comments. Sorry, it was my reaction to Greg's comments - which read (to me) that he was saying yes - table this for now, release 1.0.0, install and clobber the existing shared apr 0.9.5 install, then figure out how to get it right with release 1.0.1. That concerned me. 1/10 on helpfulness. I believe, with the possible exception of apr_finfo_t::ctime (and still asking for feedback), that APR is code-complete API stable for 1.0. With apr-iconv designated as a mutable implementation detail of the public apr_xlate interface, that is not an issue either. I spent no time in apr-util so I really don't have an opinion either way. If Graham's efforts, with Joe's useful feedback, produces a build system which cleanly lets 0.9 and 1.0 (and future releases) coexist, I'm satisfied we finished APR 1.0. I'd be very happy if we left apr-config alone (as 0.9), created apr-1-config or apr-1.0-config with a symlink named apr-1-config, and let the consumers attempt to use apr-[n..1]-config down to apr-config, based on what THEIR application is targeted at and capable of supporting. The version argument solution to apr-config also sounds like it could solve the problem. Bill
Re: apr-config and apr-1-config
William A. Rowe, Jr. wrote: If Graham's efforts, with Joe's useful feedback, produces a build system which cleanly lets 0.9 and 1.0 (and future releases) coexist, I'm satisfied we finished APR 1.0. I've just tried to install an RPM of httpd 2.0.50 onto a system that already has RPMs of apr-1.0.0 and apr-util-1.0.0 installed, and the httpd RPM installs cleanly with no conflicts. The httpd RPM contains httpd + apr-0.9 + apr-util-0.9 rolled up into a single RPM. A further question though - is it worth making the effort to make RPMs for apr (and apr-util) v0.9, or is it sufficient to leave it as it is now: httpd v2.0.x includes a rolled up version of apr v0.9 in a single package. In other words, what other projects apart from httpd are using apr v0.9 and not apr v1.0? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: apr-iconv 1.0
William A. Rowe, Jr. wrote: At 06:41 PM 7/1/2004, Branko ibej wrote: Thoughts? I think 1.0 is an auspicious time to make this change, especially if we declare apr-iconv to be an implementation detail of apr_xlate. The nifty bit is, if we declare apr-iconv to be an internal, implementation detail of apr_xlate - we are free to adopt your suggestions in 1.0.1 :) That's true. What is troubling us most, at this instant, are those things that change the API in such a way that developer's code would be broken fixing the problems of APR 1.0.0. As long as they are internal details (default pathing, etc) then we won't be troubled by getting it right a little later. Then I suggest we really do close off apr-iconv. This means the apr-iconv headers shouldn't get installed, right? Among other things. -- Brane
Re: apr-iconv 1.0
At 12:46 PM 7/2/2004, Branko Äibej wrote: William A. Rowe, Jr. wrote: At 06:41 PM 7/1/2004, Branko Ãibej wrote: Thoughts? I think 1.0 is an auspicious time to make this change, especially if we declare apr-iconv to be an implementation detail of apr_xlate. The nifty bit is, if we declare apr-iconv to be an internal, implementation detail of apr_xlate - we are free to adopt your suggestions in 1.0.1 :) That's true. Then I suggest we really do close off apr-iconv. This means the apr-iconv headers shouldn't get installed, right? Among other things. ++1 to that idea, as long as apr-util internally gets the -I / -L paths to the build of apr-iconv, and they don't persist in the apu-1-config file. Bill
Re: FreeBSD APR patch for threads
On Jul 2, 2004, at 12:43 PM, Craig Rodrigues wrote: I maintain the port for apr in the FreeBSD ports collection. The latest version of FreeBSD's implementation of threads is *MUCH* more stable than in earlier versions of FreeBSD. To compile a program for threads, all you need to do is link with -lpthread. -D_REENTRANT and -D_THREAD_SAFE are no longer needed and have been entirely removed from FreeBSD header files. This is great news! I have been maintaining a variation of this patch which I would like to submit back to the APR repository. This patch basically does the following: - for the latest versions of FreeBSD, puts in the correct flags for linking in threads - for older versions of FreeBSD, i.e FreeBSD 4.x, disables threads by default (which is what APR does right now) I'm +1 for this patch in concept, but I don't have a FreeBSD machine with an osreldate recent enough to test this patch. I've been testing this patch for some time now. Would it be possible to go in for APR 1.0? Well, let's get it into HEAD and get some feedback on it first. -aaron
[PATCH APR 1.0] crtime v.s. intime
Here's the patch for those interested, which splits ctime into crtime
and intime.
An interesting side effect, neither crtime nor intime stay part of the
APR_FINFO_MIN set of information - one bit or the other would be
toggled.
BillIndex: file_io/netware/filestat.c
===
RCS file: /home/cvs/apr/file_io/netware/filestat.c,v
retrieving revision 1.34
diff -u -r1.34 filestat.c
--- file_io/netware/filestat.c 29 Mar 2004 17:53:28 - 1.34
+++ file_io/netware/filestat.c 2 Jul 2004 20:01:09 -
@@ -55,8 +55,9 @@
static void fill_out_finfo(apr_finfo_t *finfo, struct stat *info,
apr_int32_t wanted)
{
-finfo-valid = APR_FINFO_MIN | APR_FINFO_IDENT | APR_FINFO_NLINK
-| APR_FINFO_OWNER | APR_FINFO_PROT;
+finfo-valid = APR_FINFO_MIN | APR_FINFO_INTIME
+ | APR_FINFO_IDENT | APR_FINFO_NLINK
+ | APR_FINFO_OWNER | APR_FINFO_PROT;
finfo-protection = apr_unix_mode2perms(info-st_mode);
finfo-filetype = filetype_from_mode(info-st_mode);
finfo-user = info-st_uid;
@@ -67,7 +68,8 @@
finfo-nlink = info-st_nlink;
apr_time_ansi_put(finfo-atime, info-st_atime.tv_sec);
apr_time_ansi_put(finfo-mtime, info-st_mtime.tv_sec);
-apr_time_ansi_put(finfo-ctime, info-st_ctime.tv_sec);
+/* XXX Is this intime (or actually cr time?) */
+apr_time_ansi_put(finfo-intime, info-st_ctime.tv_sec);
/* ### needs to be revisited
* if (wanted APR_FINFO_CSIZE) {
* finfo-csize = info-st_blocks * 512;
Index: file_io/os2/dir.c
===
RCS file: /home/cvs/apr/file_io/os2/dir.c,v
retrieving revision 1.36
diff -u -r1.36 dir.c
--- file_io/os2/dir.c 13 Feb 2004 09:38:24 - 1.36
+++ file_io/os2/dir.c 2 Jul 2004 20:01:10 -
@@ -101,12 +101,12 @@
thedir-entry.ftimeLastWrite);
apr_os2_time_to_apr_time(finfo-atime, thedir-entry.fdateLastAccess,
thedir-entry.ftimeLastAccess);
-apr_os2_time_to_apr_time(finfo-ctime, thedir-entry.fdateCreation,
+apr_os2_time_to_apr_time(finfo-crtime, thedir-entry.fdateCreation,
thedir-entry.ftimeCreation);
finfo-name = thedir-entry.achName;
finfo-valid = APR_FINFO_NAME | APR_FINFO_MTIME | APR_FINFO_ATIME |
-APR_FINFO_CTIME | APR_FINFO_TYPE | APR_FINFO_SIZE |
+APR_FINFO_CRTIME | APR_FINFO_TYPE | APR_FINFO_SIZE |
APR_FINFO_CSIZE;
return APR_SUCCESS;
Index: file_io/os2/filestat.c
===
RCS file: /home/cvs/apr/file_io/os2/filestat.c,v
retrieving revision 1.41
diff -u -r1.41 filestat.c
--- file_io/os2/filestat.c 22 May 2004 07:26:10 - 1.41
+++ file_io/os2/filestat.c 2 Jul 2004 20:01:10 -
@@ -42,11 +42,11 @@
fstatus-ftimeLastAccess );
apr_os2_time_to_apr_time(finfo-mtime, fstatus-fdateLastWrite,
fstatus-ftimeLastWrite );
-apr_os2_time_to_apr_time(finfo-ctime, fstatus-fdateCreation,
+apr_os2_time_to_apr_time(finfo-crtime, fstatus-fdateCreation,
fstatus-ftimeCreation );
finfo-valid = APR_FINFO_TYPE | APR_FINFO_PROT | APR_FINFO_SIZE
| APR_FINFO_CSIZE | APR_FINFO_MTIME
- | APR_FINFO_CTIME | APR_FINFO_ATIME | APR_FINFO_LINK;
+ | APR_FINFO_CRTIME | APR_FINFO_ATIME | APR_FINFO_LINK;
}
Index: file_io/unix/filestat.c
===
RCS file: /home/cvs/apr/file_io/unix/filestat.c,v
retrieving revision 1.72
diff -u -r1.72 filestat.c
--- file_io/unix/filestat.c 27 Mar 2004 13:11:17 - 1.72
+++ file_io/unix/filestat.c 2 Jul 2004 20:01:10 -
@@ -69,7 +69,8 @@
static void fill_out_finfo(apr_finfo_t *finfo, struct_stat *info,
apr_int32_t wanted)
{
-finfo-valid = APR_FINFO_MIN | APR_FINFO_IDENT | APR_FINFO_NLINK
+finfo-valid = APR_FINFO_MIN | APR_FINFO_INTIME
+ | APR_FINFO_IDENT | APR_FINFO_NLINK
| APR_FINFO_OWNER | APR_FINFO_PROT;
finfo-protection = apr_unix_mode2perms(info-st_mode);
finfo-filetype = filetype_from_mode(info-st_mode);
@@ -81,7 +82,7 @@
finfo-nlink = info-st_nlink;
apr_time_ansi_put(finfo-atime, info-st_atime);
apr_time_ansi_put(finfo-mtime, info-st_mtime);
-apr_time_ansi_put(finfo-ctime, info-st_ctime);
+apr_time_ansi_put(finfo-intime, info-st_ctime);
/* ### needs to be revisited
* if (wanted APR_FINFO_CSIZE) {
* finfo-csize = info-st_blocks * 512;
Index: file_io/win32/filestat.c
===
RCS file: /home/cvs/apr/file_io/win32/filestat.c,v
