From icrazy at gmail.com Wed Oct 1 12:21:51 2008 From: icrazy at gmail.com (Kuang He) Date: Wed, 1 Oct 2008 15:21:51 -0400 Subject: [sac-dev] Patch to make our build system support VPATH builds Message-ID: Hi, all VPATH builds [1] are preferred by some people for the following reasons: 1. They prevent the build process form cluttering your source directory with all sorts of build files. 2. To remove a build, all you have to do is remove the build directory. 3. You can build the same source multiple times using different options. This is very useful if you would like to write a script that will run the test suite for a package while the package is configured in many different ways (e.g. different features, different compiler optimization, and so on). It is also useful if you would like to do the same with releasing binary distributions of the source. Well, I think this is very desirable, since with VPATH, we can test building from SAC's source code using different parameters, e.g. --enable-debug, --enable-readline, --disable-editline --disable-readline. I made some effort to make this happen, and the patch is attached. It is not a big patch anyways. I tested using a few different combinations of parameters during the ./configure stage, and also in different directories (e.g. the subdirectory of the source tree, the parent directory of the source tree, a completely different and deep directory elsewhere). Everything works OK for me. [1] http://autotoolset.sourceforge.net/tutorial.html#SEC8 Explanation of what a `VPATH build' is: In a VPATH build, the source distribution is stored in a, possibly read-only, directory, and the actual building takes place in a different directory where all the generated files are being stored. We call the first directory, the source tree, and the second directory the build tree. The build tree may be a subdirectory of the source tree, but it is better if it is a completely separate directory. Best regards, -- Kuang He Department of Physics University of Connecticut Storrs, CT 06269-3046 Tel: +1.860.486.4919 Web: http://www.phys.uconn.edu/~he/ -------------- next part -------------- A non-text attachment was scrubbed... Name: vpath-patch.diff Type: application/octet-stream Size: 5510 bytes Desc: not available URL: From icrazy at gmail.com Wed Oct 1 12:22:59 2008 From: icrazy at gmail.com (Kuang He) Date: Wed, 1 Oct 2008 15:22:59 -0400 Subject: [sac-dev] Patch to fix a small problem with `make distclean' Message-ID: Hi all, Right now, in a source tree that has been configured with libedit, if we use `make clean', all the generated files and directories under libedit/ would be cleaned. However, if we use `make distclean', which is supposed to be a superset of `make clean', not all the generated files/dirs are cleaned properly. Like this: $ cd libedit $ make distclean $ ll total 16K drwxr-xr-x 3 icrazy icrazy 4.0K Sep 30 02:15 include drwxr-xr-x 2 icrazy icrazy 4.0K Sep 30 02:15 lib drwxr-xr-x 5 icrazy icrazy 4.0K Sep 30 02:15 libedit-2.6.9 drwxr-xr-x 4 icrazy icrazy 4.0K Sep 30 02:15 man Attached is a patch that utilizes [1] to fix this behavior, as well as some corresponding documentation. [1] Extending Automake Rules http://sources.redhat.com/automake/automake.html#Extending Best regards, -- Kuang He Department of Physics University of Connecticut Storrs, CT 06269-3046 Tel: +1.860.486.4919 Web: http://www.phys.uconn.edu/~he/ -------------- next part -------------- A non-text attachment was scrubbed... Name: make-distclean-patch.diff Type: application/octet-stream Size: 1231 bytes Desc: not available URL: From george at gly.bris.ac.uk Wed Oct 1 12:50:25 2008 From: george at gly.bris.ac.uk (George Helffrich) Date: Wed, 1 Oct 2008 20:50:25 +0100 Subject: [sac-dev] Patch to make our build system support VPATH builds In-Reply-To: References: Message-ID: <979a555c6cf807c030a8360ab3c8d9f7@gly.bris.ac.uk> Dear Kuang - VPATH is notoriously nonstandard among BSD, GNU and Sun make. Suggest that you validate its functioning on all those systems. If problematic, it might be too much hassle to make work right, despite being potentially attractive for simplifying maintenance. On 1 Oct 2008, at 20:21, Kuang He wrote: > Hi, all > > VPATH builds [1] are preferred by some people for the following > reasons: > > 1. They prevent the build process form cluttering your source > directory with all sorts of build files. > 2. To remove a build, all you have to do is remove the build > directory. > 3. You can build the same source multiple times using different > options. This is very useful if you would like to write a script that > will run the test suite for a package while the package is configured > in many different ways (e.g. different features, different compiler > optimization, and so on). It is also useful if you would like to do > the same with releasing binary distributions of the source. > > Well, I think this is very desirable, since with VPATH, we can test > building from SAC's source code using different parameters, e.g. > --enable-debug, --enable-readline, --disable-editline > --disable-readline. > > I made some effort to make this happen, and the patch is attached. It > is not a big patch anyways. I tested using a few different > combinations of parameters during the ./configure stage, and also in > different directories (e.g. the subdirectory of the source tree, the > parent directory of the source tree, a completely different and deep > directory elsewhere). Everything works OK for me. > > [1] http://autotoolset.sourceforge.net/tutorial.html#SEC8 > > Explanation of what a `VPATH build' is: > > In a VPATH build, the source distribution is stored in a, possibly > read-only, directory, and the actual building takes place in a > different directory where all the generated files are being > stored. We call the first directory, the source tree, and the > second directory the build tree. The build tree may be a > subdirectory of the source tree, but it is better if it is a > completely separate directory. > > > Best regards, > > -- > Kuang He > Department of Physics > University of Connecticut > Storrs, CT 06269-3046 > > Tel: +1.860.486.4919 > Web: http://www.phys.uconn.edu/~he/ > _______________________________________________ > sac-dev mailing list > sac-dev at iris.washington.edu > http://www.iris.washington.edu/mailman/listinfo/sac-dev > George Helffrich george at geology.bristol.ac.uk From icrazy at gmail.com Wed Oct 1 13:11:58 2008 From: icrazy at gmail.com (Kuang He) Date: Wed, 1 Oct 2008 16:11:58 -0400 Subject: [sac-dev] Patch to make our build system support VPATH builds In-Reply-To: <979a555c6cf807c030a8360ab3c8d9f7@gly.bris.ac.uk> References: <979a555c6cf807c030a8360ab3c8d9f7@gly.bris.ac.uk> Message-ID: On Wed, Oct 1, 2008 at 3:50 PM, George Helffrich wrote: > VPATH is notoriously nonstandard among BSD, GNU and Sun make. > Suggest that you validate its functioning on all those systems. If > problematic, it might be too much hassle to make work right, despite being > potentially attractive for simplifying maintenance. Dear George, Thanks for pointing this out. I've only tested VPATH builds using GNU make on linux only, and it worked. I don't have Solaris or Mac machines, so is there anybody who can help me test this patch on different operating systems other than linux (hopefully using both GNU make and other make programs)? Thanks! It is already stated in the `Readme.buildsac' file that `the build goes best with GNU development tools, specifically the GNU gcc and the GNU make'. I hope that my patch will at least work with GNU make on different systems. Hopefully it won't cause problem when using other make programs. I really like this feature since I can keep my source tree uncluttered this, and I don't need to make copies of the source tree (which is big and has thousands of files) at anytime. Best regards, -- Kuang He Department of Physics University of Connecticut Storrs, CT 06269-3046 Tel: +1.860.486.4919 Web: http://www.phys.uconn.edu/~he/ From snoke at vt.edu Wed Oct 1 16:20:38 2008 From: snoke at vt.edu (Arthur Snoke) Date: Wed, 01 Oct 2008 19:20:38 -0400 Subject: [sac-dev] Patch to fix a small problem with `make distclean' In-Reply-To: References: Message-ID: <48E405C6.8070004@vt.edu> Kuang and others, We were aware of the fact that distclean did not truly clean the libedit stuff, and the following line is in the Readme.buildsac: % make distclean > /dev/null - Removes configuration files as well. Must run make clean first. I forget if Brian had a reason for not making a fix in the Makefile. We'll look at your patch. Arthur Kuang He wrote: > Hi all, > > Right now, in a source tree that has been configured with libedit, if > we use `make clean', all the generated files and directories under > libedit/ would be cleaned. However, if we use `make distclean', which > is supposed to be a superset of `make clean', not all the generated > files/dirs are cleaned properly. Like this: > > $ cd libedit > $ make distclean > $ ll > total 16K > drwxr-xr-x 3 icrazy icrazy 4.0K Sep 30 02:15 include > drwxr-xr-x 2 icrazy icrazy 4.0K Sep 30 02:15 lib > drwxr-xr-x 5 icrazy icrazy 4.0K Sep 30 02:15 libedit-2.6.9 > drwxr-xr-x 4 icrazy icrazy 4.0K Sep 30 02:15 man > > Attached is a patch that utilizes [1] to fix this behavior, as well as > some corresponding documentation. > > [1] Extending Automake Rules > http://sources.redhat.com/automake/automake.html#Extending > > > Best regards, > > > > ------------------------------------------------------------------------ > > _______________________________________________ > sac-dev mailing list > sac-dev at iris.washington.edu > http://www.iris.washington.edu/mailman/listinfo/sac-dev From icrazy at gmail.com Wed Oct 1 16:58:08 2008 From: icrazy at gmail.com (Kuang He) Date: Wed, 1 Oct 2008 19:58:08 -0400 Subject: [sac-dev] Patch to make our build system support VPATH builds In-Reply-To: References: <979a555c6cf807c030a8360ab3c8d9f7@gly.bris.ac.uk> Message-ID: On Wed, Oct 1, 2008 at 4:11 PM, Kuang He wrote: > Dear George, > > Thanks for pointing this out. I've only tested VPATH builds using GNU > make on linux only, and it worked. I don't have Solaris or Mac > machines, A small addition: I've just tested the `VPATH build' patch on Cygwin, and it worked fine. Best regards, -- Kuang He From savage at uri.edu Thu Oct 2 13:06:26 2008 From: savage at uri.edu (Brian Savage) Date: Thu, 2 Oct 2008 16:06:26 -0400 Subject: [sac-dev] Patch to make our build system support VPATH builds In-Reply-To: References: <979a555c6cf807c030a8360ab3c8d9f7@gly.bris.ac.uk> Message-ID: <8DC46EE0-9DCC-4054-93C4-371DE2FB750D@uri.edu> Kuang, I will try to look at your patches this weekend. I have a all day meeting tomorrow. Patches I need to look at - VPATH - I will test this on the supported systems - PAGER - I think the solution George gave is the simplest and most straight forward If PAGER is defined use that variable, otherwise use the default sac paging system. - make distclean - Again needs to be tested on the supported systems. Patches which should be easy to check - tolower/toupper checks in build system - segfault on space in header variable Patches which look good, no changes - closing of the plotting window - CTRL-D to quit - sachistory string overrun I will keep you up to date Cheers Brian On Oct 1, 2008, at 7:58 PM , Kuang He wrote: > On Wed, Oct 1, 2008 at 4:11 PM, Kuang He wrote: >> Dear George, >> >> Thanks for pointing this out. I've only tested VPATH builds using GNU >> make on linux only, and it worked. I don't have Solaris or Mac >> machines, > > A small addition: I've just tested the `VPATH build' patch on Cygwin, > and it worked fine. > > Best regards, > > -- > Kuang He > _______________________________________________ > sac-dev mailing list > sac-dev at iris.washington.edu > http://www.iris.washington.edu/mailman/listinfo/sac-dev From icrazy at gmail.com Thu Oct 2 18:30:56 2008 From: icrazy at gmail.com (Kuang He) Date: Thu, 2 Oct 2008 21:30:56 -0400 Subject: [sac-dev] Patch to suppress the warnings when running autoreconf Message-ID: Hi all, Running autoreconf is basically equivalent to running the script ./bootstrap in the CVS repository, and is sometimes a little faster. Attached is a patch to suppress the following warnings when running autoreconf. Plus, with this patch, we don't need to add the '--foreign' parameter to automake anymore. Just a thought: maybe we'd better pay attention to the first warning below? $ autoreconf src/Makefile.am:14: `CFLAGS' is a user variable, you should not override it; src/Makefile.am:14: use `AM_CFLAGS' instead. utils/Makefile.am:5: `CFLAGS' is a user variable, you should not override it; utils/Makefile.am:5: use `AM_CFLAGS' instead. Makefile.am: required file `./INSTALL' not found Makefile.am: `automake --add-missing' can install `INSTALL' Makefile.am: required file `./NEWS' not found Makefile.am: required file `./AUTHORS' not found Makefile.am: required file `./ChangeLog' not found Makefile.am: required file `./COPYING' not found Makefile.am: `automake --add-missing' can install `COPYING' autoreconf: automake failed with exit status: 1 Best regards, -- Kuang He Department of Physics University of Connecticut Storrs, CT 06269-3046 Tel: +1.860.486.4919 Web: http://www.phys.uconn.edu/~he/ -------------- next part -------------- A non-text attachment was scrubbed... Name: autoreconf-patch.diff Type: application/octet-stream Size: 564 bytes Desc: not available URL: From george at gly.bris.ac.uk Sun Oct 5 04:51:17 2008 From: george at gly.bris.ac.uk (George Helffrich) Date: Sun, 5 Oct 2008 12:51:17 +0100 Subject: [sac-dev] Patch to make our build system support VPATH builds In-Reply-To: References: <979a555c6cf807c030a8360ab3c8d9f7@gly.bris.ac.uk> Message-ID: Dear All - I can confirm a successful vanilla build of Kuangs distribution on MacOS 10.3 and on FreeBSD 6.3. However, this build fails on a Solaris 5.7 system (due to a possibly unrelated problem). Perhaps Arthur can investigate further. My results are: ./configure checking build system type... sparc-sun-solaris2.7 checking host system type... sparc-sun-solaris2.7 checking target system type... sparc-sun-solaris2.7 ... checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. ------------ gcc is so old (2.7.2) that is fails configure tests using -V. Forcing to use Sun cc is OK until subdirectory configure is used; then CC gets forgotten: ------------- ./configure CC=cc checking build system type... sparc-sun-solaris2.7 checking host system type... sparc-sun-solaris2.7 checking target system type... sparc-sun-solaris2.7 ... configure: creating ./config.status config.status: creating src/Makefile config.status: creating utils/Makefile config.status: creating libedit/Makefile config.status: creating Makefile config.status: creating inc/config.h config.status: executing depfiles commands configure: Compliation Options for sac (Seismic Analysis Code 101.2) CFLAGS = LDFLAGS = LIBS = -ldl -lm -ltermcap Debug = Optimization = Database = off Matlab = off X11-buffer = on X11-depth = on X_LIBS = -L/usr/openwin/lib X_CFLAGS = -I/usr/openwin/include Readline = off Editline = on Install Base = /usr/local/sac System = sun_solaris2 (sparc-sun-solaris2.7) To compile sac type make #make Making all in libedit echo "Creating the Line Editing Library" Creating the Line Editing Library gzip -dc ./libedit-2.6.9.tar.gz | tar xvf - x libedit-2.6.9, 0 bytes, 0 tape blocks x libedit-2.6.9/makelist, 6742 bytes, 14 tape blocks x libedit-2.6.9/CHANGES, 3853 bytes, 8 tape blocks x libedit-2.6.9/INSTALL, 1604 bytes, 4 tape blocks ... (cd libedit-2.6.9 && env CFLAGS="-O -Wall -pipe -g3" LDFLAGS="" INSTALL="/tmp/sac-101.2/config/install-sh" ./configure --prefix=.. ) creating cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc -O -Wall -pipe -g3 ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. *** Error code 1 make: Fatal error: Command failed for target `lib/libedit.a' Current working directory /tmp/sac-101.2/libedit *** Error code 1 make: Fatal error: Command failed for target `all-recursive' ----------- Then, ----------- #make CC=cc Making all in libedit (cd libedit-2.6.9 && env CFLAGS="-O -Wall -pipe -g3" LDFLAGS="" INSTALL="/tmp/sac-101.2/config/install-sh" ./configure --prefix=.. ) loading cache ./config.cache checking for gcc... cc -Xc -D__EXTENSIONS__ checking whether the C compiler (cc -Xc -D__EXTENSIONS__ -O -Wall -pipe -g3 ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. *** Error code 1 make: Fatal error: Command failed for target `lib/libedit.a' Current working directory /tmp/sac-101.2/libedit *** Error code 1 make: Fatal error: Command failed for target `all-recursive' -------------- The generated Makefiles are so exquisitely baroque as to deter any sensible debug effort. Suffice it to say that builds that deviate from a default system configuration seem unlikely to work. On 1 Oct 2008, at 21:11, Kuang He wrote: > On Wed, Oct 1, 2008 at 3:50 PM, George Helffrich > wrote: >> VPATH is notoriously nonstandard among BSD, GNU and Sun make. >> Suggest that you validate its functioning on all those systems. If >> problematic, it might be too much hassle to make work right, despite >> being >> potentially attractive for simplifying maintenance. > > Dear George, > > Thanks for pointing this out. I've only tested VPATH builds using GNU > make on linux only, and it worked. I don't have Solaris or Mac > machines, so is there anybody who can help me test this patch on > different operating systems other than linux (hopefully using both GNU > make and other make programs)? Thanks! > > It is already stated in the `Readme.buildsac' file that `the build > goes best with GNU development tools, specifically the GNU gcc and the > GNU make'. I hope that my patch will at least work with GNU make on > different systems. Hopefully it won't cause problem when using other > make programs. > > I really like this feature since I can keep my source tree uncluttered > this, and I don't need to make copies of the source tree (which is big > and has thousands of files) at anytime. > > > Best regards, > > -- > Kuang He > Department of Physics > University of Connecticut > Storrs, CT 06269-3046 > > Tel: +1.860.486.4919 > Web: http://www.phys.uconn.edu/~he/ > _______________________________________________ > sac-dev mailing list > sac-dev at iris.washington.edu > http://www.iris.washington.edu/mailman/listinfo/sac-dev > George Helffrich george at geology.bristol.ac.uk From savage at uri.edu Mon Oct 6 08:47:36 2008 From: savage at uri.edu (Brian Savage) Date: Mon, 6 Oct 2008 11:47:36 -0400 Subject: [sac-dev] Patch to make our build system support VPATH builds In-Reply-To: References: <979a555c6cf807c030a8360ab3c8d9f7@gly.bris.ac.uk> Message-ID: <7B4458B5-0820-43E0-9B35-A03565A705F8@uri.edu> Kuang He, The build on my system (OSX/Intel 10.4) fails. The abs_top_srcdir is not defined. I cannot find a resolution to this, but I will keep looking. I needed to rerun the bootstrap script (or autoreconf) as the Makefile.in files needed to be regenerated from the Makefile.am files. I am using autoconf 2.60 and automake 1.9.6 Cheers Brian On Oct 5, 2008, at 7:51 AM , George Helffrich wrote: > Dear All - > > I can confirm a successful vanilla build of Kuangs distribution on > MacOS 10.3 and on FreeBSD 6.3. > > However, this build fails on a Solaris 5.7 system (due to a > possibly unrelated problem). Perhaps Arthur can investigate > further. My results are: > > ./configure > checking build system type... sparc-sun-solaris2.7 > checking host system type... sparc-sun-solaris2.7 > checking target system type... sparc-sun-solaris2.7 > ... > checking for gcc... gcc > checking for C compiler default output file name... > configure: error: C compiler cannot create executables > See `config.log' for more details. > ------------ > > gcc is so old (2.7.2) that is fails configure tests using -V. > > Forcing to use Sun cc is OK until subdirectory configure is used; > then CC gets forgotten: > > ------------- > ./configure CC=cc > checking build system type... sparc-sun-solaris2.7 > checking host system type... sparc-sun-solaris2.7 > checking target system type... sparc-sun-solaris2.7 > ... > configure: creating ./config.status > config.status: creating src/Makefile > config.status: creating utils/Makefile > config.status: creating libedit/Makefile > config.status: creating Makefile > config.status: creating inc/config.h > config.status: executing depfiles commands > configure: > > Compliation Options for sac (Seismic Analysis Code 101.2) > > CFLAGS = > LDFLAGS = > LIBS = -ldl -lm -ltermcap > Debug = > Optimization = > Database = off > Matlab = off > X11-buffer = on > X11-depth = on > X_LIBS = -L/usr/openwin/lib > X_CFLAGS = -I/usr/openwin/include > Readline = off > Editline = on > Install Base = /usr/local/sac > System = sun_solaris2 (sparc-sun-solaris2.7) > > To compile sac type make > #make > Making all in libedit > echo "Creating the Line Editing Library" > Creating the Line Editing Library > gzip -dc ./libedit-2.6.9.tar.gz | tar xvf - > x libedit-2.6.9, 0 bytes, 0 tape blocks > x libedit-2.6.9/makelist, 6742 bytes, 14 tape blocks > x libedit-2.6.9/CHANGES, 3853 bytes, 8 tape blocks > x libedit-2.6.9/INSTALL, 1604 bytes, 4 tape blocks > ... > (cd libedit-2.6.9 && env CFLAGS="-O -Wall -pipe -g3" LDFLAGS="" > INSTALL="/tmp/sac-101.2/config/install-sh" ./configure --prefix=.. ) > creating cache ./config.cache > checking for gcc... gcc > checking whether the C compiler (gcc -O -Wall -pipe -g3 ) works... no > configure: error: installation or configuration problem: C compiler > cannot create executables. > *** Error code 1 > make: Fatal error: Command failed for target `lib/libedit.a' > Current working directory /tmp/sac-101.2/libedit > *** Error code 1 > make: Fatal error: Command failed for target `all-recursive' > ----------- > > Then, > ----------- > #make CC=cc > Making all in libedit > (cd libedit-2.6.9 && env CFLAGS="-O -Wall -pipe -g3" LDFLAGS="" > INSTALL="/tmp/sac-101.2/config/install-sh" ./configure --prefix=.. ) > loading cache ./config.cache > checking for gcc... cc -Xc -D__EXTENSIONS__ > checking whether the C compiler (cc -Xc -D__EXTENSIONS__ -O -Wall - > pipe -g3 ) works... no > configure: error: installation or configuration problem: C compiler > cannot create executables. > *** Error code 1 > make: Fatal error: Command failed for target `lib/libedit.a' > Current working directory /tmp/sac-101.2/libedit > *** Error code 1 > make: Fatal error: Command failed for target `all-recursive' > -------------- > > The generated Makefiles are so exquisitely baroque as to deter any > sensible debug effort. Suffice it to say that builds that deviate > from a default system configuration seem unlikely to work. > > On 1 Oct 2008, at 21:11, Kuang He wrote: > >> On Wed, Oct 1, 2008 at 3:50 PM, George Helffrich >> wrote: >>> VPATH is notoriously nonstandard among BSD, GNU and Sun make. >>> Suggest that you validate its functioning on all those systems. If >>> problematic, it might be too much hassle to make work right, >>> despite being >>> potentially attractive for simplifying maintenance. >> >> Dear George, >> >> Thanks for pointing this out. I've only tested VPATH builds using GNU >> make on linux only, and it worked. I don't have Solaris or Mac >> machines, so is there anybody who can help me test this patch on >> different operating systems other than linux (hopefully using both >> GNU >> make and other make programs)? Thanks! >> >> It is already stated in the `Readme.buildsac' file that `the build >> goes best with GNU development tools, specifically the GNU gcc and >> the >> GNU make'. I hope that my patch will at least work with GNU make on >> different systems. Hopefully it won't cause problem when using other >> make programs. >> >> I really like this feature since I can keep my source tree >> uncluttered >> this, and I don't need to make copies of the source tree (which is >> big >> and has thousands of files) at anytime. >> >> >> Best regards, >> >> -- >> Kuang He >> Department of Physics >> University of Connecticut >> Storrs, CT 06269-3046 >> >> Tel: +1.860.486.4919 >> Web: http://www.phys.uconn.edu/~he/ >> _______________________________________________ >> sac-dev mailing list >> sac-dev at iris.washington.edu >> http://www.iris.washington.edu/mailman/listinfo/sac-dev >> > George Helffrich > george at geology.bristol.ac.uk > > _______________________________________________ > sac-dev mailing list > sac-dev at iris.washington.edu > http://www.iris.washington.edu/mailman/listinfo/sac-dev From savage at uri.edu Mon Oct 6 09:35:17 2008 From: savage at uri.edu (Brian Savage) Date: Mon, 6 Oct 2008 12:35:17 -0400 Subject: [sac-dev] Patch to make our build system support VPATH builds In-Reply-To: <7B4458B5-0820-43E0-9B35-A03565A705F8@uri.edu> References: <979a555c6cf807c030a8360ab3c8d9f7@gly.bris.ac.uk> <7B4458B5-0820-43E0-9B35-A03565A705F8@uri.edu> Message-ID: Kuang He, To get it to work I needed to add the following line to confgure.in AC_SUBST([abs_top_srcdir]) AC_SUBST([abs_top_builddir]) Cheers Brian On Oct 6, 2008, at 11:47 AM , Brian Savage wrote: > Kuang He, > > The build on my system (OSX/Intel 10.4) fails. The abs_top_srcdir > is not defined. > I cannot find a resolution to this, but I will keep looking. > > I needed to rerun the bootstrap script (or autoreconf) as the > Makefile.in files needed to be regenerated from the Makefile.am files. > > I am using autoconf 2.60 and automake 1.9.6 > > Cheers > Brian > > > On Oct 5, 2008, at 7:51 AM , George Helffrich wrote: > >> Dear All - >> >> I can confirm a successful vanilla build of Kuangs distribution >> on MacOS 10.3 and on FreeBSD 6.3. >> >> However, this build fails on a Solaris 5.7 system (due to a >> possibly unrelated problem). Perhaps Arthur can investigate >> further. My results are: >> >> ./configure >> checking build system type... sparc-sun-solaris2.7 >> checking host system type... sparc-sun-solaris2.7 >> checking target system type... sparc-sun-solaris2.7 >> ... >> checking for gcc... gcc >> checking for C compiler default output file name... >> configure: error: C compiler cannot create executables >> See `config.log' for more details. >> ------------ >> >> gcc is so old (2.7.2) that is fails configure tests using -V. >> >> Forcing to use Sun cc is OK until subdirectory configure is used; >> then CC gets forgotten: >> >> ------------- >> ./configure CC=cc >> checking build system type... sparc-sun-solaris2.7 >> checking host system type... sparc-sun-solaris2.7 >> checking target system type... sparc-sun-solaris2.7 >> ... >> configure: creating ./config.status >> config.status: creating src/Makefile >> config.status: creating utils/Makefile >> config.status: creating libedit/Makefile >> config.status: creating Makefile >> config.status: creating inc/config.h >> config.status: executing depfiles commands >> configure: >> >> Compliation Options for sac (Seismic Analysis Code 101.2) >> >> CFLAGS = >> LDFLAGS = >> LIBS = -ldl -lm -ltermcap >> Debug = >> Optimization = >> Database = off >> Matlab = off >> X11-buffer = on >> X11-depth = on >> X_LIBS = -L/usr/openwin/lib >> X_CFLAGS = -I/usr/openwin/include >> Readline = off >> Editline = on >> Install Base = /usr/local/sac >> System = sun_solaris2 (sparc-sun-solaris2.7) >> >> To compile sac type make >> #make >> Making all in libedit >> echo "Creating the Line Editing Library" >> Creating the Line Editing Library >> gzip -dc ./libedit-2.6.9.tar.gz | tar xvf - >> x libedit-2.6.9, 0 bytes, 0 tape blocks >> x libedit-2.6.9/makelist, 6742 bytes, 14 tape blocks >> x libedit-2.6.9/CHANGES, 3853 bytes, 8 tape blocks >> x libedit-2.6.9/INSTALL, 1604 bytes, 4 tape blocks >> ... >> (cd libedit-2.6.9 && env CFLAGS="-O -Wall -pipe -g3" LDFLAGS="" >> INSTALL="/tmp/sac-101.2/config/install-sh" ./configure --prefix=.. ) >> creating cache ./config.cache >> checking for gcc... gcc >> checking whether the C compiler (gcc -O -Wall -pipe -g3 ) works... no >> configure: error: installation or configuration problem: C >> compiler cannot create executables. >> *** Error code 1 >> make: Fatal error: Command failed for target `lib/libedit.a' >> Current working directory /tmp/sac-101.2/libedit >> *** Error code 1 >> make: Fatal error: Command failed for target `all-recursive' >> ----------- >> >> Then, >> ----------- >> #make CC=cc >> Making all in libedit >> (cd libedit-2.6.9 && env CFLAGS="-O -Wall -pipe -g3" LDFLAGS="" >> INSTALL="/tmp/sac-101.2/config/install-sh" ./configure --prefix=.. ) >> loading cache ./config.cache >> checking for gcc... cc -Xc -D__EXTENSIONS__ >> checking whether the C compiler (cc -Xc -D__EXTENSIONS__ -O -Wall - >> pipe -g3 ) works... no >> configure: error: installation or configuration problem: C >> compiler cannot create executables. >> *** Error code 1 >> make: Fatal error: Command failed for target `lib/libedit.a' >> Current working directory /tmp/sac-101.2/libedit >> *** Error code 1 >> make: Fatal error: Command failed for target `all-recursive' >> -------------- >> >> The generated Makefiles are so exquisitely baroque as to deter any >> sensible debug effort. Suffice it to say that builds that deviate >> from a default system configuration seem unlikely to work. >> >> On 1 Oct 2008, at 21:11, Kuang He wrote: >> >>> On Wed, Oct 1, 2008 at 3:50 PM, George Helffrich >>> wrote: >>>> VPATH is notoriously nonstandard among BSD, GNU and Sun >>>> make. >>>> Suggest that you validate its functioning on all those >>>> systems. If >>>> problematic, it might be too much hassle to make work right, >>>> despite being >>>> potentially attractive for simplifying maintenance. >>> >>> Dear George, >>> >>> Thanks for pointing this out. I've only tested VPATH builds using >>> GNU >>> make on linux only, and it worked. I don't have Solaris or Mac >>> machines, so is there anybody who can help me test this patch on >>> different operating systems other than linux (hopefully using >>> both GNU >>> make and other make programs)? Thanks! >>> >>> It is already stated in the `Readme.buildsac' file that `the build >>> goes best with GNU development tools, specifically the GNU gcc >>> and the >>> GNU make'. I hope that my patch will at least work with GNU make on >>> different systems. Hopefully it won't cause problem when using other >>> make programs. >>> >>> I really like this feature since I can keep my source tree >>> uncluttered >>> this, and I don't need to make copies of the source tree (which >>> is big >>> and has thousands of files) at anytime. >>> >>> >>> Best regards, >>> >>> -- >>> Kuang He >>> Department of Physics >>> University of Connecticut >>> Storrs, CT 06269-3046 >>> >>> Tel: +1.860.486.4919 >>> Web: http://www.phys.uconn.edu/~he/ >>> _______________________________________________ >>> sac-dev mailing list >>> sac-dev at iris.washington.edu >>> http://www.iris.washington.edu/mailman/listinfo/sac-dev >>> >> George Helffrich >> george at geology.bristol.ac.uk >> >> _______________________________________________ >> sac-dev mailing list >> sac-dev at iris.washington.edu >> http://www.iris.washington.edu/mailman/listinfo/sac-dev > > _______________________________________________ > sac-dev mailing list > sac-dev at iris.washington.edu > http://www.iris.washington.edu/mailman/listinfo/sac-dev From icrazy at gmail.com Mon Oct 6 10:25:31 2008 From: icrazy at gmail.com (Kuang He) Date: Mon, 6 Oct 2008 13:25:31 -0400 Subject: [sac-dev] Patch to make our build system support VPATH builds In-Reply-To: <7B4458B5-0820-43E0-9B35-A03565A705F8@uri.edu> References: <979a555c6cf807c030a8360ab3c8d9f7@gly.bris.ac.uk> <7B4458B5-0820-43E0-9B35-A03565A705F8@uri.edu> Message-ID: On Mon, Oct 6, 2008 at 11:47 AM, Brian Savage wrote: > The build on my system (OSX/Intel 10.4) fails. The abs_top_srcdir is not > defined. > I cannot find a resolution to this, but I will keep looking. > > I needed to rerun the bootstrap script (or autoreconf) as the Makefile.in > files needed to be regenerated from the Makefile.am files. > > I am using autoconf 2.60 and automake 1.9.6 Dear Brian, I have been using autoconf 2.61 and automake 1.10. According to my tests, automake v1.9 does not define abs_* series macros [1], but automake v1.10 does. The reason I used abs_top_srcdir instead of top_srcdir in several Makefile.am's is to solve a VPATH problem I could not solve otherwise. For example, in libedit/Makefile.am, there is line that reads: LIBEDIT_ENV = env CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" INSTALL="$(abs_top_srcdir)/config/install-sh" If I were to write it using $(top_srcdir), I could not make it work for all the following VPATH build cases: (1) Build directory is a subdirectory of the source tree: cd /path/to/sac/source/code mkdir build && cd build ../configure (2) Build directory is a subdirectory of a subdirectory of the source tree: cd /path/to/sac/source/code mkdir -p build/test && cd build/test ../../configure (3) Build directory and source tree are not in the same tree: cd /path/to/sac/source/code mkdir -p /somewhere/else/build && cd /somewhere/else/build /path/to/sac/source/code/configure Could you try updating your automake version and try again? Or could you figure out a way to solve this problem? [1] The autoconf manual indicates that it is autoconf that is generating macro like abs_srcdir, abs_top_srcdir, etc. http://www.gnu.org/software/autoconf/manual/autoconf.html#Preset-Output-Variables It is just automake v1.9 that has not used them (meaning: not generating them in Makefile.in's). Best regards, -- Kuang He Department of Physics University of Connecticut Storrs, CT 06269-3046 Tel: +1.860.486.4919 Web: http://www.phys.uconn.edu/~he/ From snoke at vt.edu Mon Oct 6 11:01:55 2008 From: snoke at vt.edu (Arthur Snoke) Date: Mon, 06 Oct 2008 14:01:55 -0400 Subject: [sac-dev] libedit In-Reply-To: References: <979a555c6cf807c030a8360ab3c8d9f7@gly.bris.ac.uk> <7B4458B5-0820-43E0-9B35-A03565A705F8@uri.edu> Message-ID: <48EA5293.6070708@vt.edu> A high percentage of the problems in terms of system compatibility have come from libedit. Is there perhaps a new release that is more robust? From savage at uri.edu Mon Oct 6 11:08:31 2008 From: savage at uri.edu (Brian Savage) Date: Mon, 6 Oct 2008 14:08:31 -0400 Subject: [sac-dev] Patch to make our build system support VPATH builds In-Reply-To: <7B4458B5-0820-43E0-9B35-A03565A705F8@uri.edu> References: <979a555c6cf807c030a8360ab3c8d9f7@gly.bris.ac.uk> <7B4458B5-0820-43E0-9B35-A03565A705F8@uri.edu> Message-ID: <67AC05CD-3711-41DA-B917-C82AC74D9AD1@uri.edu> Kuang He, Updating to automake 1.10 solves the problem. Solaris 2.9 works for both in and out of source directory builds Intel OSX does as well. Linux too. George indicated FreeBSD worked as did solaris 5.7 Kuang He says it works fine on Cygwin Overall this looks good to me. Unless there are any objections, I will be adding this to the repository. Cheers Brian On Oct 6, 2008, at 11:47 AM , Brian Savage wrote: > Kuang He, > > The build on my system (OSX/Intel 10.4) fails. The abs_top_srcdir > is not defined. > I cannot find a resolution to this, but I will keep looking. > > I needed to rerun the bootstrap script (or autoreconf) as the > Makefile.in files needed to be regenerated from the Makefile.am files. > > I am using autoconf 2.60 and automake 1.9.6 > > Cheers > Brian > > > On Oct 5, 2008, at 7:51 AM , George Helffrich wrote: > >> Dear All - >> >> I can confirm a successful vanilla build of Kuangs distribution >> on MacOS 10.3 and on FreeBSD 6.3. >> >> However, this build fails on a Solaris 5.7 system (due to a >> possibly unrelated problem). Perhaps Arthur can investigate >> further. My results are: >> >> ./configure >> checking build system type... sparc-sun-solaris2.7 >> checking host system type... sparc-sun-solaris2.7 >> checking target system type... sparc-sun-solaris2.7 >> ... >> checking for gcc... gcc >> checking for C compiler default output file name... >> configure: error: C compiler cannot create executables >> See `config.log' for more details. >> ------------ >> >> gcc is so old (2.7.2) that is fails configure tests using -V. >> >> Forcing to use Sun cc is OK until subdirectory configure is used; >> then CC gets forgotten: >> >> ------------- >> ./configure CC=cc >> checking build system type... sparc-sun-solaris2.7 >> checking host system type... sparc-sun-solaris2.7 >> checking target system type... sparc-sun-solaris2.7 >> ... >> configure: creating ./config.status >> config.status: creating src/Makefile >> config.status: creating utils/Makefile >> config.status: creating libedit/Makefile >> config.status: creating Makefile >> config.status: creating inc/config.h >> config.status: executing depfiles commands >> configure: >> >> Compliation Options for sac (Seismic Analysis Code 101.2) >> >> CFLAGS = >> LDFLAGS = >> LIBS = -ldl -lm -ltermcap >> Debug = >> Optimization = >> Database = off >> Matlab = off >> X11-buffer = on >> X11-depth = on >> X_LIBS = -L/usr/openwin/lib >> X_CFLAGS = -I/usr/openwin/include >> Readline = off >> Editline = on >> Install Base = /usr/local/sac >> System = sun_solaris2 (sparc-sun-solaris2.7) >> >> To compile sac type make >> #make >> Making all in libedit >> echo "Creating the Line Editing Library" >> Creating the Line Editing Library >> gzip -dc ./libedit-2.6.9.tar.gz | tar xvf - >> x libedit-2.6.9, 0 bytes, 0 tape blocks >> x libedit-2.6.9/makelist, 6742 bytes, 14 tape blocks >> x libedit-2.6.9/CHANGES, 3853 bytes, 8 tape blocks >> x libedit-2.6.9/INSTALL, 1604 bytes, 4 tape blocks >> ... >> (cd libedit-2.6.9 && env CFLAGS="-O -Wall -pipe -g3" LDFLAGS="" >> INSTALL="/tmp/sac-101.2/config/install-sh" ./configure --prefix=.. ) >> creating cache ./config.cache >> checking for gcc... gcc >> checking whether the C compiler (gcc -O -Wall -pipe -g3 ) works... no >> configure: error: installation or configuration problem: C >> compiler cannot create executables. >> *** Error code 1 >> make: Fatal error: Command failed for target `lib/libedit.a' >> Current working directory /tmp/sac-101.2/libedit >> *** Error code 1 >> make: Fatal error: Command failed for target `all-recursive' >> ----------- >> >> Then, >> ----------- >> #make CC=cc >> Making all in libedit >> (cd libedit-2.6.9 && env CFLAGS="-O -Wall -pipe -g3" LDFLAGS="" >> INSTALL="/tmp/sac-101.2/config/install-sh" ./configure --prefix=.. ) >> loading cache ./config.cache >> checking for gcc... cc -Xc -D__EXTENSIONS__ >> checking whether the C compiler (cc -Xc -D__EXTENSIONS__ -O -Wall - >> pipe -g3 ) works... no >> configure: error: installation or configuration problem: C >> compiler cannot create executables. >> *** Error code 1 >> make: Fatal error: Command failed for target `lib/libedit.a' >> Current working directory /tmp/sac-101.2/libedit >> *** Error code 1 >> make: Fatal error: Command failed for target `all-recursive' >> -------------- >> >> The generated Makefiles are so exquisitely baroque as to deter any >> sensible debug effort. Suffice it to say that builds that deviate >> from a default system configuration seem unlikely to work. >> >> On 1 Oct 2008, at 21:11, Kuang He wrote: >> >>> On Wed, Oct 1, 2008 at 3:50 PM, George Helffrich >>> wrote: >>>> VPATH is notoriously nonstandard among BSD, GNU and Sun >>>> make. >>>> Suggest that you validate its functioning on all those >>>> systems. If >>>> problematic, it might be too much hassle to make work right, >>>> despite being >>>> potentially attractive for simplifying maintenance. >>> >>> Dear George, >>> >>> Thanks for pointing this out. I've only tested VPATH builds using >>> GNU >>> make on linux only, and it worked. I don't have Solaris or Mac >>> machines, so is there anybody who can help me test this patch on >>> different operating systems other than linux (hopefully using >>> both GNU >>> make and other make programs)? Thanks! >>> >>> It is already stated in the `Readme.buildsac' file that `the build >>> goes best with GNU development tools, specifically the GNU gcc >>> and the >>> GNU make'. I hope that my patch will at least work with GNU make on >>> different systems. Hopefully it won't cause problem when using other >>> make programs. >>> >>> I really like this feature since I can keep my source tree >>> uncluttered >>> this, and I don't need to make copies of the source tree (which >>> is big >>> and has thousands of files) at anytime. >>> >>> >>> Best regards, >>> >>> -- >>> Kuang He >>> Department of Physics >>> University of Connecticut >>> Storrs, CT 06269-3046 >>> >>> Tel: +1.860.486.4919 >>> Web: http://www.phys.uconn.edu/~he/ >>> _______________________________________________ >>> sac-dev mailing list >>> sac-dev at iris.washington.edu >>> http://www.iris.washington.edu/mailman/listinfo/sac-dev >>> >> George Helffrich >> george at geology.bristol.ac.uk >> >> _______________________________________________ >> sac-dev mailing list >> sac-dev at iris.washington.edu >> http://www.iris.washington.edu/mailman/listinfo/sac-dev > > _______________________________________________ > sac-dev mailing list > sac-dev at iris.washington.edu > http://www.iris.washington.edu/mailman/listinfo/sac-dev From icrazy at gmail.com Mon Oct 6 11:55:51 2008 From: icrazy at gmail.com (Kuang He) Date: Mon, 6 Oct 2008 14:55:51 -0400 Subject: [sac-dev] libedit In-Reply-To: <48EA5293.6070708@vt.edu> References: <979a555c6cf807c030a8360ab3c8d9f7@gly.bris.ac.uk> <7B4458B5-0820-43E0-9B35-A03565A705F8@uri.edu> <48EA5293.6070708@vt.edu> Message-ID: On Mon, Oct 6, 2008 at 2:01 PM, Arthur Snoke wrote: > A high percentage of the problems in terms of system compatibility have come > from libedit. > > Is there perhaps a new release that is more robust? Dear Arthur, There is a new release below, about 4 years newer than the version we are using. http://www.thrysoee.dk/editline/libedit-20080712-2.11.tar.gz I don't know about its robustness, though. Best regards, -- Kuang He Department of Physics University of Connecticut Storrs, CT 06269-3046 Tel: +1.860.486.4919 Web: http://www.phys.uconn.edu/~he/ From icrazy at gmail.com Mon Oct 6 12:04:21 2008 From: icrazy at gmail.com (Kuang He) Date: Mon, 6 Oct 2008 15:04:21 -0400 Subject: [sac-dev] Eliminate duplicate `-I../inc' parameters in generated Makefiles Message-ID: Hi all, Attached is a patch to eliminate duplicate `-I../inc' parameters in generated Makefiles. While compiling, instead of seeing something like: gcc -DHAVE_CONFIG_H -I. -I../inc -I../inc -c -o amf/allamb.o amf/allamb.c We'll see this instead: gcc -DHAVE_CONFIG_H -I../inc -c -o amf/allamb.o amf/allamb.c Reference: http://www.gnu.org/software/automake/manual/automake.html#Program-variables Best regards, -- Kuang He Department of Physics University of Connecticut Storrs, CT 06269-3046 Tel: +1.860.486.4919 Web: http://www.phys.uconn.edu/~he/ -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-makefile-duplicate-include-parameters.diff Type: application/octet-stream Size: 1323 bytes Desc: not available URL: From savage at uri.edu Tue Oct 7 12:14:37 2008 From: savage at uri.edu (Brian Savage) Date: Tue, 7 Oct 2008 15:14:37 -0400 Subject: [sac-dev] readline/libedit patch In-Reply-To: References: <75F6391F-63EB-496D-BFBD-335B0CB5B5C9@uri.edu> Message-ID: <65FBC049-CE90-47DC-A070-41524D452EE2@uri.edu> Kuang I was looking at your readline patch to handle the real readline library when used with a script. http://www.iris.washington.edu/pipermail/sac-dev/2008-September/ 000109.html It looks like when the tty is not being used (use_tty()) you avoid the select_loop(). This seems fine with me. We also have very similar code in the zgtmsg () and the code you added looks a lot like the original zgpmsg() code. Can we do some consolidation here, possibly just within the zgpmsg() to begin with. and include code when with HAVE_LIBEDIT or HAVE_READLINE ( currently just READLINE) is true. To make the the code easier to handle in the future I would prefer the libedit and readline behave the same way if a tty is, or is not, encountered. - Use the select_loop() while in a tty session. - Avoid the select_loop() while no tty is available - Avoid the select_loop() while no line handling is available How about something like: #ifdef HAVE_READLINE || HAVE_LIBEDIT if( use_tty() ) { select_loop() } else { #endif /* HAVE READLINE || HAVE_LIBEDIT */ getfline() #ifdef HAVE_READLINE || HAVE_LIBEDIT } #endif /* HAVE READLINE || HAVE_LIBEDIT */ For reference: zgtmsg() is only called from src/exm/xpause.c src/exm/xnews.c src/cpf/cresp.c (Standard Error Recovery, not sure this is used) Cheers Brian From icrazy at gmail.com Tue Oct 7 18:23:29 2008 From: icrazy at gmail.com (Kuang He) Date: Tue, 7 Oct 2008 21:23:29 -0400 Subject: [sac-dev] readline/libedit patch In-Reply-To: <65FBC049-CE90-47DC-A070-41524D452EE2@uri.edu> References: <75F6391F-63EB-496D-BFBD-335B0CB5B5C9@uri.edu> <65FBC049-CE90-47DC-A070-41524D452EE2@uri.edu> Message-ID: On Tue, Oct 7, 2008 at 3:14 PM, Brian Savage wrote: > I was looking at your readline patch to handle the real readline library > when used with a script. > http://www.iris.washington.edu/pipermail/sac-dev/2008-September/000109.html > > It looks like when the tty is not being used (use_tty()) you avoid the > select_loop(). > This seems fine with me. We also have very similar code in the zgtmsg() and > the code you added looks a lot like the original zgpmsg() code. Dear Brian, I've been meaning to ask you about the similar codes in zgtmsg.c and zgpmsg.c. How come we need two sets of those functions in the first place? > Can we do some > consolidation here, possibly just within the zgpmsg() to begin with. and > include code > when with HAVE_LIBEDIT or HAVE_READLINE ( currently just READLINE) is true. Ideally, we could totally get rid of the file zgtmsg.c, couldn't we? > To make the the code easier to handle in the future I would prefer the > libedit and > readline behave the same way if a tty is, or is not, encountered. > > - Use the select_loop() while in a tty session. > - Avoid the select_loop() while no tty is available > - Avoid the select_loop() while no line handling is available > > How about something like: > > #ifdef HAVE_READLINE || HAVE_LIBEDIT > if( use_tty() ) { > select_loop() > } else { > #endif /* HAVE READLINE || HAVE_LIBEDIT */ > > getfline() > > #ifdef HAVE_READLINE || HAVE_LIBEDIT > } > #endif /* HAVE READLINE || HAVE_LIBEDIT */ I think this is a good idea. Will do in a while. > For reference: > zgtmsg() is only called from > src/exm/xpause.c > src/exm/xnews.c > src/cpf/cresp.c (Standard Error Recovery, not sure this is used) We don't need src/exm/xnews.c anymore, so I'm going to get rid of it -- one less thing to worry about. Is there anyway to get the dates of those sac2000 releases in file aux/news? There is a line in src/co/zgpmsg.c that reads: #if !defined(READLINE) && !defined(USE_X11_DOUBLE_BUFFER) I don't quite understand why USE_X11_DOUBLE_BUFFER has anything to do with line editing functionality. Could you please explain a bit? Thanks! Best regards, -- Kuang He Department of Physics University of Connecticut Storrs, CT 06269-3046 Tel: +1.860.486.4919 Web: http://www.phys.uconn.edu/~he/ From s.peacock at blacknest.gov.uk Tue Oct 7 23:43:01 2008 From: s.peacock at blacknest.gov.uk (Sheila Peacock) Date: Wed, 08 Oct 2008 07:43:01 +0100 Subject: [sac-dev] [Fwd: GSE writing] Message-ID: <48EC5675.70702@blacknest.gov.uk> Dear All, I sent this to SAC-help and got only one reply from someone else who had had the same problem, but no solution. Since you are working on the latest edition, I'm wondering if you have come across, and addressed, this problem. Regards, Sheila. -------- Original Message -------- Subject: GSE writing Date: Tue, 30 Sep 2008 08:05:05 +0100 From: Sheila Peacock Organization: AWE Blacknest To: sac-help at iris.washington.edu Dear All, SAC v. 101.1 either fails or crashes when I try to use "writegse". SAC v. 100 is OK with writegse. Is this a known bug? Regards, Sheila Peacock. SAC v. 100 (is OK) $ sacb SEISMIC ANALYSIS CODE [03/01/2005 (Version 100.00)] Copyright 1995 Regents of the University of California SAC> r 1986.213.14.03.12.3600.DW.COL..SHZ.D.SAC SAC> writegse 198608011403COL.gse.int Converting waveforms . Writing station data . Writing channel data . Writing arrival data . 1 waveforms written in 198608011403COL.gse.int SAC> end SAC v. 101.1 fails: $ sac1011 SEISMIC ANALYSIS CODE [01/19/2008 (Version 101.1)] Copyright 1995 Regents of the University of California SAC> r 1986.213.14.03.12.3600.DW.COL..SHZ.D.SAC SAC> writegse 198608011403COL.gse.int Segmentation fault or.... (trying various parameters in the parameter list) SAC> r 1986.213.14.03.12.3600.DW.COL..SHZ.D.SAC SAC> writegse int 198608011403COL.gse.int ERROR 1312: Bad number of files in write file list: SAC> writegse int source off 198608011403COL.gse.int ERROR 1312: Bad number of files in write file list: SAC> writegse int source off commit 198608011403COL.gse.int ERROR 1312: Bad number of files in write file list: $ sac1011 SEISMIC ANALYSIS CODE [01/19/2008 (Version 101.1)] Copyright 1995 Regents of the University of California SAC> r 1986.213.14.03.12.3600.DW.COL..SHZ.D.SAC SAC> writegse CM6 198608011403COL.gse.cm6 Segmentation fault From savage at uri.edu Wed Oct 8 06:46:48 2008 From: savage at uri.edu (Brian Savage) Date: Wed, 8 Oct 2008 09:46:48 -0400 Subject: [sac-dev] [Fwd: GSE writing] In-Reply-To: <48EC5675.70702@blacknest.gov.uk> References: <48EC5675.70702@blacknest.gov.uk> Message-ID: Sheila, I just checked versions 101.2 and 101.1 on my machine. It looks like 101.2 works, 101.1 does not. I will look further into this for a better answer. This bug was not known about. Thank you for being persistent. :) Cheers Brian savage at uri.edu On Oct 8, 2008, at 2:43 AM, Sheila Peacock wrote: > Dear All, > > I sent this to SAC-help and got only one reply from someone else > who had had the same problem, but no solution. Since you are > working on the latest edition, I'm wondering if you have come > across, and addressed, this problem. > > Regards, > Sheila. > > > -------- Original Message -------- > Subject: GSE writing > Date: Tue, 30 Sep 2008 08:05:05 +0100 > From: Sheila Peacock > Organization: AWE Blacknest > To: sac-help at iris.washington.edu > > Dear All, > > SAC v. 101.1 either fails or crashes when I try to use "writegse". > SAC v. 100 is OK > with writegse. Is this a known bug? > > Regards, > Sheila Peacock. > > SAC v. 100 (is OK) > $ sacb > SEISMIC ANALYSIS CODE [03/01/2005 (Version 100.00)] > Copyright 1995 Regents of the University of California > > SAC> r 1986.213.14.03.12.3600.DW.COL..SHZ.D.SAC > SAC> writegse 198608011403COL.gse.int > Converting waveforms . > Writing station data . > Writing channel data . > Writing arrival data . > 1 waveforms written in 198608011403COL.gse.int > SAC> end > > > SAC v. 101.1 fails: > > $ sac1011 > SEISMIC ANALYSIS CODE [01/19/2008 (Version 101.1)] > Copyright 1995 Regents of the University of California > > SAC> r 1986.213.14.03.12.3600.DW.COL..SHZ.D.SAC > SAC> writegse 198608011403COL.gse.int > Segmentation fault > > > or.... (trying various parameters in the parameter list) > > SAC> r 1986.213.14.03.12.3600.DW.COL..SHZ.D.SAC > SAC> writegse int 198608011403COL.gse.int > ERROR 1312: Bad number of files in write file list: > SAC> writegse int source off 198608011403COL.gse.int > ERROR 1312: Bad number of files in write file list: > SAC> writegse int source off commit 198608011403COL.gse.int > ERROR 1312: Bad number of files in write file list: > > $ sac1011 > SEISMIC ANALYSIS CODE [01/19/2008 (Version 101.1)] > Copyright 1995 Regents of the University of California > > SAC> r 1986.213.14.03.12.3600.DW.COL..SHZ.D.SAC > SAC> writegse CM6 198608011403COL.gse.cm6 > Segmentation fault > > _______________________________________________ > sac-dev mailing list > sac-dev at iris.washington.edu > http://www.iris.washington.edu/mailman/listinfo/sac-dev From savage at uri.edu Wed Oct 8 07:01:54 2008 From: savage at uri.edu (Brian Savage) Date: Wed, 8 Oct 2008 10:01:54 -0400 Subject: [sac-dev] readline/libedit patch In-Reply-To: References: <75F6391F-63EB-496D-BFBD-335B0CB5B5C9@uri.edu> <65FBC049-CE90-47DC-A070-41524D452EE2@uri.edu> Message-ID: <8618CC3B-F61C-4092-BB9E-3640298EB0FE@uri.edu> Kuang He, The difference between zgpmsg() and zgtmsg() is zgpmsg() currently adds commands to the history while zgtmsg() does not. I imagine there is an easy way to handle this. xnews: I would suggest leaving the function in, but short-circuiting it: print a message and return. Look for the DEPRECATED function in src/dff/f2c.c, this may be useful. The information is stored in aux/news. We can probably change the filename to HISTORY.old and reference it in the HISTORY file and/or the README file. double_buffer: This was added to fix the window redrawing problem on some systems (Linux). It was added at the same time as the libedit/readline functionality which is why it they are stuck together. You are correct that the double_buffer has nothing do do with libedit functionality, but the select() function does. At the time of adding this function, it was either use two (2) cases or use (4) cases. I opted for two and lumped in READLINE with DOUBLE_BUFFER. I think we should be able to remove the DOUBLE_BUFFER option and force sac to always use the double buffer in future releases. Cheers Brian On Oct 7, 2008, at 9:23 PM, Kuang He wrote: > On Tue, Oct 7, 2008 at 3:14 PM, Brian Savage wrote: >> I was looking at your readline patch to handle the real readline >> library >> when used with a script. >> http://www.iris.washington.edu/pipermail/sac-dev/2008-September/ >> 000109.html >> >> It looks like when the tty is not being used (use_tty()) you avoid >> the >> select_loop(). >> This seems fine with me. We also have very similar code in the >> zgtmsg() and >> the code you added looks a lot like the original zgpmsg() code. > > Dear Brian, > > I've been meaning to ask you about the similar codes in zgtmsg.c and > zgpmsg.c. How come we need two sets of those functions in the first > place? > >> Can we do some >> consolidation here, possibly just within the zgpmsg() to begin >> with. and >> include code >> when with HAVE_LIBEDIT or HAVE_READLINE ( currently just READLINE) >> is true. > > Ideally, we could totally get rid of the file zgtmsg.c, couldn't we? > >> To make the the code easier to handle in the future I would prefer >> the >> libedit and >> readline behave the same way if a tty is, or is not, encountered. >> >> - Use the select_loop() while in a tty session. >> - Avoid the select_loop() while no tty is available >> - Avoid the select_loop() while no line handling is available >> >> How about something like: >> >> #ifdef HAVE_READLINE || HAVE_LIBEDIT >> if( use_tty() ) { >> select_loop() >> } else { >> #endif /* HAVE READLINE || HAVE_LIBEDIT */ >> >> getfline() >> >> #ifdef HAVE_READLINE || HAVE_LIBEDIT >> } >> #endif /* HAVE READLINE || HAVE_LIBEDIT */ > > I think this is a good idea. Will do in a while. > >> For reference: >> zgtmsg() is only called from >> src/exm/xpause.c >> src/exm/xnews.c >> src/cpf/cresp.c (Standard Error Recovery, not sure this is used) > > We don't need src/exm/xnews.c anymore, so I'm going to get rid of it > -- one less thing to worry about. Is there anyway to get the dates of > those sac2000 releases in file aux/news? > > There is a line in src/co/zgpmsg.c that reads: > > #if !defined(READLINE) && !defined(USE_X11_DOUBLE_BUFFER) > > I don't quite understand why USE_X11_DOUBLE_BUFFER has anything to do > with line editing functionality. Could you please explain a bit? > Thanks! > > > Best regards, > > -- > Kuang He > Department of Physics > University of Connecticut > Storrs, CT 06269-3046 > > Tel: +1.860.486.4919 > Web: http://www.phys.uconn.edu/~he/ > _______________________________________________ > sac-dev mailing list > sac-dev at iris.washington.edu > http://www.iris.washington.edu/mailman/listinfo/sac-dev From savage at uri.edu Wed Oct 8 07:17:08 2008 From: savage at uri.edu (Brian Savage) Date: Wed, 8 Oct 2008 10:17:08 -0400 Subject: [sac-dev] [SAC-HELP] [Fwd: GSE writing] In-Reply-To: References: <48EC5675.70702@blacknest.gov.uk> Message-ID: Shelia, After a bit of looking ... The SeisMgr database in SAC is responsible for writing GSE files. If the SeisMgr database is off the writing of GSE files fails. Version: If SeisMgr database on by default v100.0: On v101.1: Off (writegse fails) v101.2: On The SeisMgr database should is now be on by default in v101.2 as well as in future versions. To turn on the database set the environment variable in sh or csh (in v101.1 and later) sh% export SAC_USE_DATABASE=1 csh% setenv SAC_USE_DATABASE 1 Sorry for the headaches. Cheers Brian On Oct 8, 2008, at 9:46 AM, Brian Savage wrote: > Sheila, > > I just checked versions 101.2 and 101.1 on my machine. > It looks like 101.2 works, 101.1 does not. > I will look further into this for a better answer. > > This bug was not known about. Thank you for being persistent. :) > > Cheers > Brian > savage at uri.edu > > > On Oct 8, 2008, at 2:43 AM, Sheila Peacock wrote: > >> Dear All, >> >> I sent this to SAC-help and got only one reply from someone else >> who had had the same problem, but no solution. Since you are >> working on the latest edition, I'm wondering if you have come >> across, and addressed, this problem. >> >> Regards, >> Sheila. >> >> >> -------- Original Message -------- >> Subject: GSE writing >> Date: Tue, 30 Sep 2008 08:05:05 +0100 >> From: Sheila Peacock >> Organization: AWE Blacknest >> To: sac-help at iris.washington.edu >> >> Dear All, >> >> SAC v. 101.1 either fails or crashes when I try to use >> "writegse". SAC v. 100 is OK >> with writegse. Is this a known bug? >> >> Regards, >> Sheila Peacock. >> >> SAC v. 100 (is OK) >> $ sacb >> SEISMIC ANALYSIS CODE [03/01/2005 (Version 100.00)] >> Copyright 1995 Regents of the University of California >> >> SAC> r 1986.213.14.03.12.3600.DW.COL..SHZ.D.SAC >> SAC> writegse 198608011403COL.gse.int >> Converting waveforms . >> Writing station data . >> Writing channel data . >> Writing arrival data . >> 1 waveforms written in 198608011403COL.gse.int >> SAC> end >> >> >> SAC v. 101.1 fails: >> >> $ sac1011 >> SEISMIC ANALYSIS CODE [01/19/2008 (Version 101.1)] >> Copyright 1995 Regents of the University of California >> >> SAC> r 1986.213.14.03.12.3600.DW.COL..SHZ.D.SAC >> SAC> writegse 198608011403COL.gse.int >> Segmentation fault >> >> >> or.... (trying various parameters in the parameter list) >> >> SAC> r 1986.213.14.03.12.3600.DW.COL..SHZ.D.SAC >> SAC> writegse int 198608011403COL.gse.int >> ERROR 1312: Bad number of files in write file list: >> SAC> writegse int source off 198608011403COL.gse.int >> ERROR 1312: Bad number of files in write file list: >> SAC> writegse int source off commit 198608011403COL.gse.int >> ERROR 1312: Bad number of files in write file list: >> >> $ sac1011 >> SEISMIC ANALYSIS CODE [01/19/2008 (Version 101.1)] >> Copyright 1995 Regents of the University of California >> >> SAC> r 1986.213.14.03.12.3600.DW.COL..SHZ.D.SAC >> SAC> writegse CM6 198608011403COL.gse.cm6 >> Segmentation fault >> >> _______________________________________________ >> sac-dev mailing list >> sac-dev at iris.washington.edu >> http://www.iris.washington.edu/mailman/listinfo/sac-dev > > _______________________________________________ > sac-help mailing list > sac-help at iris.washington.edu > http://www.iris.washington.edu/mailman/listinfo/sac-help From icrazy at gmail.com Thu Oct 9 16:36:08 2008 From: icrazy at gmail.com (Kuang He) Date: Thu, 9 Oct 2008 19:36:08 -0400 Subject: [sac-dev] readline/libedit patch In-Reply-To: <65FBC049-CE90-47DC-A070-41524D452EE2@uri.edu> References: <75F6391F-63EB-496D-BFBD-335B0CB5B5C9@uri.edu> <65FBC049-CE90-47DC-A070-41524D452EE2@uri.edu> Message-ID: Dear Brian, Attached is a patch (on top of my original patches) that does the following: - define HAVE_LIBEDIT and HAVE_READLINE, and get rid of the original READLINE in configure.in - update corresponding source code due to the above change - Consolidate zgpmsg() implementations in src/co/zgpmsg.c - reverse part of a previous change in Makefile.in's that intends to get rid of duplicate -I../inc, which would also cause a compile failure however Best regards, -- Kuang He Department of Physics University of Connecticut Storrs, CT 06269-3046 Tel: +1.860.486.4919 Web: http://www.phys.uconn.edu/~he/ On Tue, Oct 7, 2008 at 3:14 PM, Brian Savage wrote: > Kuang > > I was looking at your readline patch to handle the real readline library > when used with a script. > http://www.iris.washington.edu/pipermail/sac-dev/2008-September/000109.html > > It looks like when the tty is not being used (use_tty()) you avoid the > select_loop(). > This seems fine with me. We also have very similar code in the zgtmsg() and > the code you added looks a lot like the original zgpmsg() code. Can we do > some > consolidation here, possibly just within the zgpmsg() to begin with. and > include code > when with HAVE_LIBEDIT or HAVE_READLINE ( currently just READLINE) is true. > To make the the code easier to handle in the future I would prefer the > libedit and > readline behave the same way if a tty is, or is not, encountered. > > - Use the select_loop() while in a tty session. > - Avoid the select_loop() while no tty is available > - Avoid the select_loop() while no line handling is available > > How about something like: > > #ifdef HAVE_READLINE || HAVE_LIBEDIT > if( use_tty() ) { > select_loop() > } else { > #endif /* HAVE READLINE || HAVE_LIBEDIT */ > > getfline() > > #ifdef HAVE_READLINE || HAVE_LIBEDIT > } > #endif /* HAVE READLINE || HAVE_LIBEDIT */ > > For reference: > zgtmsg() is only called from > src/exm/xpause.c > src/exm/xnews.c > src/cpf/cresp.c (Standard Error Recovery, not sure this is used) -------------- next part -------------- A non-text attachment was scrubbed... Name: zgpmsg-consolidation.patch Type: application/octet-stream Size: 11843 bytes Desc: not available URL: From tilmann at esc.cam.ac.uk Thu Oct 16 07:31:07 2008 From: tilmann at esc.cam.ac.uk (Frederik Tilmann) Date: Thu, 16 Oct 2008 15:31:07 +0100 Subject: [sac-dev] Suggestion regarding external commands Message-ID: <48F7502B.2000808@esc.cam.ac.uk> Dear all one of the little used but very useful features of sac is the availability to write user-defined commands (those which are loaded via load). What do you think about introducing a reposity for these on the sac website which would allow users to share these self-made commands. Maybe the best of them could eventually become part of the core code in future version. Frederik -- Frederik Tilmann Bullard Laboratories Tel. +44 1223 765545 Department of Earth Sciences Fax. +44 1223 360779 University of Cambridge email: tilmann at esc.cam.ac.uk Madingley Road http://bullard.esc.cam.ac.uk/~tilmann Cambridge CB3 0EZ UK From savage at uri.edu Mon Oct 20 14:52:24 2008 From: savage at uri.edu (Brian Savage) Date: Mon, 20 Oct 2008 17:52:24 -0400 Subject: [sac-dev] pager patch In-Reply-To: References: <75F6391F-63EB-496D-BFBD-335B0CB5B5C9@uri.edu> Message-ID: <27FEFED5-3F3C-4474-89A5-D6C6F04DE185@uri.edu> Kuang He, I tested your pager patch and was quite happy with it. The one which searches /bin and /usr/bin for less and then more If any one else would like to comment on this patch, please do so. It is labeled as [1] below. Cheers Brian > > [1] http://www.iris.washington.edu/pipermail/sac-dev/2008-September/ > 000108.html