On 06/13/2011 08:05 PM, Tom Lane wrote:
> 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.
>
>
I think we can be a bit more liberal about build patches than things
that can affect the runtime behaviour.
So +1 for fixing both of these.
cheers
andrew
