Failure with regression test largeobject if pg_regress invoked from external paths

Hi all,

Today a colleague (Kingter Wang) has reminded me about a failure with
the test case largeobject that can happen if pg_regress is run from an
external path that has not results/ available at hand:
*** /home/packages/stuff/expected/largeobject.out Tue Jan 5 07:56:58 2016
--- /home/packages/stuff/results/largeobject.out Tue Jan 5 07:57:21 2016
***************
*** 388,405 ****
(1 row)

\lo_import 'results/lotest.txt'
\set newloid :LASTOID
-- just make sure \lo_export does not barf
\lo_export :newloid 'results/lotest2.txt'
-- This is a hack to test that export/import are reversible
-- This uses knowledge about the inner workings of large object mechanism
-- which should not be used outside it. This makes it a HACK
SELECT pageno, data FROM pg_largeobject WHERE loid = (SELECT loid
from lotest_stash_values)
EXCEPT
SELECT pageno, data FROM pg_largeobject WHERE loid = :newloid;
! pageno | data
! --------+------
! (0 rows)

SELECT lo_unlink(loid) FROM lotest_stash_values;
lo_unlink
--- 388,735 ----
(1 row)

\lo_import 'results/lotest.txt'
+ could not open file "results/lotest.txt": No such file or directory
\set newloid :LASTOID
-- just make sure \lo_export does not barf
\lo_export :newloid 'results/lotest2.txt'
+ ERROR: large object 0 does not exist

While looking at largeobject.source, it is indeed surprising to see
that we use a relative path for this test and not an absolute path.
For the sake of this test's portability, shouldn't we append
@abs_builddir@ then? Attached is a patch to address this issue.

I would imagine that I am not the only one seeing those tests run in
such ways...
Regards,
--
Michael