Thread: Unable to `make install` on MacOS in the latest master (68a13f28be)
I am unable to `make install` on MacOS in the latest master (68a13f28be).
Here are the steps to reproduce.
OS: MacOSX 10.14.2
Branch: master:HEAD (68a13f28be)
$ git log --pretty=format:'%h' -n 1
68a13f28be
$ ./configure --with-bonjour
$ make
$ sudo make install
...
/usr/bin/install -c -m 644 utils/errcodes.h '/usr/local/pgsql/include/server/utils'
/usr/bin/install -c -m 644 utils/fmgroids.h '/usr/local/pgsql/include/server/utils'
/usr/bin/install -c -m 644 utils/fmgrprotos.h '/usr/local/pgsql/include/server/utils'
cp ./*.h '/usr/local/pgsql/include/server'/
cp: ./dynloader.h: No such file or directory
make[2]: *** [install] Error 1
make[1]: *** [install-include-recurse] Error 2
make: *** [install-src-recurse] Error 2
FWIW, I've also tried `./configure` without any flags, but that didn't effect the results.
I am able to successfully build/install from branch `REL_11_STABLE` (ad425aaf06)
On 1/3/19 10:47 AM, Andrew Alsup wrote: > cp ./*.h '/usr/local/pgsql/include/server'/ > cp: ./dynloader.h: No such file or directory Has dynloader.h somehow ended up as a symbolic link to a file no longer present? Perhaps influenced by commit 842cb9f ? -Chap
> On 3 Jan 2019, at 16:54, Chapman Flack <chap@anastigmatix.net> wrote: > > On 1/3/19 10:47 AM, Andrew Alsup wrote: >> cp ./*.h '/usr/local/pgsql/include/server'/ >> cp: ./dynloader.h: No such file or directory > > Has dynloader.h somehow ended up as a symbolic link to a file > no longer present? > > Perhaps influenced by commit 842cb9f ? It is indeed related to that commit. You will need to do make distclean, or remove dynloader.h manually. cheers ./daniel
Daniel Gustafsson <daniel@yesql.se> writes:
>> On 3 Jan 2019, at 16:54, Chapman Flack <chap@anastigmatix.net> wrote:
>> Perhaps influenced by commit 842cb9f ?
> It is indeed related to that commit. You will need to do make distclean, or
> remove dynloader.h manually.
As a general rule, it's wise to do "make distclean" before "git pull"
when you're tracking master. This saves a lot of grief when someone
rearranges the set of generated files, as happened here. (If things
are really messed up, you might need "git clean -dfx" to get rid of
everything not in git.)
You might worry that this will greatly increase the rebuild time,
which it will if you don't take precautions. The way to fix that
is (1) use ccache and (2) set the configure script to use a cache
file.
regards, tom lane
> As a general rule, it's wise to do "make distclean" before "git pull" > when you're tracking master. This saves a lot of grief when someone > rearranges the set of generated files, as happened here. (If things > are really messed up, you might need "git clean -dfx" to get rid of > everything not in git.) > > You might worry that this will greatly increase the rebuild time, > which it will if you don't take precautions. The way to fix that > is (1) use ccache and (2) set the configure script to use a cache > file. > > regards, tom lane Tom and Daniel, Thanks for the help on "make distclean". That did the trick. I will be more careful when pulling master. Somehow, I hadn't been hit with this before, which was just dumb luck. Thanks for helping me out. -- Andy
On Thu, Jan 03, 2019 at 11:27:34AM -0500, Andrew Alsup wrote: > Thanks for the help on "make distclean". That did the trick. I will be > more careful when pulling master. Somehow, I hadn't been hit with this > before, which was just dumb luck. Thanks for helping me out. A more violent method is that from the top of the tree: git clean -d -x -f That's really efficient when using the git reporitory directly. -- Michael