Re: cvs commit: apr/user/unix .cvsignore Makefile.in
On Wed, Jan 10, 2001 at 02:52:05PM -0500, Jeff Trawick wrote: > Jeff Trawick <[EMAIL PROTECTED]> writes: > > > [EMAIL PROTECTED] writes: > > > > > gstein 01/01/09 03:06:29 > > > > > > Libtool-ize APR. > > > Index: Makefile.in > > > === > > > RCS file: /home/cvs/apr/shmem/unix/Makefile.in,v > > > retrieving revision 1.14 > > > retrieving revision 1.15 > > > diff -u -u -r1.14 -r1.15 > > > --- Makefile.in 2000/11/15 11:50:07 1.14 > > > +++ Makefile.in 2001/01/09 11:06:15 1.15 > > ... > > > + cp $(MM_OBJS) . > > > > Isn't this copying the wrong (or not enough) files? It currently > > copies just the .lo (timestamp) files. Maybe it should copy the .o > > files too. > > > > Later, libtool thinks these are the real files (I guess) and when > > building .libs/libapr.a it ends up creating the symbolic links (the > > ones that don't work with libtool 1.3.3) and putting these timestamp > > files in the archive. > > > > mm_malloc/mm_free/etc. are not in .libs/libapr.a. They are > > referenced, of course. > > I just verified that if shmem/unix/Makefile copies mm/*.lo *and* > mm/*.o then .libs/libapr.a has mm_malloc() et al in it. > > As an added bonus, this avoids the dependency on libtool 1.3.4. I'm just going to punt that stuff. Ryan made a change to allow us to tell apps to include libmm.la, so that should be fine. That will also keep us from poking around with the MM files, making assumptions about .lo organization, etc ... much cleaner. The whole copy thing used to be in there, but was an artifact of the old system. I think we can clear it out. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
Jeff Trawick <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] writes: > > > gstein 01/01/09 03:06:29 > > > > Libtool-ize APR. > > Index: Makefile.in > > === > > RCS file: /home/cvs/apr/shmem/unix/Makefile.in,v > > retrieving revision 1.14 > > retrieving revision 1.15 > > diff -u -u -r1.14 -r1.15 > > --- Makefile.in 2000/11/15 11:50:07 1.14 > > +++ Makefile.in 2001/01/09 11:06:15 1.15 > ... > > + cp $(MM_OBJS) . > > Isn't this copying the wrong (or not enough) files? It currently > copies just the .lo (timestamp) files. Maybe it should copy the .o > files too. > > Later, libtool thinks these are the real files (I guess) and when > building .libs/libapr.a it ends up creating the symbolic links (the > ones that don't work with libtool 1.3.3) and putting these timestamp > files in the archive. > > mm_malloc/mm_free/etc. are not in .libs/libapr.a. They are > referenced, of course. I just verified that if shmem/unix/Makefile copies mm/*.lo *and* mm/*.o then .libs/libapr.a has mm_malloc() et al in it. As an added bonus, this avoids the dependency on libtool 1.3.4. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
[EMAIL PROTECTED] writes: > gstein 01/01/09 03:06:29 > > Libtool-ize APR. > Index: Makefile.in > === > RCS file: /home/cvs/apr/shmem/unix/Makefile.in,v > retrieving revision 1.14 > retrieving revision 1.15 > diff -u -u -r1.14 -r1.15 > --- Makefile.in 2000/11/15 11:50:07 1.14 > +++ Makefile.in 2001/01/09 11:06:15 1.15 ... > + cp $(MM_OBJS) . Isn't this copying the wrong (or not enough) files? It currently copies just the .lo (timestamp) files. Maybe it should copy the .o files too. Later, libtool thinks these are the real files (I guess) and when building .libs/libapr.a it ends up creating the symbolic links (the ones that don't work with libtool 1.3.3) and putting these timestamp files in the archive. mm_malloc/mm_free/etc. are not in .libs/libapr.a. They are referenced, of course. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr APRVARS.in configure.in
Jeff Trawick <[EMAIL PROTECTED]> writes: > Oops... I meant to follow up to the list... trying again. > > Note also that upgrading to libtool 1.3.4 and libtool 1.3.5 didn't > help. Double loser... I didn't blow away ltmain.sh after upgrading, and ltmain.sh is where the bug was. libtool 1.3.4 has a fix for the problem. Unless somebody shouts real soon, I'll change the libtool check to require 1.3.4 instead of 1.3.3. Also, I noticed that build/cvsclean doesn't blow away all copies of ltmain.sh: ./srclib/pcre/ltmain.sh ./srclib/apr/shmem/unix/mm/ltmain.sh ./ltmain.sh The first two reside in cvs, so it is okay not to remove them. The last one isn't in cvs so it has to go. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr APRVARS.in configure.in
Oops... I meant to follow up to the list... trying again. Note also that upgrading to libtool 1.3.4 and libtool 1.3.5 didn't help. Greg Stein <[EMAIL PROTECTED]> writes: > That patch is just plain wrong. Usable as a stopgap, but not something to be > committed. > > I was dead tired last night and had to crash after some minimal testing. > I'll get the stuff cleaned back up. > > Jeff: what is going wrong for you with Ryan's new patch? Here is the tail end of a build just now on an up-to-date clean tree: make[3]: Leaving directory `/home/trawick/apache/httpd-2.0/srclib/apr/dso/unix' make[3]: Entering directory `/home/trawick/apache/httpd-2.0/srclib/apr' /bin/sh /home/trawick/apache/httpd-2.0/srclib/apr/libtool --mode=link --silent gcc -DLINUX=2 -DAPACHE_XLATE Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -I./include -I../include -o libapr.l.Aa -rpath /usr/local/lib lib/apr_pools.lo strings/apr_cpystrn.lo strings/apr_fnmatch.lo strings/apr_snprintf.lo strings/apr_strings.lo strings/apr_strnatcmp.lo passwd/apr_getpass.lo passwd/apr_md5.lo tables/apr_hash.lo tables/apr_tables.lo file_io/unix/dir.lo file_io/unix/fileacc.lo file_io/unix/filedup.lo file_io/unix/filestat.lo file_io/unix/flock.lo file_io/unix/fullrw.lo file_io/unix/open.lo file_io/unix/pipe.lo file_io/unix/readwrite.lo file_io/unix/seek.lo network_io/unix/inet_ntop.lo network_io/unix/inet_pton.lo network_io/unix/poll.lo network_io/unix/sendrecv.lo network_io/unix/sockaddr.lo network_io/unix/sockets.lo network_io/unix/sockopt.lo threadproc/unix/proc.lo threadproc/unix/procsup.lo threadproc/unix/signals.lo threadproc/unix/thread.lo threadproc/unix/threadpriv.lo misc/unix/errorcodes.lo misc/unix/getopt.lo misc/unix/getuuid.lo misc/unix/otherchild.lo mis! ! c/unix/rand.lo misc/unix/start.lo misc/unix/uuid.lo locks/unix/crossproc.lo locks/unix/intraproc.lo locks/unix/locks.lo time/unix/time.lo time/unix/timestr.lo mmap/unix/common.lo mmap/unix/mmap.lo shmem/unix/mm_alloc.lo shmem/unix/mm_core.lo shmem/unix/mm_global.lo shmem/unix/mm_lib.lo shmem/unix/mm_vers.lo shmem/unix/shmem.lo i18n/unix/xlate.lo user/unix/homedir.lo dso/unix/dso.lo ar: shmem/unix/mm_alloc.o: No such file or directory make[3]: *** [libapr.la] Error 1 make[3]: Leaving directory `/home/trawick/apache/httpd-2.0/srclib/apr' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/trawick/apache/httpd-2.0/srclib/apr' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/trawick/apache/httpd-2.0/srclib' make: *** [all-recursive] Error 1 Here are the files in shmem/unix. Look at the symbolic links. Not too cool. They were created by libtool... [EMAIL PROTECTED] httpd-2.0]$ dir srclib/apr/shmem/unix/ total 48 drwxrwxr-x 4 trawick trawick 1024 Jan 10 07:01 . drwxrwxr-x 5 trawick trawick 1024 Dec 4 17:23 .. -rw-rw-r-- 1 trawick trawick20 Jan 9 15:17 .cvsignore drwxrwxr-x 2 trawick trawick 1024 Jan 9 15:17 CVS -rw-rw-r-- 1 trawick trawick 657 Jan 10 07:00 Makefile -rw-rw-r-- 1 trawick trawick 549 Jan 9 15:17 Makefile.in drwxrwxr-x 4 trawick trawick 2048 Jan 10 07:01 mm -rw-rw-r-- 1 trawick trawick10 Jan 10 07:01 mm_alloc.lo lrwxrwxrwx 1 trawick trawick22 Jan 10 07:01 mm_alloc.o -> shmem/unix/mm_alloc.lo -rw-rw-r-- 1 trawick trawick10 Jan 10 07:01 mm_core.lo lrwxrwxrwx 1 trawick trawick21 Jan 10 07:01 mm_core.o -> shmem/unix/mm_core.lo -rw-rw-r-- 1 trawick trawick10 Jan 10 07:01 mm_global.lo lrwxrwxrwx 1 trawick trawick23 Jan 10 07:01 mm_global.o -> shmem/unix/mm_global.lo -rw-rw-r-- 1 trawick trawick10 Jan 10 07:01 mm_lib.lo lrwxrwxrwx 1 trawick trawick20 Jan 10 07:01 mm_lib.o -> shmem/unix/mm_lib.lo -rw-rw-r-- 1 trawick trawick10 Jan 10 07:01 mm_vers.lo lrwxrwxrwx 1 trawick trawick21 Jan 10 07:01 mm_vers.o -> shmem/unix/mm_vers.lo -rw-rw-r-- 1 trawick trawick 6381 Jan 8 10:34 shmem.c -rw-rw-r-- 1 trawick trawick10 Jan 10 07:01 shmem.lo -rw-rw-r-- 1 trawick trawick 26420 Jan 10 07:01 shmem.o Here is what libtool is doing (I turned off --silent): make[1]: Entering directory `/home/trawick/apache/httpd-2.0/srclib/apr' /bin/sh /home/trawick/apache/httpd-2.0/srclib/apr/libtool --mode=link gcc -DLINUX=2 -DAPACHE_XLA TE -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -DAP_DEBUG -DNO_DBM_ apr_fnmatch.lo strings/apr_snprintf.lo strings/apr_strings.lo strings/apr_strnatcmp.lo passwd/apr_getpass.lo passwd/apr_md5.lo tables/apr_hash.lo tables/apr_tables.lo file_io/unix/dir.lo file_io/unix/fileacc.lo file_io/unix/filedup.lo file_io/unix/filestat.lo file_io/unix/flock.lo file_io/unix/fullrw.lo file_io/unix/open.lo file_io/unix/pipe.lo file_io/unix/readwrite.lo file_io/unix/seek.lo network_io/unix/inet_ntop.lo network_io/unix/inet_pton.lo network_io/unix/poll.lo network_io/unix/sendrec
Sockopt patch
I've stuck the latest version of the patch at http://httpd.apache.org/~dreid/sockopt_diff If I don't hear any negatives I'll commit when I get back from my course on Saturday morning. david
Re: cvs commit: apr Makefile.in configure.in
On Wed, 10 Jan 2001 12:57:36 +0100 (CET), Sascha Schumann wrote: >On Wed, 10 Jan 2001, Brian Havard wrote: > >> On Tue, 9 Jan 2001 17:17:16 -0800, Greg Stein wrote: >> >> >Yay! >> > >> >I always hated that thing. I did enough damage last night, that I wasn't >> >going to try and remove it, though :-) >> >> Yeah, libtool has a few nice features. I just wish it didn't slow the build >> to a crawl. For me, APR now takes over 5x as long to build as without >> libtool (no, that's not an exaggeration, 47s vs 4min27s). > >Try to install a faster Bourne Shell.. if it takes so much >time, it is usually caused by a very slow /bin/sh. > >http://freshmeat.net/projects/pdksh/ Actually, that's what I'm using. The problem is that it spawns processes via fork/exec which is horribly inefficient on OS/2 as fork() is emulated by the C library for unix compatibility only. I've had a look at recoding it to use spawn() (like I did for CGIs in Apache a while ago) but it isn't a simple job. -- __ | Brian Havard | "He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy!" - Life of Brian | --
Re: cvs commit: apr Makefile.in configure.in
On Wed, 10 Jan 2001, Brian Havard wrote: > On Tue, 9 Jan 2001 17:17:16 -0800, Greg Stein wrote: > > >Yay! > > > >I always hated that thing. I did enough damage last night, that I wasn't > >going to try and remove it, though :-) > > Yeah, libtool has a few nice features. I just wish it didn't slow the build > to a crawl. For me, APR now takes over 5x as long to build as without > libtool (no, that's not an exaggeration, 47s vs 4min27s). Try to install a faster Bourne Shell.. if it takes so much time, it is usually caused by a very slow /bin/sh. http://freshmeat.net/projects/pdksh/ - Sascha
Re: cvs commit: apr Makefile.in configure.in
On Tue, 9 Jan 2001 17:17:16 -0800, Greg Stein wrote: >Yay! > >I always hated that thing. I did enough damage last night, that I wasn't >going to try and remove it, though :-) Yeah, libtool has a few nice features. I just wish it didn't slow the build to a crawl. For me, APR now takes over 5x as long to build as without libtool (no, that's not an exaggeration, 47s vs 4min27s). >On Wed, Jan 10, 2001 at 01:01:33AM -, [EMAIL PROTECTED] wrote: >> bjh 01/01/09 17:01:33 >> >> Modified:.Makefile.in configure.in >> Log: >> Libtool takes care of the lib prefix so get rid of our own workaround. -- __ | Brian Havard | "He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy!" - Life of Brian | --
Re: cvs commit: apr Makefile.in configure.in
Yay!
I always hated that thing. I did enough damage last night, that I wasn't
going to try and remove it, though :-)
Cheers,
-g
On Wed, Jan 10, 2001 at 01:01:33AM -, [EMAIL PROTECTED] wrote:
> bjh 01/01/09 17:01:33
>
> Modified:.Makefile.in configure.in
> Log:
> Libtool takes care of the lib prefix so get rid of our own workaround.
>
> Revision ChangesPath
> 1.38 +1 -1 apr/Makefile.in
>
> Index: Makefile.in
> ===
> RCS file: /home/cvs/apr/Makefile.in,v
> retrieving revision 1.37
> retrieving revision 1.38
> diff -u -r1.37 -r1.38
> --- Makefile.in 2001/01/09 11:05:33 1.37
> +++ Makefile.in 2001/01/10 01:01:33 1.38
> @@ -16,7 +16,7 @@
>[EMAIL PROTECTED]@
>#shmem/@OSDIR@
>
> -LIBAPR = @[EMAIL PROTECTED]
> +LIBAPR = libapr.la
>
>TARGET_EXPORTS = apr.exports
>
>
>
>
> 1.208 +0 -5 apr/configure.in
>
> Index: configure.in
> ===
> RCS file: /home/cvs/apr/configure.in,v
> retrieving revision 1.207
> retrieving revision 1.208
> diff -u -r1.207 -r1.208
> --- configure.in2001/01/09 19:28:36 1.207
> +++ configure.in2001/01/10 01:01:33 1.208
> @@ -41,9 +41,6 @@
>echo "(Default will be ${DEFAULT_OSDIR})"
>MODULES="file_io network_io threadproc misc locks time mmap shmem i18n
> user"
>
> -# Most platforms use a prefix of 'lib' on their library files.
> -LIBPREFIX='lib'
> -
>dnl # Checks for programs.
>AC_PROG_CC
>AC_PROG_MAKE_SET
> @@ -101,7 +98,6 @@
> *-os2*)
> CFLAGS="$CFLAGS -DOS2 -Zmt"
> OSDIR="os2"
> - LIBPREFIX=""
> enable_threads="system_threads"
> eolstr="\\r\\n"
> ;;
> @@ -862,7 +858,6 @@
>AC_SUBST(RM)
>AC_SUBST(OSDIR)
>AC_SUBST(DEFAULT_OSDIR)
> -AC_SUBST(LIBPREFIX)
>AC_SUBST(EXEEXT)
>AC_SUBST(THREAD_CPPFLAGS)
>AC_SUBST(THREAD_CFLAGS)
>
>
>
--
Greg Stein, http://www.lyra.org/
Re: APR_MKDIR() attempt #2
On Sat, Jan 06, 2001 at 12:14:28PM -0800, Mo DeJong wrote: > I sent this patch in some time ago, but > I did not hear anything back so I though > I would post it again. This patch fixes > the build in the case where apr is > compiled in a build dir that is not > the src dir. This only matters when > another module uses the RUN_SUBDIR_CONFIG_NOW() > macro. I reviewed the patch quite a bit, but I don't recall the reason I had for not applying it. (I think it was something about the APR_MKDIR func) Note that Sascha has patched apr_common.m4 to use the $MKDIR variable. Assuming the caller (Subversion) sets that, then we should be okay. [ a one line patch to SVN's configure.in ] Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: APR_MKDIR() attempt #2
Mo DeJong wrote: I sent this patch in some time ago, but I did not hear anything back so I though I would post it again. This patch fixes the build in the case where apr is compiled in a build dir that is not the src dir. This only matters when another module uses the RUN_SUBDIR_CONFIG_NOW() macro. I'd second this patch (we'll need it for Subversion), but I'm not qualified to decide if it's correct. It looks fine to me. Opinions? -- Brane Čibej home: <[EMAIL PROTECTED]> http://www.xbc.nu/brane/ work: <[EMAIL PROTECTED]> http://www.hermes-softlab.com/ ACM: <[EMAIL PROTECTED]>http://www.acm.org/
