|
From: Nicholas N. <n.n...@gm...> - 2009-05-26 00:59:50
|
Hi, I think the DARWIN branch is in a good enough state that it's ready to be merged with the trunk. Excluding Helgrind, DRD and Ptrcheck, I get only 11 regtest failures on my MacBook Pro, which is better than the result for some Linux systems. (I haven't made much of an effort to get Helgrind, DRD and Ptrcheck working on Darwin yet because they are the least-used tools. That's future work.) The Darwin-specific code still requires some cleaning up -- look for comments containing "DDD" and/or "GrP" if you want an idea -- but it's in a good enough state that maintaining a separate branch for it is no longer worth the effort. I've recently done a lot of commits to synchronise the branch with the trunk. The net result is that the branch/trunk diff now contains mostly new, Darwin-specific code; there's only a small amount of trunk code that is modified. The 31,102 line diff is available at www.valgrind.org/njn/trunk-DARWIN-r10152.diff.bz2, it's from r10152. I propose doing the merge in two day's time, ie. some time Thursday (Melbourne time). If interested people could look over the diff, that would be helpful. It would also be very helpful if we could avoid making commits to the trunk or the DARWIN branch in the meantime. Any comments? Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-05-28 03:36:16
|
On Tue, May 26, 2009 at 10:31 AM, Nicholas Nethercote <n.n...@gm...> wrote: > Hi, > > I think the DARWIN branch is in a good enough state that it's ready to > be merged with the trunk. > [...] > I propose doing the merge in two day's time, ie. some time Thursday > (Melbourne time). This is now done, and I've added code to the branch so it aborts on start-up with a message saying you should use the trunk instead. Any existing Valgrind-on-Mac users should check out the trunk like so: svn co svn://svn.valgrind.org/valgrind/branches/DARWIN <dirname> cd <dirname> and build according to the instructions in the README. Nick |
|
From: Julian S. <js...@ac...> - 2009-05-28 17:50:39
|
On Thursday 28 May 2009, Nicholas Nethercote wrote: > On Tue, May 26, 2009 at 10:31 AM, Nicholas Nethercote > > <n.n...@gm...> wrote: > > Hi, > > > > I think the DARWIN branch is in a good enough state that it's ready to > > be merged with the trunk. > > [...] > > I propose doing the merge in two day's time, ie. some time Thursday > > (Melbourne time). > > This is now done, Amazing stuff; great work. Good to finally have it done. J |
|
From: Nicholas N. <n.n...@gm...> - 2009-05-28 04:34:11
|
On Thu, May 28, 2009 at 1:36 PM, Nicholas Nethercote <n.n...@gm...> wrote: > On Tue, May 26, 2009 at 10:31 AM, Nicholas Nethercote > <n.n...@gm...> wrote: >> Hi, >> >> I think the DARWIN branch is in a good enough state that it's ready to >> be merged with the trunk. >> [...] >> I propose doing the merge in two day's time, ie. some time Thursday >> (Melbourne time). > > This is now done, and I've added code to the branch so it aborts on > start-up with a message saying you should use the trunk instead. > > Any existing Valgrind-on-Mac users should check out the trunk like so: > > svn co svn://svn.valgrind.org/valgrind/branches/DARWIN <dirname> That should be: svn co svn://svn.valgrind.org/valgrind/trunk <dirname> Nick |
|
From: Filipe C. <fi...@gm...> - 2009-05-28 07:12:29
|
Thank you! Now I can use the trunk :-) Just a thought: Couldn't the DARWIN merge abort in configure, so people wouldn't have to compile it just to know it's defunct? Keep up the good work! F On Thu, May 28, 2009 at 05:34, Nicholas Nethercote <n.n...@gm...>wrote: > On Thu, May 28, 2009 at 1:36 PM, Nicholas Nethercote > <n.n...@gm...> wrote: > > On Tue, May 26, 2009 at 10:31 AM, Nicholas Nethercote > > <n.n...@gm...> wrote: > >> Hi, > >> > >> I think the DARWIN branch is in a good enough state that it's ready to > >> be merged with the trunk. > >> [...] > >> I propose doing the merge in two day's time, ie. some time Thursday > >> (Melbourne time). > > > > This is now done, and I've added code to the branch so it aborts on > > start-up with a message saying you should use the trunk instead. > > > > Any existing Valgrind-on-Mac users should check out the trunk like so: > > > > svn co svn://svn.valgrind.org/valgrind/branches/DARWIN <dirname> > > That should be: > > svn co svn://svn.valgrind.org/valgrind/trunk <dirname> > > Nick > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. > Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Nicholas N. <n.n...@gm...> - 2009-05-28 22:33:48
|
On Thu, May 28, 2009 at 5:12 PM, Filipe Cabecinhas <fi...@gm...> wrote: > Thank you! Now I can use the trunk :-) > > Just a thought: Couldn't the DARWIN merge abort in configure, so people > wouldn't have to compile it just to know it's defunct? It could, I didn't think of that. I've added an abort there too. I kept the one in m_main.c too in case people update without rerunning autoconf. Nick |
|
From: Bart V. A. <bar...@gm...> - 2009-06-03 06:34:23
|
On Thu, May 28, 2009 at 5:36 AM, Nicholas Nethercote <n.n...@gm...> wrote: > On Tue, May 26, 2009 at 10:31 AM, Nicholas Nethercote > <n.n...@gm...> wrote: >> Hi, >> >> I think the DARWIN branch is in a good enough state that it's ready to >> be merged with the trunk. >> [...] >> I propose doing the merge in two day's time, ie. some time Thursday >> (Melbourne time). > > This is now done, and I've added code to the branch so it aborts on > start-up with a message saying you should use the trunk instead. > > Any existing Valgrind-on-Mac users should check out the trunk like so: > > svn co svn://svn.valgrind.org/valgrind/branches/DARWIN <dirname> > cd <dirname> > > and build according to the instructions in the README. It is indeed great news that the Valgrind trunk now compiles on Darwin. But making sure that Valgrind compiles and runs fine on Darwin or any other OS is not just a one time effort. At least in theory, every single commit, even when tested properly one one OS, has the potential to break something on another OS. In other words, if we do not want to abuse Mac users as testers of the trunk, we have to make sure that the nightly build does not only run on Linux systems but also on at least one Darwin system. Bart. |
|
From: Julian S. <js...@ac...> - 2009-06-03 08:28:06
|
> not want to abuse Mac users as testers of the trunk, we have to make > sure that the nightly build does not only run on Linux systems but > also on at least one Darwin system. Will MacOS run on VMware et al? I think the basic problem is to find a MacOS machine that runs 24x7. I only have Linux machines that run 24x7 and I think the same is true for Nick. J |
|
From: Bart V. A. <bar...@gm...> - 2009-06-03 08:35:32
|
On Wed, Jun 3, 2009 at 10:30 AM, Julian Seward <js...@ac...> wrote: > >> not want to abuse Mac users as testers of the trunk, we have to make >> sure that the nightly build does not only run on Linux systems but >> also on at least one Darwin system. > > Will MacOS run on VMware et al? I think the basic problem is to find > a MacOS machine that runs 24x7. I only have Linux machines that run > 24x7 and I think the same is true for Nick. According to the information I found it is possible to run MacOS on VMware but doing so violates the MacOS EULA (http://communities.vmware.com/thread/16346). However, I don't know whether that information is correct neither whether it is up to date. Bart. |
|
From: Michael S. <ms...@ap...> - 2009-06-03 15:34:06
|
Mac OS X Server will, but the regular desktop OS won't. On Jun 3, 2009, at 1:30 AM, Julian Seward wrote: > >> not want to abuse Mac users as testers of the trunk, we have to make >> sure that the nightly build does not only run on Linux systems but >> also on at least one Darwin system. > > Will MacOS run on VMware et al? I think the basic problem is to find > a MacOS machine that runs 24x7. I only have Linux machines that run > 24x7 and I think the same is true for Nick. > > J > > > ------------------------------------------------------------------------------ > OpenSolaris 2009.06 is a cutting edge operating system for enterprises > looking to deploy the next generation of Solaris that includes the > latest > innovations from Sun and the OpenSource community. Download a copy and > enjoy capabilities such as Networking, Storage and Virtualization. > Go to: http://p.sf.net/sfu/opensolaris-get > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers ________________________________________ Michael R Sweet, Senior Printing System Engineer |
|
From: Greg P. <gp...@ap...> - 2009-06-03 19:06:52
|
On Jun 3, 2009, at 1:30 AM, Julian Seward wrote: >> not want to abuse Mac users as testers of the trunk, we have to make >> sure that the nightly build does not only run on Linux systems but >> also on at least one Darwin system. > > Will MacOS run on VMware et al? I think the basic problem is to find > a MacOS machine that runs 24x7. I only have Linux machines that run > 24x7 and I think the same is true for Nick. I might be able to arrange for something here. What does the test machinery look like? -- Greg Parker gp...@ap... Runtime Wrangler |
|
From: alex g. <ale...@hm...> - 2009-06-03 20:21:20
|
I have an underused Mac OsX machine dedicated to tests that runs 24x7. if you tell me how to test, I can run it daily. alex. On Jun 3, 2009, at 3:06 PM, Greg Parker wrote: > On Jun 3, 2009, at 1:30 AM, Julian Seward wrote: >>> not want to abuse Mac users as testers of the trunk, we have to make >>> sure that the nightly build does not only run on Linux systems but >>> also on at least one Darwin system. >> >> Will MacOS run on VMware et al? I think the basic problem is to find >> a MacOS machine that runs 24x7. I only have Linux machines that run >> 24x7 and I think the same is true for Nick. > > I might be able to arrange for something here. What does the test > machinery look like? > > > -- > Greg Parker gp...@ap... Runtime Wrangler > > > > ------------------------------------------------------------------------------ > OpenSolaris 2009.06 is a cutting edge operating system for enterprises > looking to deploy the next generation of Solaris that includes the > latest > innovations from Sun and the OpenSource community. Download a copy and > enjoy capabilities such as Networking, Storage and Virtualization. > Go to: http://p.sf.net/sfu/opensolaris-get > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Nicholas N. <n.n...@gm...> - 2009-06-04 00:01:16
|
On Thu, Jun 4, 2009 at 5:06 AM, Greg Parker <gp...@ap...> wrote: > On Jun 3, 2009, at 1:30 AM, Julian Seward wrote: >>> not want to abuse Mac users as testers of the trunk, we have to make >>> sure that the nightly build does not only run on Linux systems but >>> also on at least one Darwin system. >> >> Will MacOS run on VMware et al? I think the basic problem is to find >> a MacOS machine that runs 24x7. I only have Linux machines that run >> 24x7 and I think the same is true for Nick. > > I might be able to arrange for something here. What does the test > machinery look like? We now have three offers for test machines (thanks!) I'm currently rewriting the instructions to make them much clearer. Also, it looks like there might be some GNU-vs-BSD-sed issues in the script, which I'll look at when I've finished the instructions. I'll report back in a while. Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-06-04 01:01:53
|
On Thu, Jun 4, 2009 at 10:01 AM, Nicholas Nethercote <n.n...@gm...> wrote: > > Also, it looks like there might be some GNU-vs-BSD-sed issues in the > script, which I'll look at when I've finished the instructions. I'll > report back in a while. Argh, turns out it's GNU-vs-BSD issues to do with 'date'. On GNU, you specify the date 24 hours ago like this: date --date=yesterday on BSD you do this date -v-24H Neither of these are POSIX; POSIX date doesn't seem to have the capability of returning dates other than "now". So unless anyone knows something that'll work on all platforms, looks like we'll be doing platform tests or trying variants until something works. Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-06-04 02:19:35
|
On Thu, Jun 4, 2009 at 10:37 AM, Nicholas Nethercote <n.n...@gm...> wrote: > Argh, turns out it's GNU-vs-BSD issues to do with 'date'. On GNU, you > specify the date 24 hours ago like this: > > date --date=yesterday > > on BSD you do this > > date -v-24H I've fixed this and another minor issue. It seems to run ok on Darwin now. Now we just have to work out who will run the tests. We have offers from Michael, Alex and Greg. Care to fight it out amongst yourselves? :) Nick |
|
From: alex g. <ale...@hm...> - 2009-06-04 03:18:39
|
the more tests, the better, no? ;) On Jun 3, 2009, at 9:53 PM, Nicholas Nethercote wrote: > On Thu, Jun 4, 2009 at 10:37 AM, Nicholas Nethercote > <n.n...@gm...> wrote: >> Argh, turns out it's GNU-vs-BSD issues to do with 'date'. On GNU, >> you >> specify the date 24 hours ago like this: >> >> date --date=yesterday >> >> on BSD you do this >> >> date -v-24H > > I've fixed this and another minor issue. It seems to run ok on > Darwin now. > > Now we just have to work out who will run the tests. We have offers > from Michael, Alex and Greg. Care to fight it out amongst yourselves? > :) > > Nick > > ------------------------------------------------------------------------------ > OpenSolaris 2009.06 is a cutting edge operating system for enterprises > looking to deploy the next generation of Solaris that includes the > latest > innovations from Sun and the OpenSource community. Download a copy and > enjoy capabilities such as Networking, Storage and Virtualization. > Go to: http://p.sf.net/sfu/opensolaris-get > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Michael S. <ms...@ap...> - 2009-06-05 15:19:12
|
On Jun 3, 2009, at 6:53 PM, Nicholas Nethercote wrote: > On Thu, Jun 4, 2009 at 10:37 AM, Nicholas Nethercote > <n.n...@gm...> wrote: >> Argh, turns out it's GNU-vs-BSD issues to do with 'date'. On GNU, >> you >> specify the date 24 hours ago like this: >> >> date --date=yesterday >> >> on BSD you do this >> >> date -v-24H > > I've fixed this and another minor issue. It seems to run ok on > Darwin now. > > Now we just have to work out who will run the tests. We have offers > from Michael, Alex and Greg. Care to fight it out amongst yourselves? > :) Well, since I already have everything setup, I'm going to turn my system on once I verify the results this morning... But like Alex said, it won't hurt to have a few systems running the tests anyways (you already do for Linux...) ________________________________________ Michael R Sweet, Senior Printing System Engineer |
|
From: Nicholas N. <n.n...@gm...> - 2009-06-05 22:59:24
|
On Sat, Jun 6, 2009 at 1:19 AM, Michael Sweet <ms...@ap...> wrote: > > Well, since I already have everything setup, I'm going to turn my system on > once I verify the results this morning... Excellent, thanks. I hope the improved README.txt made things easier. > But like Alex said, it won't > hurt to have a few systems running the tests anyways (you already do for > Linux...) Sure. Nick |
|
From: Michael S. <ms...@ap...> - 2009-06-05 23:29:50
|
On Jun 5, 2009, at 3:59 PM, Nicholas Nethercote wrote: > On Sat, Jun 6, 2009 at 1:19 AM, Michael Sweet <ms...@ap...> > wrote: >> >> Well, since I already have everything setup, I'm going to turn my >> system on >> once I verify the results this morning... > > Excellent, thanks. I hope the improved README.txt made things easier. They are definitely an improvement, but for me the best changes were to the nightly script so that I could actually run it! :P Anyways, they should be going out now, the main issue that I saw in the first report was that one of the tests wouldn't build since <stdint.h> wasn't being included (for uint32_t). ________________________________________ Michael R Sweet, Senior Printing System Engineer |
|
From: Nicholas N. <n.n...@gm...> - 2009-06-06 02:05:01
|
On Sat, Jun 6, 2009 at 9:29 AM, Michael Sweet <ms...@ap...> wrote: > Anyways, they should be going out now, the main issue that I saw in the first report was that one of the tests wouldn't build since <stdint.h> wasn't being included (for uint32_t). Is that memcheck/tests/x86/more_x86_fp.c? Hmm, if anyone can explain, I'd love to know why it compiles on my machine and not yours. Nick |
|
From: Michael R S. <ms...@ap...> - 2009-06-06 03:56:15
|
Nicholas Nethercote wrote:
> On Sat, Jun 6, 2009 at 9:29 AM, Michael Sweet <ms...@ap...> wrote:
>> Anyways, they should be going out now, the main issue that I saw in the first report was that one of the tests wouldn't build since <stdint.h> wasn't being included (for uint32_t).
>
> Is that memcheck/tests/x86/more_x86_fp.c? Hmm, if anyone can explain,
> I'd love to know why it compiles on my machine and not yours.
Nope, fdleak_cmsg.c:
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include
-I../../coregrind -I../
../include -I../../VEX/pub -DVGA_x86=1 -DVGO_darwin=1 -DVGP_x86_darwin=1
-Winli
ne -Wall -Wshadow -g -arch i386 -Wno-long-long -Wno-pointer-sign
-Wdeclaration-a
fter-statement -fno-stack-protector -MT execve.o -MD -MP -MF
.deps/execve.Tpo -c
-o execve.o execve.c
mv -f .deps/execve.Tpo .deps/execve.Po
gcc -Winline -Wall -Wshadow -g -arch i386 -Wno-long-long
-Wno-pointer-sign -Wdec
laration-after-statement -fno-stack-protector -o execve execve.o
gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include
-I../../coregrind -I../
../include -I../../VEX/pub -DVGA_x86=1 -DVGO_darwin=1 -DVGP_x86_darwin=1
-Winli
ne -Wall -Wshadow -g -arch i386 -Wno-long-long -Wno-pointer-sign
-Wdeclaration-a
fter-statement -fno-stack-protector -MT faultstatus.o -MD -MP -MF
.deps/faultsta
tus.Tpo -c -o faultstatus.o faultstatus.c
mv -f .deps/faultstatus.Tpo .deps/faultstatus.Po
gcc -Winline -Wall -Wshadow -g -arch i386 -Wno-long-long
-Wno-pointer-sign -Wdec
laration-after-statement -fno-stack-protector -o faultstatus
faultstatus.o
gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include
-I../../coregrind -I../
../include -I../../VEX/pub -DVGA_x86=1 -DVGO_darwin=1 -DVGP_x86_darwin=1
-Winli
ne -Wall -Wshadow -g -arch i386 -Wno-long-long -Wno-pointer-sign
-Wdeclaration-a
fter-statement -fno-stack-protector -MT fcntl_setown.o -MD -MP -MF
.deps/fcntl_s
etown.Tpo -c -o fcntl_setown.o fcntl_setown.c
mv -f .deps/fcntl_setown.Tpo .deps/fcntl_setown.Po
gcc -Winline -Wall -Wshadow -g -arch i386 -Wno-long-long
-Wno-pointer-sign -Wdec
laration-after-statement -fno-stack-protector -o fcntl_setown
fcntl_setown.o
gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include
-I../../coregrind -I../
../include -I../../VEX/pub -DVGA_x86=1 -DVGO_darwin=1 -DVGP_x86_darwin=1
-Winli
ne -Wall -Wshadow -g -arch i386 -Wno-long-long -Wno-pointer-sign
-Wdeclaration-a
fter-statement -fno-stack-protector -MT fdleak_cmsg.o -MD -MP -MF
.deps/fdleak_c
msg.Tpo -c -o fdleak_cmsg.o fdleak_cmsg.c
fdleak_cmsg.c: In function 'client':
fdleak_cmsg.c:139: error: 'uint32_t' undeclared (first use in this function)
fdleak_cmsg.c:139: error: (Each undeclared identifier is reported only once
fdleak_cmsg.c:139: error: for each function it appears in.)
make[5]: *** [fdleak_cmsg.o] Error 1
make[4]: *** [check-am] Error 2
make[3]: *** [check-recursive] Error 1
make[2]: *** [check-recursive] Error 1
make[1]: *** [check-recursive] Error 1
make: *** [check] Error 2
--
______________________________________________________________________
Michael R Sweet Senior Printing System Engineer
|
|
From: Nicholas N. <n.n...@gm...> - 2009-06-06 06:55:03
|
On Sat, Jun 6, 2009 at 1:56 PM, Michael R Sweet <ms...@ap...> wrote: > Nicholas Nethercote wrote: >> >>> Anyways, they should be going out now, the main issue that I saw in the >>> first report was that one of the tests wouldn't build since <stdint.h> >>> wasn't being included (for uint32_t). >> >> Is that memcheck/tests/x86/more_x86_fp.c? Hmm, if anyone can explain, >> I'd love to know why it compiles on my machine and not yours. > > Nope, fdleak_cmsg.c: Weird... the relevant macro (CMSG_NXTHDR) in sys/socket.h doesn't use uint32_t on my system, but it does use __darwin_int_ptr_t. What OS version are you running? Nick |
|
From: Michael R S. <ms...@ap...> - 2009-06-06 18:50:38
|
Nicholas Nethercote wrote: > On Sat, Jun 6, 2009 at 1:56 PM, Michael R Sweet <ms...@ap...> wrote: >> Nicholas Nethercote wrote: >>>> Anyways, they should be going out now, the main issue that I saw in the >>>> first report was that one of the tests wouldn't build since <stdint.h> >>>> wasn't being included (for uint32_t). >>> Is that memcheck/tests/x86/more_x86_fp.c? Hmm, if anyone can explain, >>> I'd love to know why it compiles on my machine and not yours. >> Nope, fdleak_cmsg.c: > > Weird... the relevant macro (CMSG_NXTHDR) in sys/socket.h doesn't use > uint32_t on my system, but it does use __darwin_int_ptr_t. What OS > version are you running? This particular system is running 10.5.7 Server. I just tried a fresh checkout, autogen.sh, configure, make, and make regtest and didn't get the error on this system. Perhaps there is something different about the nightly build path? -- ______________________________________________________________________ Michael R Sweet Senior Printing System Engineer |
|
From: Nicholas N. <n.n...@gm...> - 2009-06-06 21:51:19
|
On Sun, Jun 7, 2009 at 4:50 AM, Michael R Sweet<ms...@ap...> wrote:
>
> I just tried a fresh checkout, autogen.sh, configure, make, and make
> regtest and didn't get the error on this system. Perhaps there is
> something different about the nightly build path?
You can look in the old.verbose and new.verbose files for a full log
of what's happened. Maybe if you replicate exactly the commands in
those you'll be able to work out the problem. The commands used are
very similar to those above.
Or, maybe there is some environment difference between running those
by hand and running under whatever scheduling program you're using?
And if it's any use, here's what CMSG_NXTHDR looks like on my vanilla
10.5.7 system:
/* given pointer to struct cmsghdr, return pointer to next cmsghdr */
#define CMSG_NXTHDR(mhdr, cmsg) \
(((unsigned char *)(cmsg) +
__DARWIN_ALIGN((__darwin_intptr_t)(cmsg)->cmsg_len) + \
__DARWIN_ALIGN(sizeof(struct cmsghdr)) > \
(unsigned char *)(mhdr)->msg_control + (mhdr)->msg_controllen) ? \
(struct cmsghdr *)0L /* NULL */ : \
(struct cmsghdr *)((unsigned char *)(cmsg) +
__DARWIN_ALIGN((__darwin_intptr_t)(cmsg)->cmsg_len)))
Nick
|
|
From: Greg P. <gp...@ap...> - 2009-06-06 22:53:41
|
On Jun 6, 2009, at 2:50 PM, Nicholas Nethercote wrote: > On Sun, Jun 7, 2009 at 4:50 AM, Michael R Sweet<ms...@ap...> > wrote: >> >> I just tried a fresh checkout, autogen.sh, configure, make, and make >> regtest and didn't get the error on this system. Perhaps there is >> something different about the nightly build path? > > You can look in the old.verbose and new.verbose files for a full log > of what's happened. Maybe if you replicate exactly the commands in > those you'll be able to work out the problem. The commands used are > very similar to those above. > > Or, maybe there is some environment difference between running those > by hand and running under whatever scheduling program you're using? Running that compile with -E to get preprocessed output might be informative. -- Greg Parker gp...@ap... Runtime Wrangler |