Skip site navigation (1) Skip section navigation (2)

Re: build error: strlcat/strlcpy used from heimdal libroken.so

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Martin von Gagern <Martin(dot)vGagern(at)gmx(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org, pgsql-bugs(at)gentoo(dot)org
Subject: Re: build error: strlcat/strlcpy used from heimdal libroken.so
Date: 2010-04-15 01:59:39
Message-ID: 201004150159.o3F1xdl26692@momjian.us (view raw or flat)
Thread:
Lists: 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(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2010-04-15 02:03:32
Subject: Re: initdb stores default client_encoding from environment-variable
Previous:From: John RegehrDate: 2010-04-15 01:22:31
Subject: Re: BUG #5416: int4inc() is wrong

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group