Re: build error: strlcat/strlcpy used from heimdal libroken.so - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: build error: strlcat/strlcpy used from heimdal libroken.so
Date
Msg-id 201004150159.o3F1xdl26692@momjian.us
Whole thread Raw
In response to build error: strlcat/strlcpy used from heimdal libroken.so  (Martin von Gagern <Martin.vGagern@gmx.net>)
Responses Re: build error: strlcat/strlcpy used from heimdal libroken.so
List pgsql-bugs
I haven't seen anyone reply to this report, which might mean we are
waiting for Gentoo to be fixed.  Gentoo is notoriously dynamic and it is
hard for us to adjust based on their changes in every case, which I
guess explains why 8.4.X has not been fixed either.

---------------------------------------------------------------------------

Martin von Gagern wrote:
-- Start of PGP signed section.
> 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
>
-- End of PGP section, PGP failed!

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: initdb stores default client_encoding from environment-variable
Next
From: Tom Lane
Date:
Subject: Re: initdb stores default client_encoding from environment-variable