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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers