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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Compilation of timezone source with zic fails (on mountpoint)
Дата
Msg-id 4270.1477500077@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Compilation of timezone source with zic fails (on mountpoint)  (Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>)
Ответы Re: Compilation of timezone source with zic fails (on mountpoint)  (Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: BUG #14396: grant drop table
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: BUG #14344: string_agg(DISTINCT ..) crash