Why polecat and colugos are failing to build back branches - Mailing list pgsql-hackers

From Tom Lane
Subject Why polecat and colugos are failing to build back branches
Date
Msg-id 11741.1308009955@sss.pgh.pa.us
Whole thread Raw
Responses Re: Why polecat and colugos are failing to build back branches
Re: Why polecat and colugos are failing to build back branches
List pgsql-hackers
I looked into $SUBJECT.  There appear to be two distinct issues:

1. On colugos (OS X with LLVM), the plperl link step is spitting up
because Apple's ExtUtils::Embed puts some -arch switches into
perl_embed_ldflags.  We found out about that some time ago, and fixed
it for 9.0 and up here:
http://git.postgresql.org/gitweb?p=postgresql.git&a=commitdiff&h=d69a419e682c2d39c2355105a7e5e2b90357c8f0
However, because when using gcc that only results in a warning,
we didn't back-patch it.  Now it appears that it's an error when using
LLVM, so maybe we oughta back-patch it, at least to whichever releases
we think will build with LLVM.

2. Pre-9.0, the installation step is failing like this:

make -C src install
/bin/sh ../config/mkinstalldirs '/Volumes/High
Usage/usr/local/src/build-farm-4.4/builds/REL8_2_STABLE/pgsql.14435/src/test/regress/./tmp_check/install/usr/local/src/build-farm-4.4/builds/REL8_2_STABLE/inst/lib/postgresql/pgxs/src'
mkdir /Volumes/High/Usage
mkdir: /Volumes/High/Usage: Permission denied
mkdir /Volumes/High/Usage/usr
mkdir: /Volumes/High/Usage: No such file or directory
mkdir /Volumes/High/Usage/usr/local
mkdir: /Volumes/High/Usage/usr: No such file or directory
[etc]

What is happening here of course is that mkinstalldirs is not prepared
to deal with spaces in the given pathname.  In 9.0 we replaced it with a
more modern script that apparently hasn't got that problem.  (Or at
least, there's no such failure ... I don't see any reference to
'/Volumes/High Usage/' in the later-version buildfarm logs, so maybe
there is some other factor at work?)

It looks to me like it wouldn't be terribly difficult to make
mkinstalldirs handle this case correctly.  We aren't normally in the
habit of patching bugs that only appear in old release branches,
but should we make an exception for this?  The alternatives seem to be
to ask Robert to rename the volume, or stop testing pre-9.0 branches on
that machine.  Neither seems like a great idea from a test coverage
standpoint.  We *should* have at least one test machine that's testing
building and installation into space-containing paths, or the case is
certain to break.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_trgm: unicode string not working
Next
From: Jeff Janes
Date:
Subject: Re: lazy vxid locks, v1