Thread: Re: make fails if path has spaces
Andreas Pflug wrote: > If configure detects some tools in the existing path, the build process > may fail. > In my case, there's perl under c:\program files. make will fail while in > bin/psql because "/c/program" is not found. I am not surprised. We do not do proper quoting of environment variables in configure.in. I also don't know if the autoconf program that creates the configure output does proper quoting either. Can you tell us where it is failing by looking in config.log? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
If configure detects some tools in the existing path, the build process may fail. In my case, there's perl under c:\program files. make will fail while in bin/psql because "/c/program" is not found. Regards, Andreas
Bruce Momjian wrote: > Andreas Pflug wrote: > >>If configure detects some tools in the existing path, the build process >>may fail. >>In my case, there's perl under c:\program files. make will fail while in >>bin/psql because "/c/program" is not found. > > > I am not surprised. We do not do proper quoting of environment > variables in configure.in. I also don't know if the autoconf program > that creates the configure output does proper quoting either. Can you > tell us where it is failing by looking in config.log? I'm no sure what you mean. AFAICS configure does detect the program location all right, but it should either omit the full path, so the program is located using $PATH, or executables found should be quoted. Regards, Andreas
Andreas Pflug wrote: > Bruce Momjian wrote: > > Andreas Pflug wrote: > > > >>If configure detects some tools in the existing path, the build process > >>may fail. > >>In my case, there's perl under c:\program files. make will fail while in > >>bin/psql because "/c/program" is not found. > > > > > > I am not surprised. We do not do proper quoting of environment > > variables in configure.in. I also don't know if the autoconf program > > that creates the configure output does proper quoting either. Can you > > tell us where it is failing by looking in config.log? > > I'm no sure what you mean. AFAICS configure does detect the program > location all right, but it should either omit the full path, so the > program is located using $PATH, or executables found should be quoted. Yes, the executable has to be quoted. Where is it being referenced unquoted? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: > > Yes, the executable has to be quoted. Where is it being referenced > unquoted? In this case, $(PERL) is referenced for building psql's doc. PERL is set in Makefile.global unquoted, as all paths. For others, the same problem might arise with bison or flex. Regards, Andrea
Has anyone tried Point in Time recovery on Win32? tried to set it up
today and keep getting this error
*Test=# Select pg_start_backup('test backup');
ERROR: function pg_start_backup("unknown") does not exist
HINT: No function matches the given name and argument types. You may
need to add explicit type casts
*
--
*Jamie Deppeler
*
Jamie Deppeler <jamie@doitonce.net.au> writes:
> Has anyone tried Point in Time recovery on Win32? tried to set it up
> today and keep getting this error
> *Test=# Select pg_start_backup('test backup');
> ERROR: function pg_start_backup("unknown") does not exist
I just committed that function late this afternoon ... how old is
the snapshot you're using?
regards, tom lane
Andreas Pflug wrote: > Bruce Momjian wrote: > >> >> Yes, the executable has to be quoted. Where is it being referenced >> unquoted? > > > In this case, $(PERL) is referenced for building psql's doc. PERL is > set in Makefile.global unquoted, as all paths. > > For others, the same problem might arise with bison or flex. > > Generally I think we expect all the build tools to be installed under MSys - maybe you need to install MSysDTK? An alternative would be to quote $(PERL) in psql's Makefile, but that might not solve the general problem, as you observe. cheers andrew
Andreas Pflug wrote: > Bruce Momjian wrote: > > > > > Yes, the executable has to be quoted. Where is it being referenced > > unquoted? > > In this case, $(PERL) is referenced for building psql's doc. PERL is set > in Makefile.global unquoted, as all paths. > > For others, the same problem might arise with bison or flex. Is the problem the assignment in Makefile.global or the use of the variable in psql/Makefile? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: > Andreas Pflug wrote: > >>Bruce Momjian wrote: >> >> >>>Yes, the executable has to be quoted. Where is it being referenced >>>unquoted? >> >>In this case, $(PERL) is referenced for building psql's doc. PERL is set >>in Makefile.global unquoted, as all paths. >> >>For others, the same problem might arise with bison or flex. > > > Is the problem the assignment in Makefile.global or the use of the > variable in psql/Makefile? > It could be fixed in both places, but the more general fix would be to qoute in Makefile.global, i.e. fixing configure. Regards, Andreas
Andreas Pflug wrote:
> Bruce Momjian wrote:
> > Andreas Pflug wrote:
> >
> >>Bruce Momjian wrote:
> >>
> >>
> >>>Yes, the executable has to be quoted. Where is it being referenced
> >>>unquoted?
> >>
> >>In this case, $(PERL) is referenced for building psql's doc. PERL is set
> >>in Makefile.global unquoted, as all paths.
> >>
> >>For others, the same problem might arise with bison or flex.
> >
> >
> > Is the problem the assignment in Makefile.global or the use of the
> > variable in psql/Makefile?
> >
>
> It could be fixed in both places, but the more general fix would be to
> qoute in Makefile.global, i.e. fixing configure.
What if you change this:
PERL = @PERL@
to this:
PERL = "@PERL@"
Does it help?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: >>> >> >>It could be fixed in both places, but the more general fix would be to >>qoute in Makefile.global, i.e. fixing configure. > > > What if you change this: > > PERL = @PERL@ > > to this: > > PERL = "@PERL@" > > Does it help? > Changed in src/Makefile.global.in, and it works. There are other candidates that could have a non-msys path, which maybe should be quoted as well. Regards, Andreas