Re: Compilation of timezone source with zic fails (on mountpoint) - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Compilation of timezone source with zic fails (on mountpoint)
Date
Msg-id 4270.1477500077@sss.pgh.pa.us
Whole thread Raw
In response to Compilation of timezone source with zic fails (on mountpoint)  (Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>)
Responses Re: Compilation of timezone source with zic fails (on mountpoint)
List pgsql-bugs
Sandeep Thakkar <sandeep.thakkar@enterprisedb.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 li=
nk
> failed: Operation not permitted
> .*/zic: link from
> /mnt/hgfs/pginstaller-repo/**server/staging/linux/share/postgresql/timez=
one/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 har=
d
> 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 create=
d.
> The Linux machine is a Virtual Machine hosted on VMware Fusion on the Ma=
c
> Server and the Fusion doesn't allow to create hard links inside the shar=
ed
> location. It errors out with "Operation not permitted". Symbolic links c=
an
> 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) !=3D 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) !=3D 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

pgsql-bugs by date:

Previous
From: Stephen Frost
Date:
Subject: Re: BUG #14396: grant drop table
Next
From: Peter Geoghegan
Date:
Subject: Re: BUG #14344: string_agg(DISTINCT ..) crash