I have just tested postgresql 8.4.1 and found that my system is unable to compile it, both x86_64 & x86 tested with the same error. here is the logs: i686-pc-linux-gnu-gcc -O2 -march=i686 -pipe -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -DECPG_COMPILE -L../../../../src/port -Wl,-O1 -Wl,--as-needed -Wl,-rpath,'/usr/lib/postgresql-8.4/lib' preproc.o type.o ecpg.o output.o parser.o keywords.o c_keywords.o ecpg_keywords.o kwlookup.o ../ecpglib/typename.o descriptor.o variable.o -lpgport -lpam -lssl -lcrypto -lgssapi -lkrb5 -lcrypto -lz -lreadline -lcrypt -ldl -lm -lpthread -o ecpg descriptor.o: In function `descriptor_variable': descriptor.c:(.text+0x2a): undefined reference to `strlcpy' ../../../../src/port/libpgport.a(path.o): In function `get_home_path': path.c:(.text+0x241): undefined reference to `strlcpy' ../../../../src/port/libpgport.a(path.o): In function `join_path_components': path.c:(.text+0x5c6): undefined reference to `strlcpy' ../../../../src/port/libpgport.a(path.o): In function `T.45': path.c:(.text+0x6f5): undefined reference to `strlcpy' path.c:(.text+0x732): undefined reference to `strlcpy' collect2: ld returned 1 exit status make[4]: *** [ecpg] Error 1 make[4]: Leaving directory `/var/tmp/portage/dev-db/postgresql-base-8.4.1/work/postgresql-8.4.1/src/interfaces/ecpg/preproc' make[3]: *** [all] Error 2 make[3]: Leaving directory `/var/tmp/portage/dev-db/postgresql-base-8.4.1/work/postgresql-8.4.1/src/interfaces/ecpg' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/dev-db/postgresql-base-8.4.1/work/postgresql-8.4.1/src/interfaces' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/portage/dev-db/postgresql-base-8.4.1/work/postgresql-8.4.1/src' make: *** [all] Error 2 * * ERROR: dev-db/postgresql-base-8.4.1 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2994: Called die * The specific snippet of code: * emake LD="$(tc-getLD) $(get_abi_LDFLAGS)" || die "emake failed"; * The die message: * emake failed zymtest3 ~ # emerge --info Portage 2.2_rc41 (default/linux/x86/10.0, gcc-4.4.1, glibc-2.10.1-r0, 2.6.30-gentoo-r6-zym i686) ================================================================= System uname: Linux-2.6.30-gentoo-r6-zym-i686-QEMU_Virtual_CPU_version_0.10.50-with-gentoo-2.0.1 Timestamp of tree: Tue, 22 Sep 2009 03:30:01 +0000 distcc 3.1 i686-pc-linux-gnu [disabled] app-shells/bash: 4.0_p33 dev-lang/python: 2.6.2-r1 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.4.3-r3 sys-apps/sandbox: 2.1 sys-devel/autoconf: 2.63-r1 sys-devel/automake: 1.10.2, 1.11 sys-devel/binutils: 2.19.1-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/eselect/postgresql /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests buildpkg distlocks fixpackages parallel-fetch preserve-libs protect-owned sandbox sfperms sign strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="-Wl,-O1" LINGUAS="zh_CN en" MAKEOPTS="-j10" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 accessibility acl acpi alsa apache2 avahi berkdb bindist bluetooth branding bzip2 cairo cdr cjk cli cracklib crypt cups curl dbus dri dts dvdr eds emboss encode esd exif fam firefox foomaticdb fortran fuse gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 hal iconv idn imlib ipv6 irda isdnlog jpeg kerberos lcms ldap libnotify libwww mad mailwrapper midi mng modules motif mp3 mpeg mudflap nas ncurses nls nptl nptlonly nsplugin ogg opengl openmp oss pam pcmcia pcre perl php png pppd pulseaudio python quicktime readline reflection samba sdl session snmp spell spl ssl svg svga sysfs tcpd threads tiff truetype udev unicode usb userlocales v4l v4l2 vhosts vorbis win32codecs x264 x86 xcb xine xinerama xml xorg xulrunner xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="zh_CN en" USERLAND="GNU" VIDEO_CARDS="vga vesa fbdev" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Attach full build.log and config.log.
Created attachment 204985 [details] postgresql-base-8.4.1 config.log
Created attachment 204987 [details] postgresql-base-8.4.1 buildlog
As you may see, the problem comes up during configure: it doesn't find strlcpy definitions, but it finds the functions, somewhere among 'lpam -lssl -lcrypto -lgssapi -lkrb5 -lcrypto -lz -lcrypt -ldl -lm' (probably krb5, you may check that).
Encountered a similar issue with boinc and heimdal in the past. Maybe the solution from bug #248769 comment #13 can be reused.
Created attachment 205132 [details, diff] Use pg implementation of strlcpy and strlcat This is an adaptation of bug #248769 comment #13 to postgresql-base. With this patch applied to the ebuild, the application emerges cleanly, and should run without any symbol lookup issues (though I haven't tested it). The list of affected symbols, i.e. "strlcpy" and "strlcat", was determined through trial and error. So its the minimum required for postgresql-base on systems with heimdal, at least for current versions of both.
Strange, I do have heimdal and don't have your problem.
I've got app-crypt/heimdal-1.2.1-r4 and was about to install dev-db/postgresql-base-8.4.1[kerberos] (and have soucceeded now with my patch). "ldd /usr/lib/libkrb5.so" and "ldd /usr/lib/libgssapi.so" both mention /usr/lib/libroken.so.18. "objdump -T /usr/lib/libroken.so.18 | egrep 'strlcat|strlcpy'" will list both symbols in the .text section of that library, so they are provided. The configure script of postgresql-base prints these lines: checking whether strlcat is declared... no checking whether strlcpy is declared... no checking for strlcat... yes checking for strlcpy... yes These results can also be found in the generated header file: $ egrep '_STRL(CPY|CAT)' /var/tmp/portage/dev-db/postgresql-base-8.4.1/work/postgresql-8.4.1/src/include/pg_config.h #define HAVE_DECL_STRLCAT 0 #define HAVE_DECL_STRLCPY 0 #define HAVE_STRLCAT 1 #define HAVE_STRLCPY 1 I guess if you fail to reproduce the issue, at least one of these facts is different for you, and it would be interesting to know which. Come to think of it, the src/include/port.h header of postgresql does provide a prototype for strlcat and strlcpy if none is available. So including that header into the failing descriptor.c should solve the issue for now. On the other hand, once heimdal stops providing these symbols, as is intended for the next release, this approach might break runtime behaviour, so I'd not persue that avenue right now.
Same heimdal and postgresql-base here and those two symbols seem to be in my roken too. Perhaps --as-needed plays a role ?
(In reply to comment #9) > Perhaps --as-needed plays a role ? Seems likely: with --as-needed, it compiles for me as well. Don't know what would happen at runtime, though. As the functions should have the same semantics, I guess that should be all right, too. Still, requiring --as-needed seems like a workaround at best, not a proper solution.
AFAICT, you've already given correct solution: > once heimdal stops providing these symbols Of course, waiting for it may be quite annoying.
the patch from Martin von Gagern works for this bug, but it still can't make postgresql-server happy: make[4]: Entering directory `/var/tmp/portage/dev-db/postgresql-server-8.4.1/work/postgresql-8.4.1/src/backend/utils/hash' i686-pc-linux-gnu-gcc -O2 -march=i686 -fomit-frame-pointer -pipe -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -I../../../../src/include -I../../../../src/include -Dstrlcat=pg_strlcat -Dstrlcpy=pg_strlcpy -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/postgresql-8.4/ -c -o dynahash.o dynahash.c -MMD -MP -MF .deps/dynahash.Po dynahash.c: In function 'hash_create': dynahash.c:315: error: 'pg_strlcpy' undeclared (first use in this function) dynahash.c:315: error: (Each undeclared identifier is reported only once dynahash.c:315: error: for each function it appears in.) make[4]: *** [dynahash.o] Error 1
same problem here. although USE="-kerberos" sorted it for me (since I only need it for samba i don'T care if postgres has it ..
Created attachment 214023 [details, diff] postgresql-8.4-heimdal_strlcpy.patch Heimdal apparently is not the only package that provides strlcpy function by accident, and the postgresql-base configure script already protects itself from such a libedit. A simple extension of that mechanism to kerberos libraries seems to work: This is such a patch to the configure scripts.
Created attachment 214024 [details, diff] postgresql-base-8.4.1.ebuild.diff This is the modification of the postgresql-base-8.4.1.ebuild to use the patch above.
tested with patch postgresql-8.4-heimdal_strlcpy.patch works on postgresql-base & postgresql-server, I have tested this patch with the ebuild from portage of version 8.4.2-r1 thanks.
Is dev-db/postgresql-base-8.4.3 the only one that needs the patch? Or do the other branches need it as well(7.4.28, 8.0.24, 8.1.20, 8.2.16, 8.3.10)?
(In reply to comment #17) > Is dev-db/postgresql-base-8.4.3 the only one that needs the patch? Or do the > other branches need it as well(7.4.28, 8.0.24, 8.1.20, 8.2.16, 8.3.10)? > Well, I've answered my own question. 8.4 and 9.0 require the patch. Mr. von Gagern, since you seem to know what is happening here, would you report this upstream?
(In reply to comment #18) > Mr. von Gagern, [...], would you report this upstream? Reported upstream to pgsql-bugs@p.o mailing list, cc to Gentoo maintainers. Subject: "build error: strlcat/strlcpy used from heimdal libroken.so" Awaiting moderation. Will try to post a gmane link later on. Would nevertheless like to see this fixed at the distro level asap.
(In reply to comment #19) > Will try to post a gmane link later on. http://thread.gmane.org/gmane.comp.db.postgresql.bugs/22987 Do you want to make this the URL for this bug report here?
(In reply to comment #19) > (In reply to comment #18) > > Mr. von Gagern, [...], would you report this upstream? > > Reported upstream to pgsql-bugs@p.o mailing list, cc to Gentoo maintainers. > Subject: "build error: strlcat/strlcpy used from heimdal libroken.so" > Awaiting moderation. Will try to post a gmane link later on. > Would nevertheless like to see this fixed at the distro level asap. > Thanks for doing that. You definitely know way more about the Heimdal issue than I could possibly fathom. I have already submitted a collection of ebuilds, of which 8.4.3-r1 and 9.0_alpha4-r1 have this patch applied, to be committed to the tree to Mr. Müller (dev-zero).
(In reply to comment #20) > http://thread.gmane.org/gmane.comp.db.postgresql.bugs/22987 That post has been forwarded to the pgsql-hackers@p.o list by Craig Ringer: http://thread.gmane.org/gmane.comp.db.postgresql.devel.general/139424
update for newer heimdal, as of heimdal-1.3.2-r1 testing pkg, there is no strlcpy exposed anymore. so I have build postgresql without the strlcpy problem anymore. zym6400 ~ # readelf -s /usr/lib/libroken.so.18.1.0 | grep strlcpy 269: 0000000000010e90 87 FUNC GLOBAL DEFAULT 12 rk_strlcpy@@HEIMDAL_ROKEN_1.0
+ 02 Jun 2010; Patrick Lauer <patrick@gentoo.org> + +postgresql-base-7.4.29-r1.ebuild, +postgresql-base-8.0.25-r1.ebuild, + +postgresql-base-8.1.21-r1.ebuild, +postgresql-base-8.2.17-r1.ebuild, + +postgresql-base-8.3.11-r1.ebuild, + +files/postgresql-base-8.4-9.0-heimdal_strlcpy.patch, + +postgresql-base-8.4.4-r1.ebuild, +postgresql-base-9.0_beta1-r1.ebuild: + Fixes for #313765, #251046, #294462, #300793, #274836, #296714, #238817, + #278228, #263096, #246397, #285953. Thanks to Aaron Swenson for collecting + the fixes and testing.
Now that heimdal-1.3.2-r1 doesn't require the patch, is there any harm if the patch is applied? More to the point: if dev-db/postgresql-base is built with the patch and heimdal-1.3.2-r1 goes stable after -base is compiled, will the patch interfere with the functionality of Heimdal? I lack the capability to test such a situation, so I need one of you to test it and report back. I thank you for your effort in advance.
(In reply to comment #25) > Now that heimdal-1.3.2-r1 doesn't require the patch, is there any harm if the > patch is applied? no, there is no harm, nothing impacted. > > More to the point: if dev-db/postgresql-base is built with the patch and > heimdal-1.3.2-r1 goes stable after -base is compiled, will the patch interfere > with the functionality of Heimdal? if heimdal bump from 1.2 to 1.3, postgreqsl-base/server will need to remerge, due to the @preserved-rebuild. > > I lack the capability to test such a situation, so I need one of you to test it > and report back. I thank you for your effort in advance. >
(In reply to comment #26) > (In reply to comment #25) > > Now that heimdal-1.3.2-r1 doesn't require the patch, is there any harm if the > > patch is applied? > > no, there is no harm, nothing impacted. > > > > More to the point: if dev-db/postgresql-base is built with the patch and > > heimdal-1.3.2-r1 goes stable after -base is compiled, will the patch interfere > > with the functionality of Heimdal? > > if heimdal bump from 1.2 to 1.3, postgreqsl-base/server will need to remerge, > due to the @preserved-rebuild. > > > > I lack the capability to test such a situation, so I need one of you to test it > > and report back. I thank you for your effort in advance. > > > Great! Thanks for your time.
