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