Re: Compilation of timezone source with zic fails (on mountpoint)

Sandeep Thakkar <sandeep(dot)thakkar(at)enterprisedb(dot)com> writes:
> During building of the ongoing PG updates (9.6.1, 9.5.5 to 9.1.24), we
> found that the build failed for Linux on 9.3 and 9.2 with the following
> error:
> ...
> warning: "./data/backward", line 125: symbolic link used because hard link
> failed: Operation not permitted
> .*/zic: link from
> /mnt/hgfs/pginstaller-repo/**server/staging/linux/share/postgresql/timezone/US/Eastern
> failed: Operation not permitted*
> make[2]: *** [install] Error 1

> On investigating, we found that it was because of the few commits in the
> new updates related to zic.c which tries to create hard links. These hard
> links failed to create on our build farm because we were building the
> source on the mount point (/mnt/hgfs/) where hard links cannot be created.
> The Linux machine is a Virtual Machine hosted on VMware Fusion on the Mac
> Server and the Fusion doesn't allow to create hard links inside the shared
> location. It errors out with "Operation not permitted". Symbolic links can
> be created though.

I took a closer look at this. As I said earlier, zic has always attempted
to use hard links, and now that I look, the fallback to symlinks has been
there right along as well. So you were always getting those warnings on
that platform. What is new, apparently, is this bit at the end of zic.c's
main() which came in with tzcode2016c (ie, our *previous* set of releases):

if (warnings && (ferror(stderr) || fclose(stderr) != 0))
return EXIT_FAILURE;

I cannot reproduce any failure locally by forcing "warnings" on, but I
speculate that for some reason fclose(stderr) fails on your platform.

We could probably persuade the IANA guys that fclose() is a bad idea here
and fflush() would be saner. Could you determine whether "make install"
passes in that environment if you replace this code with

if (warnings && (fflush(stderr) != 0 || ferror(stderr)))
return EXIT_FAILURE;

?

Independently of that, though, I think it's a bad idea to be using such
an environment as your build platform, because it means you are getting
different results (different package contents) depending on whether you
happen to build with the install target directory on that mount or not.

regards, tom lane