Thread: msvc and vista fun
I am still very unhappy about the way the MSVC builds work. Although we have managed to make it sort of work with the buildfarm script, it is distinctly fragile. Last night, for example, I had a build failure due to a badly installed zlib. The error state didn't come back to the buildfarm script, which carried on merrily to the check stage, which also naturally failed, but also didn't manage to give back an error state to the buildfarm script, and finally got a failure at the install stage. That means that we simply can't rely on this build system to give us accurate state on the buildfarm - we might have had a code breakage but it won't always tell us that. Part of the problem, it seems to me, is that this build system is a hodge-podge of Perl programs and Windows shell scripts. In at least one case we call perl to write a dynamically generated .bat file which we then execute. Since the perl is pretty much indispensable (or at least would need replacing by an engine of similar capability), I think we should make the whole thing a perl suite with some very minimal .bat wrappers if necessary. On a somewhat related note, I have had spectacular lack of success in getting either MSVC or MinGW builds to work on Vista - so much so that I have currently abandoned my attempts on that platform and I resorted to resuscitating an old XP box for testing. Following some advice from Magnus, I added ACLs to the build root for both an admin and a non-admin user (cacls buildroot /E /T /G AdminUser:C and similarly for a non-admin user) . I can build as the admin user but when I come to run initdb it fails, complaining that it can't find the postgres executable. If I then switch to the non-admin user, it can run initdb just fine. However, that user can't build, because it gets a mysterious failure from mt.exe. MinGW is even worse - it says it can't run gcc because it can't run cc1.exe (IIRC), so it fails at the configure stage! All of this has cost me quite a few hours in the last week, with very little to show for it. Perhaps someone would like to tell me how I can remedy these problems. More importantly, this should be in an FAQ or some such. Also, I would like to know if we have really tested out on Vista the privilege surrendering code that is is supposed to work in Windows. It looks to me like it might not be working. If we can make progress on these issues then I'll be happy. If not, I think we need to look carefully at what we say we can support, and what we declare to be still experimental. cheers andrew
Andrew Dunstan wrote: > On a somewhat related note, I have had spectacular lack of success in > getting either MSVC or MinGW builds to work on Vista - so much so that I > have currently abandoned my attempts on that platform and I resorted to > resuscitating an old XP box for testing. Following some advice from > Magnus, I added ACLs to the build root for both an admin and a non-admin > user (cacls buildroot /E /T /G AdminUser:C and similarly for a non-admin > user) . I can build as the admin user but when I come to run initdb it > fails, complaining that it can't find the postgres executable. Yeah, I ran into that problem as well. I'll look at my Vista box when I'm in the office tomorrow and see if I can figure out what hack fixed it for me. If I then > switch to the non-admin user, it can run initdb just fine. However, that > user can't build, because it gets a mysterious failure from mt.exe. > MinGW is even worse - it says it can't run gcc because it can't run > cc1.exe (IIRC), so it fails at the configure stage! All of this has cost > me quite a few hours in the last week, with very little to show for it. And that one... > Perhaps someone would like to tell me how I can remedy these problems. > More importantly, this should be in an FAQ or some such. Also, I would > like to know if we have really tested out on Vista the privilege > surrendering code that is is supposed to work in Windows. It looks to me > like it might not be working. What makes you say that? > If we can make progress on these issues then I'll be happy. If not, I > think we need to look carefully at what we say we can support, and what > we declare to be still experimental. Lack of completely reliable buildfarm support for MSVC or trouble setting up a buildenv doesn't mean we cannot support a platform - it just means we need o be extra vigilent to ensure that regresssion tests etc. do actually pass (though that level of failure would be visible on the BF I would hope - it certainly has been until now). Regards, Dave
Andrew Dunstan wrote: > > I am still very unhappy about the way the MSVC builds work. Although we > have managed to make it sort of work with the buildfarm script, it is > distinctly fragile. Last night, for example, I had a build failure due > to a badly installed zlib. The error state didn't come back to the > buildfarm script, which carried on merrily to the check stage, which > also naturally failed, but also didn't manage to give back an error I've heard you report this before, and I've tried and failed many times to reproduce it. It has *always* come back with the proper errorlevel when I've tried. So two questions: 1) are you absolutely sure that the problem is not in the buildfarm script? 2) What exactly was the error? So I can try to reproduce that exact problem here and see if I can find out what it is. What did you do wrong, and what was the error messages if you still have the log. > state to the buildfarm script, and finally got a failure at the install > stage. That means that we simply can't rely on this build system to give > us accurate state on the buildfarm - we might have had a code breakage > but it won't always tell us that. At least it broke eventually :-) But I agree that's a big problem. > Part of the problem, it seems to me, is that this build system is a > hodge-podge of Perl programs and Windows shell scripts. In at least one > case we call perl to write a dynamically generated .bat file which we > then execute. Which one is that? I can't find it. A simple findstr through all the perl files appears to contain nothing of the sort. > Since the perl is pretty much indispensable (or at least > would need replacing by an engine of similar capability), I think we > should make the whole thing a perl suite with some very minimal .bat > wrappers if necessary. That's mostly how it is now, no? What are you referring to specifically? The only longer ones I can see are: builddoc.bat - could certainly be put into perl stuff, but it's not involved in the buildfarm process, so... clean.bat - doesn't really matter, IMO, and again not involved in the buildfarm process vcregress.bat - sure, it could be made perl, but right now you can actually run the regression tests on an installed system without having perl at all... But that's not really a requirement, so we could change that one. The rest are just thin wrappers. Speaking of wrappers, are you planning to make the buildfarm use the modules instead of the perlscripts? IIRC, I made those modules specifically for the bf - and it should make it even easier to pick up the errors from there. I'll leave the Vista parts to Dave since I haven't used it at all there. These are really completely separate issues, and should be treated as such. //Magnus
Magnus Hagander wrote:
> Andrew Dunstan wrote:
>
>> I am still very unhappy about the way the MSVC builds work. Although we
>> have managed to make it sort of work with the buildfarm script, it is
>> distinctly fragile. Last night, for example, I had a build failure due
>> to a badly installed zlib. The error state didn't come back to the
>> buildfarm script, which carried on merrily to the check stage, which
>> also naturally failed, but also didn't manage to give back an error
>>
>
> I've heard you report this before, and I've tried and failed many times
> to reproduce it. It has *always* come back with the proper errorlevel
> when I've tried. So two questions:
>
> 1) are you absolutely sure that the problem is not in the buildfarm script?
>
Pretty damn sure, yes. This code has functioned correctly on the
buildfarm on every other platform since its inception.
> 2) What exactly was the error? So I can try to reproduce that exact
> problem here and see if I can find out what it is. What did you do
> wrong, and what was the error messages if you still have the log.
>
I did indeed keep the logs.
Steps to reproduce: rename your zdll.lib and then run the buildfarm script.
Output:
E:\prog>perl run_build.pl --test
[17:51:47] checking out source ...
[17:52:17] checking if build run needed ...
[17:52:30] copying source to pgsql.3840 ...
3152 File(s) copied
[17:53:44] running configure ...
[17:53:44] running make ...
[18:27:50] running make check ...
[18:27:50] running make install ...
Branch: HEAD
Stage Install failed with status 2
from the bottom of the make log:
Build FAILED.
.\src\backend\utils\adt\oracle_compat.c(898): warning C4090: 'function'
: different 'const' qualifiers
.\src\backend\utils\adt\oracle_compat.c(900): warning C4090: 'function'
: different 'const' qualifiers
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib'
LINK : fatal error LNK1104: cannot open file
'e:\prog\pgdepend\zlib\lib\zdll.lib' 2 Warning(s) 12 Error(s)
Relevant perl code executed by buildfarm:
chdir "$pgsql/src/tools/msvc"; @makeout = `build 2>&1`; chdir $branch_root; my $status = $?
>>8;
Could it possibly be that the exit status has only low bits set, and
isn't what should be returned by wait()? I am checking on this now ....
(time passes) ... no, the raw status returned is in fact 0.
Now, I see that we do something different in the install case, which is
why the error gets trapped there. For install, we don't call the .bat
file at all, we call the install script directly:
chdir "$pgsql/src/tools/msvc"; @makeout = `perl install.pl "$installdir" 2>&1`; chdir $branch_root;
my $status = $? >>8;
So it looks like the .bat files are not collecting the exit status and
passing it on correctly.
>
>
>> state to the buildfarm script, and finally got a failure at the install
>> stage. That means that we simply can't rely on this build system to give
>> us accurate state on the buildfarm - we might have had a code breakage
>> but it won't always tell us that.
>>
>
> At least it broke eventually :-) But I agree that's a big problem.
>
yes.
>
>
>> Part of the problem, it seems to me, is that this build system is a
>> hodge-podge of Perl programs and Windows shell scripts. In at least one
>> case we call perl to write a dynamically generated .bat file which we
>> then execute.
>>
>
> Which one is that? I can't find it. A simple findstr through all the
> perl files appears to contain nothing of the sort.
>
perl ../../src/tools/msvc/getregress.pl > regress.tmp.bat
call regress.tmp.bat
del regress.tmp.bat
>
>> Since the perl is pretty much indispensable (or at least
>> would need replacing by an engine of similar capability), I think we
>> should make the whole thing a perl suite with some very minimal .bat
>> wrappers if necessary.
>>
>
> That's mostly how it is now, no? What are you referring to specifically?
>
> The only longer ones I can see are:
>
> builddoc.bat - could certainly be put into perl stuff, but it's not
> involved in the buildfarm process, so...
>
> clean.bat - doesn't really matter, IMO, and again not involved in the
> buildfarm process
>
> vcregress.bat - sure, it could be made perl, but right now you can
> actually run the regression tests on an installed system without having
> perl at all... But that's not really a requirement, so we could change
> that one.
>
perl2exe ?
> The rest are just thin wrappers.
>
Well, my .bat-fu was last in use around DOS6.2, so I'm not mucjh help
with them :-) I don't think they're really thin enough. Why not just
have them call "perl scriptname args"?
>
> Speaking of wrappers, are you planning to make the buildfarm use the
> modules instead of the perlscripts? IIRC, I made those modules
> specifically for the bf - and it should make it even easier to pick up
> the errors from there.
>
>
>
>
Yes, you did. But as I think I told you, I had a rethink about that. The
whole point about the buildfarm is to do things as closely to what a
human would do as possible, so I don't want to make it use the perl
modules like that unless we really really have to. I also want to have
as little special casing as possible in the buildfarm.
cheers
andrew
Dave Page wrote: > >> Perhaps someone would like to tell me how I can remedy these >> problems. More importantly, this should be in an FAQ or some such. >> Also, I would like to know if we have really tested out on Vista the >> privilege surrendering code that is is supposed to work in Windows. >> It looks to me like it might not be working. > > What makes you say that? It was just a suspicion, but maybe the fact that the admin user can't run while the non-admin user can indicates that it is working (possibly too well). > >> If we can make progress on these issues then I'll be happy. If not, I >> think we need to look carefully at what we say we can support, and >> what we declare to be still experimental. > > Lack of completely reliable buildfarm support for MSVC or trouble > setting up a buildenv doesn't mean we cannot support a platform - it > just means we need o be extra vigilent to ensure that regresssion > tests etc. do actually pass (though that level of failure would be > visible on the BF I would hope - it certainly has been until now). > > I am not only concerned about the buildfarm, but about the robustness, maintainability and simplicity of the build process. Having to have a completely separate build system for msvc is really quite sucky. cheers andrew
Andrew Dunstan wrote: > Relevant perl code executed by buildfarm: > > chdir "$pgsql/src/tools/msvc"; > @makeout = `build 2>&1`; > chdir $branch_root; > my $status = $? >>8; I know the docs say otherwise, but would it be possible that "chdir" somehow resets $? on windows, sometimes, under some circumstances? Perhaps just move up the "my $status.." one line up? Best Regards Michael Paesold
> user) . I can build as the admin user but when I come to run > initdb it fails, complaining that it can't find the postgres > executable. FYI, this happens on my Win 2000 also. Maybe a problem with mixed / \ path separators after RestrictExec. Andreas
Andrew Dunstan wrote: > > > Dave Page wrote: >> >>> Perhaps someone would like to tell me how I can remedy these >>> problems. More importantly, this should be in an FAQ or some such. >>> Also, I would like to know if we have really tested out on Vista the >>> privilege surrendering code that is is supposed to work in Windows. >>> It looks to me like it might not be working. >> >> What makes you say that? > > > It was just a suspicion, but maybe the fact that the admin user can't > run while the non-admin user can indicates that it is working (possibly > too well). Hmm, yes - I see what you mean. How are you defining 'admin user'? When I ran into this problem from what I recall I was originally trying to swim against the Vista security model by using the Administrator account which is disabled by default (for anyone stilldoubting that from the last discussion on the topic, please see http://blogs.msdn.com/windowsvistasecurity/archive/2006/08/27/windowsvistasecurity-.aspx). It went away when I started using my own user account which is not 'the' administrator, but is a member of the administrators group. > I am not only concerned about the buildfarm, but about the robustness, > maintainability and simplicity of the build process. Having to have a > completely separate build system for msvc is really quite sucky. Well, yes, but unfortunately there's not really any other way to get a halfway decent development environment on Windows. Mingw/Msys are horrendously maintained - mingw still doesn't work without hacking on Vista as you've found, and msys doesn't work at all on 64 bit versions for example (at least it didn't the last few times I tried - it's possible they've fixed it now). The debugger doesn't work for most people, and the development environment is just plain nasty to keep up to date. Now 99.99% of users don't build on Windows anyway, so I'm not so much concerned about their ability to maintain and use the build environment as ours - if that means we have to fix a few bugs in the MSVC scripts during the dev cycle, so be it. The setup I'm using now for 8.3 is already orders of magnitude easier to setup and maintain than the mingw/msys environment, plus we have a decent debugger (and other tools) now, and the ability to run on 64 bit platforms, not to mention a compiler with which we can (eventually) build for them as well. Regards, Dave
Dave Page wrote: > If I then >> switch to the non-admin user, it can run initdb just fine. However, >> that user can't build, because it gets a mysterious failure from >> mt.exe. MinGW is even worse - it says it can't run gcc because it >> can't run cc1.exe (IIRC), so it fails at the configure stage! All of >> this has cost me quite a few hours in the last week, with very little >> to show for it. > > And that one... See http://aarongiles.com/?p=199 for more details, but the quick fix I used was to add /mingw/libexec/gcc/mingw32/3.4.2 to the path in /etc/profile. Regards, Dave
On Sun, Jun 24, 2007 at 08:24:43PM -0400, Andrew Dunstan wrote: > > > Magnus Hagander wrote: > >Andrew Dunstan wrote: > > > >>I am still very unhappy about the way the MSVC builds work. Although we > >>have managed to make it sort of work with the buildfarm script, it is > >>distinctly fragile. Last night, for example, I had a build failure due > >>to a badly installed zlib. The error state didn't come back to the > >>buildfarm script, which carried on merrily to the check stage, which > >>also naturally failed, but also didn't manage to give back an error > >> > > > >I've heard you report this before, and I've tried and failed many times > >to reproduce it. It has *always* come back with the proper errorlevel > >when I've tried. So two questions: > > > >1) are you absolutely sure that the problem is not in the buildfarm script? > > > > Pretty damn sure, yes. This code has functioned correctly on the > buildfarm on every other platform since its inception. I think you are overestimating the cross-platformness of perl... :-) > >2) What exactly was the error? So I can try to reproduce that exact > >problem here and see if I can find out what it is. What did you do > >wrong, and what was the error messages if you still have the log. > > > > I did indeed keep the logs. > > Steps to reproduce: rename your zdll.lib and then run the buildfarm script. Ok. Running this *outside* the buildfarm properly sets errorlevel=1 when it exits. Running the same test from the buildfarm script on the same machine, and it picks up the error and reports it just fine. (http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylark&dt=2007-06-25%2008:28:31) Since nobody else (AFAIK) has seen this, I'd be inclined to blame something in your environment. Can you run the build in "broken mode" but *without* using the buildfarm scripts, and see what errorlevel you get? Meaning: build.bat ... wait ... echo %errorlevel% It should output 1 if that part works, 0 if it fails. That'll tell us if the problem is in the bf or if it's in the actual build system. > >>Part of the problem, it seems to me, is that this build system is a > >>hodge-podge of Perl programs and Windows shell scripts. In at least one > >>case we call perl to write a dynamically generated .bat file which we > >>then execute. > >> > > > >Which one is that? I can't find it. A simple findstr through all the > >perl files appears to contain nothing of the sort. > > > > perl ../../src/tools/msvc/getregress.pl > regress.tmp.bat > call regress.tmp.bat > del regress.tmp.bat Ah. I was looking at the build parts only, not the regress part. My bad. Anyway, yes, the vcregress.bat file was the only one on the list that made sense to consider redoing in perl. > >>Since the perl is pretty much indispensable (or at least > >>would need replacing by an engine of similar capability), I think we > >>should make the whole thing a perl suite with some very minimal .bat > >>wrappers if necessary. > >> > > > >That's mostly how it is now, no? What are you referring to specifically? > > > >The only longer ones I can see are: > > > >builddoc.bat - could certainly be put into perl stuff, but it's not > >involved in the buildfarm process, so... > > > >clean.bat - doesn't really matter, IMO, and again not involved in the > >buildfarm process > > > >vcregress.bat - sure, it could be made perl, but right now you can > >actually run the regression tests on an installed system without having > >perl at all... But that's not really a requirement, so we could change > >that one. > > > > perl2exe ? No way, that's just too ugly :-) Since you basically ship perl packaged inside the exe anyway, we might as well accept the requirement of perl to run the regression tests. Actually, ´given the above we *already* require perl for the regression tests, I had forgotten about that part. > > >The rest are just thin wrappers. > > > > Well, my .bat-fu was last in use around DOS6.2, so I'm not mucjh help > with them :-) I don't think they're really thin enough. Why not just > have them call "perl scriptname args"? I guess you could. The point of the split in build.bat today is basically that you run mkvcbuild separately if you want to work from the GUI. But that could of course be dealt with with commandline parameters if there's really a benefit in it. But I'm not sure there is - there's very little logic in the bat files, and that's what matters IMO. > >Speaking of wrappers, are you planning to make the buildfarm use the > >modules instead of the perlscripts? IIRC, I made those modules > >specifically for the bf - and it should make it even easier to pick up > >the errors from there. > > > > > > Yes, you did. But as I think I told you, I had a rethink about that. The > whole point about the buildfarm is to do things as closely to what a > human would do as possible, so I don't want to make it use the perl > modules like that unless we really really have to. I also want to have > as little special casing as possible in the buildfarm. Ah, you did tell me that. Sorry, forgot about that. Fair 'nuff. //Magnus
Magnus Hagander wrote: > Running the same test from the buildfarm script on the same machine, and it > picks up the error and reports it just fine. > (http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylark&dt=2007-06-25%2008:28:31) I ran on Baiji (renaming the zlib directory, instead of the .lib as Magnus did) and see a error as well: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=baiji&dt=2007-06-25%2008:36:47 Just for kicks, that was also on Vista. I'm going to run on my Win2K3 animal in a minute - that one runs VC++ Express, unlike Baiji and Skylark which I believe are both 'proper' Visual Studio. Will report back when it's done. Regards, Dave
Dave Page wrote: > I'm going to run on my Win2K3 > animal in a minute - that one runs VC++ Express, unlike Baiji and > Skylark which I believe are both 'proper' Visual Studio. Will report > back when it's done. Yep, it failed at make as well, and reported it appropriately to the BF. Regards, Dave
Dave Page wrote: > Dave Page wrote: >> I'm going to run on my Win2K3 animal in a minute - that one runs VC++ >> Express, unlike Baiji and Skylark which I believe are both 'proper' >> Visual Studio. Will report back when it's done. > > Yep, it failed at make as well, and reported it appropriately to the BF. > > Well, that's *very* curious. I have seen this on more than one machine. I'll run the test Magnus suggests and see what we can discover. cheers andrew
Magnus Hagander wrote: > > Can you run the build in "broken mode" but *without* using the buildfarm > scripts, and see what errorlevel you get? Meaning: > build.bat > ... wait ... > echo %errorlevel% > > It should output 1 if that part works, 0 if it fails. That'll tell us if > the problem is in the bf or if it's in the actual build system. > > > It fails and says 1. Now, if I change the build script so it says exit %E instead of exit /b %E I pick up the exit status just fine. I wonder if wer have different flavors of command interpreter? (My perl is the latest one from ActiveState, btw. I assume you're using that.) Can we change that or make it switchable? I'd be happy to provide an environment variable like RUNNING_BUILDFARM if that would help. cheers andrew
On Mon, Jun 25, 2007 at 10:06:57AM -0400, Andrew Dunstan wrote: > > > Magnus Hagander wrote: > > > >Can you run the build in "broken mode" but *without* using the buildfarm > >scripts, and see what errorlevel you get? Meaning: > >build.bat > >... wait ... > >echo %errorlevel% > > > >It should output 1 if that part works, 0 if it fails. That'll tell us if > >the problem is in the bf or if it's in the actual build system. > > > > > > > > It fails and says 1. > > Now, if I change the build script so it says > > exit %E > > instead of > > exit /b %E That's just weird :-( And making that change makes the script unusable from the commandline. > I pick up the exit status just fine. I wonder if wer have different > flavors of command interpreter? (My perl is the latest one from > ActiveState, btw. I assume you're using that.) cmd.exe from Windows - I assume you haven't installed some funky addon special command interpreter? In that case, it should be the same. So I have: Microsoft Windows [Version 5.2.3790] (C) Copyright 1985-2003 Microsoft Corp. As for perl, I'm probably not on the very latest, but it's not so old. I'm on: This is perl, v5.8.8 built for MSWin32-x64-multi-thread (with 33 registered patches, see perl -V for more detail) Dave - what version are you on? > Can we change that or make it switchable? I'd be happy to provide an > environment variable like RUNNING_BUILDFARM if that would help. We could, but it seems very ugly. And again, it's *not* required for buildfarm on my or Daves machines. So I'd rather like to know why it's actually happening than just blindly change it. //Magnus
Magnus Hagander wrote: > As for perl, I'm probably not on the very latest, but it's not so old. I'm > on: > This is perl, v5.8.8 built for MSWin32-x64-multi-thread > (with 33 registered patches, see perl -V for more detail) > > > Dave - what version are you on? This is perl, v5.8.8 built for MSWin32-x86-multi-thread (with 50 registered patches, see perl -V for more detail) /D
Magnus Hagander wrote: > cmd.exe from Windows - I assume you haven't installed some funky addon > special command interpreter? In that case, it should be the same. So I > have: > Microsoft Windows [Version 5.2.3790] > (C) Copyright 1985-2003 Microsoft Corp. > > > > Hmm. Mine says 5.1.2600, which seems to be quite old. I'll see about updating ... the strange thing is I'm pretty sure I've seen this on other more up to date machines. cheers andrew
On Mon, Jun 25, 2007 at 10:45:00AM -0400, Andrew Dunstan wrote: > > > Magnus Hagander wrote: > >cmd.exe from Windows - I assume you haven't installed some funky addon > >special command interpreter? In that case, it should be the same. So I > >have: > >Microsoft Windows [Version 5.2.3790] > >(C) Copyright 1985-2003 Microsoft Corp. > > > > > > > > > > Hmm. Mine says 5.1.2600, which seems to be quite old. I'll see about > updating ... the strange thing is I'm pretty sure I've seen this on > other more up to date machines. That's because you are on XP. 5.1 is XP, 5.2 is 2003. To make things more interesting, XP x64 is 5.2... So it might be worthwhile to see if this is something that happens on <= XP, and works on >= 2003. Dave, did you test on any server OS other than 2003, or any client that's XP or earlier? //Magnus
Andrew Dunstan wrote: > Hmm. Mine says 5.1.2600, which seems to be quite old. I'll see about > updating ... the strange thing is I'm pretty sure I've seen this on > other more up to date machines. You can't update that unless you upgrade to Windows 2003 or Vista. That's the XP command shell. Regards, Dave
Dave Page wrote: > Dave Page wrote: >> If I then >>> switch to the non-admin user, it can run initdb just fine. However, >>> that user can't build, because it gets a mysterious failure from >>> mt.exe. MinGW is even worse - it says it can't run gcc because it >>> can't run cc1.exe (IIRC), so it fails at the configure stage! All of >>> this has cost me quite a few hours in the last week, with very >>> little to show for it. >> >> And that one... > > See http://aarongiles.com/?p=199 for more details, but the quick fix I > used was to add /mingw/libexec/gcc/mingw32/3.4.2 to the path in > /etc/profile. > > That seems to have fixed it. But now of cousre I forgot that the latest version is broken w.r.t. gettimeofday ... *sigh* cheers andrew
Magnus Hagander wrote: >> Can we change that or make it switchable? I'd be happy to provide an >> environment variable like RUNNING_BUILDFARM if that would help. >> > > We could, but it seems very ugly. And again, it's *not* required for > buildfarm on my or Daves machines. So I'd rather like to know why it's > actually happening than just blindly change it. > > > Not surprisingly, I am not the only person who has had this problem. See http://jira.codehaus.org/browse/CONTINUUM-413 where the suggested solution is: if "%MAVEN_TERMINATE_CMD%" == "on" exit %ERRORLEVEL% exit /b %ERRORLEVEL% There are 12 lines involved in our .bat files: build.bat:35:exit /b %E% builddoc.bat:40:exit /b builddoc.bat:50:exit /b install.bat:9:exit /b 1 install.bat:18:exit /b %ERRORLEVEL% vcregress.bat:35: if errorlevel 1 exit /b 1 vcregress.bat:51:exit /b %E% vcregress.bat:64: if errorlevel 1 exit /b 1 vcregress.bat:66: if errorlevel 1 exit /b 1 vcregress.bat:86:exit /b %E% vcregress.bat:97:if %CONTRIBERROR%==1 exit /b 1 vcregress.bat:113:exit /b %E% Would making a change like this in those 12 places be so ugly? cheers andrew
Magnus Hagander wrote: > So it might be worthwhile to see if this is something that happens on <= > XP, and works on >= 2003. Dave, did you test on any server OS other than > 2003, or any client that's XP or earlier? No, my testing was only on 2k3 and vista. /D
On Sun, 2007-06-24 at 13:23 -0400, Andrew Dunstan wrote: (cut) > On a somewhat related note, I have had spectacular lack of success in > getting either MSVC or MinGW builds to work on Vista - so much so that I > have currently abandoned my attempts on that platform and I resorted to > resuscitating an old XP box for testing. Following some advice from > Magnus, I added ACLs to the build root for both an admin and a non-admin > user (cacls buildroot /E /T /G AdminUser:C and similarly for a non-admin > user) . I can build as the admin user but when I come to run initdb it > fails, complaining that it can't find the postgres executable. If I then > switch to the non-admin user, it can run initdb just fine. However, that > user can't build, because it gets a mysterious failure from mt.exe. > MinGW is even worse - it says it can't run gcc because it can't run > cc1.exe (IIRC), so it fails at the configure stage! All of this has cost > me quite a few hours in the last week, with very little to show for it. Hi Andrew, This has come up quite recently on the MingW lists - see http://sourceforge.net/mailarchive/forum.php?thread_name=00fc01c7a0af% 240a037c30%240200a8c0%40AMD2500&forum_name=mingw-users for a discussion of the problem and solution. Kind regards, Mark. -- ILande - Open Source Consultancy http://www.ilande.co.uk
Mark Cave-Ayland wrote: > This has come up quite recently on the MingW lists - see > http://sourceforge.net/mailarchive/forum.php?thread_name=00fc01c7a0af% > 240a037c30%240200a8c0%40AMD2500&forum_name=mingw-users for a discussion > of the problem and solution. > > > > Thanks. I've actually got past this issue, and moved on to the problem of having to downgrade far enough to get past the gettimeofday redefinition problem :-) cheers andrew
Dave Page wrote: > Andrew Dunstan wrote: > >> On a somewhat related note, I have had spectacular lack of success in >> getting either MSVC or MinGW builds to work on Vista - so much so >> that I have currently abandoned my attempts on that platform and I >> resorted to resuscitating an old XP box for testing. Following some >> advice from Magnus, I added ACLs to the build root for both an admin >> and a non-admin user (cacls buildroot /E /T /G AdminUser:C and >> similarly for a non-admin user) . I can build as the admin user but >> when I come to run initdb it fails, complaining that it can't find >> the postgres executable. > > Yeah, I ran into that problem as well. I'll look at my Vista box when > I'm in the office tomorrow and see if I can figure out what hack fixed > it for me. > > I have never heard back on this, AFAIK. If anyone has instructions on how to manage this please let me know. My current status with MSVC/vista is still that I can build but not run as an admin user, and run but not build as a non-admin user. Bleah. cheers andrew
Andrew Dunstan wrote: > Dave Page wrote: >> Andrew Dunstan wrote: >>> On a somewhat related note, I have had spectacular lack of success >>> in getting either MSVC or MinGW builds to work on Vista - so much so >>> that I have currently abandoned my attempts on that platform and I >>> resorted to resuscitating an old XP box for testing. Following some >>> advice from Magnus, I added ACLs to the build root for both an admin >>> and a non-admin user (cacls buildroot /E /T /G AdminUser:C and >>> similarly for a non-admin user) . I can build as the admin user but >>> when I come to run initdb it fails, complaining that it can't find >>> the postgres executable. >> Yeah, I ran into that problem as well. I'll look at my Vista box when >> I'm in the office tomorrow and see if I can figure out what hack >> fixed it for me. > > I have never heard back on this, AFAIK. If anyone has instructions on > how to manage this please let me know. My current status with > MSVC/vista is still that I can build but not run as an admin user, and > run but not build as a non-admin user. Bleah. > > cheers > > andrew Described situation looks like you are trying to run initdb under Admin account. This will happen even if currently logged user in not admin, but initdb has property 'run as administrator' set or you are trying to run it under some file commander which is running in admin mode. Andrei.
Andrei Kovalevski wrote: > Andrew Dunstan wrote: >> Dave Page wrote: >>> Andrew Dunstan wrote: >>>> On a somewhat related note, I have had spectacular lack of success >>>> in getting either MSVC or MinGW builds to work on Vista - so much >>>> so that I have currently abandoned my attempts on that platform and >>>> I resorted to resuscitating an old XP box for testing. Following >>>> some advice from Magnus, I added ACLs to the build root for both an >>>> admin and a non-admin user (cacls buildroot /E /T /G AdminUser:C >>>> and similarly for a non-admin user) . I can build as the admin user >>>> but when I come to run initdb it fails, complaining that it can't >>>> find the postgres executable. >>> Yeah, I ran into that problem as well. I'll look at my Vista box >>> when I'm in the office tomorrow and see if I can figure out what >>> hack fixed it for me. >> >> I have never heard back on this, AFAIK. If anyone has instructions on >> how to manage this please let me know. My current status with >> MSVC/vista is still that I can build but not run as an admin user, >> and run but not build as a non-admin user. Bleah. >> >> cheers >> >> andrew > Described situation looks like you are trying to run initdb under > Admin account. This will happen even if currently logged user in not > admin, but initdb has property 'run as administrator' set or you are > trying to run it under some file commander which is running in admin > mode. > > No it doesn't. Please read again. As a non-admin user I *can* run. I just can't build. As an admin user I can build, but I can't run (and I should be able to run). cheers andrew
Andrew Dunstan wrote: > I have never heard back on this, AFAIK. If anyone has instructions on > how to manage this please let me know. My current status with MSVC/vista > is still that I can build but not run as an admin user, and run but not > build as a non-admin user. Bleah. I remember responding, but we had 2 somewhat intertwined threads going back then as I recall so it might have been in the other one... On my machine here, I run the buildfarm under user 'Dave' which is a member of the Administrators group. It would not run under the (unlocked) Administrator account as I recall, as it gave the error you report about not being able to find postgres.exe. iirc, this is because of the way the administrator account is largely crippled by UAC these days (you're not really supposed to use it anyway). I run the clients for both MSVC and Mingw this way. On Mingw, the only other problem I recall was that cc1.exe couldn't be found, for which I posted a solution here http://archives.postgresql.org/pgsql-hackers/2007-06/msg00932.php On MSVC, I don't recall seeing the problem you get with mt.exe. Can you provide any more useful detail than 'mysterious failure'? That was all you said in your original message. Regards, Dave.