Hi all, @Ron Johnson, I am building from the source because I wanted to contribute to the open-source community, and for that, I want the source files. I had a few things in mind currently for the same :). @Tom Lane <t...@sss.pgh.pa.us>, Thanks I am using a directory path with spaces in it, and removing them solved my issue. Next time I will use '_' in paths to be on the safer side.
Thanks and regards Ayush Vatsa SDE Amazon On Tue, 12 Dec 2023 at 22:10, Tom Lane <t...@sss.pgh.pa.us> wrote: > Ayush Vatsa <ayushvatsa1...@gmail.com> writes: > > Sorry, I should have included the required information initially itself. > I > > am new to the database field so please pardon my mistakes :) > > You still didn't mention the platform/environment, but I guess from > the reference to -isysroot that it must be macOS (Darwin). I further > guess that you're using Homebrew or MacPorts, because bare macOS > doesn't supply GNU sed. That doesn't get us much further though; > plenty of Postgres developers use one or the other of those setups > without difficulty. > > One idea that comes to mind is that you might be trying to build in > a directory path that contains spaces or other odd characters. > That's generally not well supported by Unix-based tooling. > However, I'm not sure how that'd lead to this particular failure. > > The only other idea I have is that maybe you have some weird > Homebrew or MacPorts package installed that changes the behavior > of your shell. I have no idea what that would be though. > > FWIW, on my own Mac laptop, line 486 in config.status in a > current build looks like > > *\'*) ac_optarg=`$as_echo "$ac_optarg" | sed "s/'/'\\\\\\\\''/g"` ;; > > which seems identical to what you reported. So that takes some > steam out of the idea that the file was generated incorrectly > in your build, pointing more to the idea that your shell is not > reading it as-expected. > > regards, tom lane >
