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

Yes, zic has always attempted to create hard links and it never failed on
our build farm and we haven't changed anything.

The patch given doesn't help. I guess the problem is that in dolink(), the
fromfield value is a directory (path to postgresql/timezone) and hence the
make install fails at following check:
--
fromisdir = itsdir(fromfield);
if (fromisdir)
{
char const *e = strerror(fromisdir < 0 ? errno : EPERM);

fprintf(stderr, _("%s: link from %s/%s failed: %s\n"),
progname, directory, fromfield, e);

exit(EXIT_FAILURE);
}
--

"fromfield" value should have been the file inside the timezone directory.

On Wed, Oct 26, 2016 at 10:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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
>

--
Sandeep Thakkar