From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Cc: | robert(at)logicalchaos(dot)org |
Subject: | Why polecat and colugos are failing to build back branches |
Date: | 2011-06-14 00:05:55 |
Message-ID: | 11741.1308009955@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2011-06-14 00:10:58 | Re: lazy vxid locks, v1 |
Previous Message | Bruce Momjian | 2011-06-13 23:47:31 | Re: pg_trgm: unicode string not working |