Hi
I've passed your report, and proposed fix, on to the -hackers list for
consideration. Thanks for taking the time to investigate this and report
it in detail.
--
Craig Ringer
--- Begin Message ---
Dear maintainers of PostgreSQL,
Build errors for PostgreSQL have been reported on Gentoo Linux, see
https://bugs.gentoo.org/285953 for the full bug report there.
The issue has originally been reported for PostgreSQL 8.4.1, but has
been reproduced with 8.4.2, 8.4.3 and even some 9.0 alpha.
In short, the build fails when the heimdal kerberos implementation is
installed on the system, and heimdal wasn't built with -Wl,--as-needed.
In that case, the postgresql configure script detects that the strlcat
and strlcpy functions as available. It does so because libgssapi.so and
libkrb5.so both depend on heimdal's libroken.so, which currently does
export these symbols. A fix for heimdal is in progress, which will
reduce the list of exported symbols using a linker script, but afaik it
hasn't been released yet, so for now heimdal installations providing
these symbols are a fact of life.
Later on, when postgresql has been configured and gets compiled, the
-Wl,--as-needed flag is passed to the linker, and as libroken itself
isn't named as a library to link against, the linker will complain about
undefined references.
Parts of the configure output:
> checking whether strlcat is declared... no
> checking whether strlcpy is declared... no
> checking for strlcat... yes
> checking for strlcpy... yes
Parts of the make output:
> descriptor.o: In function `descriptor_variable':
> .../postgresql-8.4.1/src/interfaces/ecpg/preproc/descriptor.c:326: undefined
> reference to `strlcpy'
> ../../../../src/port/libpgport.a(path.o): In function `get_home_path':
> .../postgresql-8.4.1/src/port/path.c:644: undefined reference to `strlcpy'
> ../../../../src/port/libpgport.a(path.o): In function `join_path_components':
> .../postgresql-8.4.1/src/port/path.c:177: undefined reference to `strlcpy'
> ../../../../src/port/libpgport.a(path.o): In function `make_relative_path':
> .../postgresql-8.4.1/src/port/path.c:503: undefined reference to `strlcpy'
> .../postgresql-8.4.1/src/port/path.c:523: undefined reference to `strlcpy'
> collect2: ld returned 1 exit status
> make[4]: *** [ecpg] Error 1
Several solutions are conceivable. The Gentoo user Honza Macháček
proposed handling libroken the same way you already handle libedit, i.e.
disable some libraries during detection of these functions. See
https://bugs.gentoo.org/attachment.cgi?id=214023 for his patch. In short
it's this:
> -# Some versions of libedit contain strlcpy(); so disregard that library while
> +# Some versions of libedit and libroken contain strlcpy(); so disregard that
> library while
> # checking for these standard libc functions.
> pgac_save_LIBS="$LIBS"
> -LIBS=`echo "$LIBS" | sed -e 's/-ledit//g' -e 's/-lreadline//g'`
> +LIBS=`echo "$LIBS" | sed -e 's/-ledit//g' -e 's/-lreadline//g' -e
> 's/-lgssapi//g' -e 's/-lkrb5//g'`
Another alternative might be choosing behaviour based on the detection
of suitable function declarations, i.e. HAVE_DECL_STRLCAT instead of
HAVE_STRLCAT. Or you might try enabling the -Wl,--as-needed flag before
detecting these library functions, to ensure the same behaviour at
configure time and at build time. In both cases you might whish to
rename those symbols in case you use your own implementation, just to
make sure the linker knows which one to choose.
Please choose a suitable method to fix this build error for PostgreSQL.
Thanks,
Martin von Gagern
signature.asc
Description: OpenPGP digital signature
--- End Message ---
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
