I have patchless postgres 8.x working to the extent that it's not
segfaulting on AIX 5.3 here, ML3 and built with gcc 4.0.1. There are
two different ways that I've done it, adding "-lc" to the LDFLAGS passed
to configure, and passing "--without-readline" to configure. All 98
regression tests pass with "--without-readline", but the inet test fails
when LDFLAGS is set to "-lc".

What is happening with postgres certainly appears to be related to the
linker; in dynahash.c, the keycopy functions that work with no new
linker flags (strncpy, memmove worked as a memcpy replacement) are all
exported by libreadline.a, while the segfaulting/infinite-looping memcpy
is not. When all the keycopy functions are from libc.a, by not linking
against libreadline or by telling the linker to first check libc, all
the keycopy functions, including memcpy, work.

LDFLAGS configuration
$ LDFLAGS="-lc" ./configure \
--prefix=/opt/dbs/pgsql810-afilias-AIX53-2005-11-16 \
--with-includes=/opt/freeware/include --enable-debug \
--enable-thread-safety --with-libraries=/opt/freeware/lib \
--enable-casert

no readline configuration
$ ./configure --prefix=/opt/dbs/pgsql810-afilias-AIX53-2005-11-16 \
--with-includes=/opt/freeware/include --enable-debug \
--enable-thread-safety --with-libraries=/opt/freeware/lib \
--enable-casert --without-readline

--
Seneca Cunningham
scunning@ca.afilias.info

Search Discussions

  • Tom Lane at Nov 16, 2005 at 11:28 pm

    Seneca Cunningham writes:
    What is happening with postgres certainly appears to be related to the
    linker; in dynahash.c, the keycopy functions that work with no new
    linker flags (strncpy, memmove worked as a memcpy replacement) are all
    exported by libreadline.a, while the segfaulting/infinite-looping memcpy
    is not.
    libreadline exports these?? I'd say you have a seriously braindead copy
    of libreadline ... can you recompile a fresh copy off the net?

    The inet failures look like there is consistently no support for IPv6.
    I wonder if the linker is somehow replacing our own inet-parsing
    subroutines with a non-IPv6-aware set. It's conceivable that there
    could be a name collision with subroutines from an old version of
    libbind.

    regards, tom lane
  • Seneca Cunningham at Nov 17, 2005 at 4:20 pm

    Tom Lane wrote:
    Seneca Cunningham <scunning@ca.afilias.info> writes:
    What is happening with postgres certainly appears to be related to the
    linker; in dynahash.c, the keycopy functions that work with no new
    linker flags (strncpy, memmove worked as a memcpy replacement) are all
    exported by libreadline.a, while the segfaulting/infinite-looping memcpy
    is not.

    libreadline exports these?? I'd say you have a seriously braindead copy
    of libreadline ... can you recompile a fresh copy off the net?
    That was just IBM's rpm of readline 4.3, my fresh build of readline 5.0
    exports memcpy in addition to the aforementioned functions. As a
    result, LDFLAGS-less postgres doesn't segfault but it gets its memcpy
    linked through libreadline. libreadline's build scripts, at least for
    5.0, don't seem to give a build that can be properly linked against on
    AIX, and it's entirely possible that my build used different linker
    flags than IBM's to get a libreadline that actually exports what it
    provides.
    The inet failures look like there is consistently no support for IPv6.
    I wonder if the linker is somehow replacing our own inet-parsing
    subroutines with a non-IPv6-aware set. It's conceivable that there
    could be a name collision with subroutines from an old version of
    libbind.
    The linker appears to be grabbing the inet functions from the AIX libc,
    not the postgres set. LDFLAGS is placed before all the SUBSYS.o, and by
    my understanding of the AIX linker, adding "-lc" to LDFLAGS would cause
    it to search libc.a before utils/SUBSYS.o and use the functions like
    inet_net_pton from libc.

    --
    Seneca Cunningham
    scunning@ca.afilias.info

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-ports @
categoriespostgresql
postedNov 16, '05 at 10:33p
activeNov 17, '05 at 4:20p
posts3
users2
websitepostgresql.org
irc#postgresql

2 users in discussion

Seneca Cunningham: 2 posts Tom Lane: 1 post

People

Translate

site design / logo © 2022 Grokbase