FAQ
Compiling of PostgreSQL 8.3.3 on Mac OS X 10.5.2 (9C2031) fails with
the following error. I got the same error whether I did a "vanilla"
./configure or whether I used a variety of --with-X flags (e.g. perl,
libxslt). The use or non-use of --with-libedit-preferred does not
change the outcome (as suggested in this blog post:
http://www.stereoplex.com/two-voices/error-compiling-postgresql-8.3-on-leopard-rl_completion_matches
)

This is a fairly stock 10.5 machine (quad-core Mac Pro) that I just
got last week, but I do have developer tools installed on it.

Also, a pending software update is about to require me to reboot. (I
will post again if the update fixes the issue).

Any suggestions? More info needed?

Error:

gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Winline -Wdeclaration-after-statement -Wendif-labels
-fno-strict-aliasing -fwrapv -dynamiclib -install_name
/usr/local/pgsql-8.3/lib/libecpg.6.dylib -compatibility_version 6
-current_version 6.0 -exported_symbols_list exports.list
-multiply_defined suppress execute.o typename.o descriptor.o data.o
error.o prepare.o memory.o connect.o misc.o path.o pgstrcasecmp.o
thread.o -L../pgtypeslib -L../../../../src/interfaces/libpq
-L../../../../src/port -L/sw/lib -L/sw/lib -lpgtypes -lpq -lm -o
libecpg.6.0.dylib
Undefined symbols:
"_PGTYPESdate_from_asc", referenced from:
_ecpg_get_data in data.o
_ecpg_get_data in data.o
"_PQfinish", referenced from:
_ecpg_finish in connect.o
"_PQsetdbLogin", referenced from:
_ECPGconnect in connect.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[4]: *** [libecpg.6.0.dylib] Error 1
make[3]: *** [all] Error 2
make[2]: *** [all] Error 2
make[1]: *** [all] Error 2
make: *** [all] Error 2

Search Discussions

  • Randall Lucas at Jun 28, 2008 at 12:55 am
    Just confirmed after make distclean and ./configure that the same
    error persists in Mac OS X 10.5.3 (9D34).

    Best,

    Randall
    On Fri, Jun 27, 2008 at 4:08 PM, Randall Lucas wrote:
    Compiling of PostgreSQL 8.3.3 on Mac OS X 10.5.2 (9C2031) fails with
    the following error. I got the same error whether I did a "vanilla"
    ./configure or whether I used a variety of --with-X flags (e.g. perl,
    libxslt). The use or non-use of --with-libedit-preferred does not
    change the outcome (as suggested in this blog post:
    http://www.stereoplex.com/two-voices/error-compiling-postgresql-8.3-on-leopard-rl_completion_matches
    )

    This is a fairly stock 10.5 machine (quad-core Mac Pro) that I just
    got last week, but I do have developer tools installed on it.

    Also, a pending software update is about to require me to reboot. (I
    will post again if the update fixes the issue).

    Any suggestions? More info needed?

    Error:

    gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith
    -Winline -Wdeclaration-after-statement -Wendif-labels
    -fno-strict-aliasing -fwrapv -dynamiclib -install_name
    /usr/local/pgsql-8.3/lib/libecpg.6.dylib -compatibility_version 6
    -current_version 6.0 -exported_symbols_list exports.list
    -multiply_defined suppress execute.o typename.o descriptor.o data.o
    error.o prepare.o memory.o connect.o misc.o path.o pgstrcasecmp.o
    thread.o -L../pgtypeslib -L../../../../src/interfaces/libpq
    -L../../../../src/port -L/sw/lib -L/sw/lib -lpgtypes -lpq -lm -o
    libecpg.6.0.dylib
    Undefined symbols:
    "_PGTYPESdate_from_asc", referenced from:
    _ecpg_get_data in data.o
    _ecpg_get_data in data.o
    "_PQfinish", referenced from:
    _ecpg_finish in connect.o
    "_PQsetdbLogin", referenced from:
    _ECPGconnect in connect.o
    ld: symbol(s) not found
    collect2: ld returned 1 exit status
    make[4]: *** [libecpg.6.0.dylib] Error 1
    make[3]: *** [all] Error 2
    make[2]: *** [all] Error 2
    make[1]: *** [all] Error 2
    make: *** [all] Error 2
  • Tom Lane at Jun 28, 2008 at 2:46 am

    "Randall Lucas" <rlucas@tercent.com> writes:
    Compiling of PostgreSQL 8.3.3 on Mac OS X 10.5.2 (9C2031) fails with
    the following error.
    Weird. It works on the laptop I'm typing on, and there are several OSX
    buildfarm machines that aren't complaining either. Are you sure you're
    using an up-to-date install of the developer tools? I seem to recall
    that it's possible to update, eg, 10.4 to 10.5 without updating your
    developer tools, but the tools don't actually work thereafter ...

    regards, tom lane
  • Tom Lane at Jun 28, 2008 at 2:58 am

    "Randall Lucas" <rlucas@tercent.com> writes:
    gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith
    -Winline -Wdeclaration-after-statement -Wendif-labels
    -fno-strict-aliasing -fwrapv -dynamiclib -install_name
    /usr/local/pgsql-8.3/lib/libecpg.6.dylib -compatibility_version 6
    -current_version 6.0 -exported_symbols_list exports.list
    -multiply_defined suppress execute.o typename.o descriptor.o data.o
    error.o prepare.o memory.o connect.o misc.o path.o pgstrcasecmp.o
    thread.o -L../pgtypeslib -L../../../../src/interfaces/libpq
    -L../../../../src/port -L/sw/lib -L/sw/lib -lpgtypes -lpq -lm -o
    libecpg.6.0.dylib
    Undefined symbols:
    Comparing this to a fresh build log on my own machine, the only obvious
    difference is the (duplicated) -L/sw/lib that your log has and mine
    doesn't. I'm thinking maybe you have old or broken PG shared libraries
    in that directory that're messing up the link. I'm not convinced of
    that, because these -L switches are last in the command and so really
    shouldn't be determining anything; but it's a place to start looking.

    regards, tom lane
  • Randall Lucas at Jul 1, 2008 at 10:42 pm

    On Fri, Jun 27, 2008 at 7:58 PM, Tom Lane wrote:
    I'm thinking maybe you have old or broken PG shared libraries
    in that directory that're messing up the link.
    Thanks for having a look. As you'll see below, that was a red
    herring. Apologies for the long email, but I want to include as much
    search-engine bait as possible for folks with the same problem.

    I dug in a bit more. It turns out that the Apple process of
    transferring my data over from my old box transferred my
    Fink-installed UNIX apps, including PostgreSQL 8.1. So I *do* have an
    old set of libraries installed in /sw/lib/postgresql-8.1

    I manually went into src/Makefile.global and changed LDFLAGS (the
    source of the duplicate "-L/sw/lib" entry) to blank. (I couldn't seem
    to get configure to do so.)

    The result is below. No more -L/sw/lib in the gcc command line that
    barfs, but the same error message comes out:

    gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith
    -Winline -Wdeclaration-after-statement -Wendif-labels
    -fno-strict-aliasing -fwrapv -dynamiclib -install_name
    /usr/local/pgsql-8.3/lib/libecpg.6.dylib -compatibility_version 6
    -current_version 6.0 -exported_symbols_list exports.list
    -multiply_defined suppress execute.o typename.o descriptor.o data.o
    error.o prepare.o memory.o connect.o misc.o path.o pgstrcasecmp.o
    thread.o -L../pgtypeslib -L../../../../src/interfaces/libpq
    -L../../../../src/port -lpgtypes -lpq -lm -o libecpg.6.0.dylib
    Undefined symbols:
    "_PGTYPESdate_from_asc", referenced from:
    _ecpg_get_data in data.o
    _ecpg_get_data in data.o
    "_PQfinish", referenced from:
    _ecpg_finish in connect.o
    "_PQsetdbLogin", referenced from:
    _ECPGconnect in connect.o
    ld: symbol(s) not found
    collect2: ld returned 1 exit status
    make[4]: *** [libecpg.6.0.dylib] Error 1
    make[3]: *** [all] Error 2
    make[2]: *** [all] Error 2
    make[1]: *** [all] Error 2
    make: *** [all] Error 2

    So then I started digging in and poking around the actual makefiles.
    It looks like the symbols that data.c is referencing come from
    src/interfaces/ecpg/pgtypeslib

    The file exports.list in src/interfaces/ecpg/pgtypeslib does NOT
    contain the missing symbol _PGTYPESdate_from_asc

    I checked the output of make, and this line caught my eye:

    awk '/^[^#]/ {printf "_%s\n",$1}' exports.txt >exports.list

    This should be dumping out any the first word of any line that doesn't
    start with a # to exports.list, prepended with "_", right?

    Well, as it turns out, lines 1-2 of exports.txt are comments, and
    lines 3-11 look like:

    PGTYPESdate_dayofweek 1
    PGTYPESdate_defmt_asc 2
    PGTYPESdate_fmt_asc 3
    PGTYPESdate_free 4
    PGTYPESdate_from_asc 5
    PGTYPESdate_from_timestamp 6
    PGTYPESdate_julmdy 7
    PGTYPESdate_mdyjul 8
    PGTYPESdate_new 9

    (Note the presence of our missing symbol, date_from_asc)

    All of these first nine symbols are missing from my copy of
    exports.list! (The rest of the symbols, 10-n, appear fine.)

    Sure enough, one of the other offenders -- PQfinish -- is present in
    the first nine symbols in src/interfaces/libpq/exports.txt but missing
    from src/interfaces/libpq/exports.list

    Could it be that my awk is buggy or not playing nice?

    $ which awk
    /sw/bin/awk
    $ ls -al /sw/bin/awk
    lrwxr-xr-x 1 root admin 4 Jun 19 18:50 /sw/bin/awk -> gawk
    $ awk -W version
    GNU Awk 3.1.4

    I also have a system awk in /usr/bin/awk, but my $PATH (using standard
    Fink init.sh practice of prepending) puts /sw/bin first.

    It appears that PG knows that I have gawk:

    $ grep 'awk' config.log
    configure:5084: checking for gawk
    configure:5100: found /sw/bin/gawk
    configure:5110: result: gawk
    ac_cv_prog_AWK=gawk
    AWK='gawk'

    When I blow away /sw/bin/awk, so that make uses /usr/bin/awk instead,
    I get a make that executes perfectly and a make check with "All 114
    tests passed."

    So, at least for now, my problem is solved. But I remain very much
    puzzled. Does anyone here know if my gawk is behaving properly? (I
    tried it with both --compat and --posix flags to see if that fixed the
    behavior; no effect.) And if it is, and PG knows that gawk behaves
    that way and detected it, shouldn't the PG makefile have adapted its
    awk invocation to use the gawk syntax?

    Comments are most welcome here before I move over to the GNU awk list
    and start accusing pretty much the oldest program in existence of
    being broken ...
  • Tom Lane at Jul 2, 2008 at 2:50 am

    "Randall Lucas" <rlucas@tercent.com> writes:
    I dug in a bit more. It turns out that the Apple process of
    transferring my data over from my old box transferred my
    Fink-installed UNIX apps, including PostgreSQL 8.1.
    And the contents of /sw/bin, no doubt?
    When I blow away /sw/bin/awk, so that make uses /usr/bin/awk instead,
    I get a make that executes perfectly and a make check with "All 114
    tests passed."
    <spock>Fascinating.</spock>
    Comments are most welcome here before I move over to the GNU awk list
    and start accusing pretty much the oldest program in existence of
    being broken ...
    Given that we've never heard the like from anyone else, I think that
    (1) accusations against the upstream gawk maintainers seem misplaced,
    and (2) there's not anything wrong with that Makefile item either.

    I believe the most likely theory is that your copy of /sw/bin/awk
    got corrupted during the transfer from your old machine, and the
    second most likely theory is that the executable is bitwise the same
    but it doesn't play nice with the system libraries on your new box,
    and the third is that there was something wrong with that specific
    Fink-port build (though if so, it should have failed on your old
    machine too). In any case it sounds like a very local problem.

    regards, tom lane
  • Randall Lucas at Jul 2, 2008 at 5:11 pm

    On Tue, Jul 1, 2008 at 7:50 PM, Tom Lane wrote:
    "Randall Lucas" <rlucas@tercent.com> writes:
    I dug in a bit more. It turns out that the Apple process of
    transferring my data over from my old box transferred my
    Fink-installed UNIX apps, including PostgreSQL 8.1.
    And the contents of /sw/bin, no doubt?
    Yes. Although, I'd been doing UNIX-y things for the past couple weeks
    and nothing seemed broken, which makes this problem more pernicious.
    Given that we've never heard the like from anyone else, I think that
    (1) accusations against the upstream gawk maintainers seem misplaced,
    Naturally; my incredulity at the brokenness of gawk didn't come
    through, I guess ;)
    I believe the most likely theory is that your copy of /sw/bin/awk
    got corrupted during the transfer from your old machine, and the
    second most likely theory is that the executable is bitwise the same
    but it doesn't play nice with the system libraries on your new box,
    and the third is that there was something wrong with that specific
    Fink-port build (though if so, it should have failed on your old
    machine too). In any case it sounds like a very local problem.
    I like this last theory best. It is somewhat surprising to me that
    more folks haven't hollered about it, given the ubiquity (?) of
    upgrades to 10.5 from people who had installed Fink on 10.4.

    I will try compiling 8.3.3 (and testing gawk) on my old 10.4 Intel Mac
    which was the source of the gawk binary. I'll also report if the
    binary is bitwise identical. No reply solicited for that; I just want
    to keep it all in the same thread for archival / search engine
    purposes.

    Thanks again,

    Randall
  • Randall Lucas at Jul 3, 2008 at 4:06 pm

    On Wed, Jul 2, 2008 at 10:11 AM, Randall Lucas wrote:
    On Tue, Jul 1, 2008 at 7:50 PM, Tom Lane wrote:

    I believe the most likely theory is that your copy of /sw/bin/awk
    got corrupted during the transfer from your old machine, and the
    second most likely theory is that the executable is bitwise the same
    but it doesn't play nice with the system libraries on your new box,
    and the third is that there was something wrong with that specific
    Fink-port build (though if so, it should have failed on your old
    machine too). In any case it sounds like a very local problem.

    I will try compiling 8.3.3 (and testing gawk) on my old 10.4 Intel Mac
    which was the source of the gawk binary. I'll also report if the
    binary is bitwise identical. No reply solicited for that; I just want
    to keep it all in the same thread for archival / search engine
    purposes.
    $ /sw/bin/awk -W version
    GNU Awk 3.1.5

    Confirming that reinstalling Fink de novo on OS X 10.5 gives me a
    properly working gawk.
  • Bruce Momjian at Jul 5, 2008 at 2:56 am

    Tom Lane wrote:
    When I blow away /sw/bin/awk, so that make uses /usr/bin/awk instead,
    I get a make that executes perfectly and a make check with "All 114
    tests passed."
    <spock>Fascinating.</spock>
    OK, that wins the most creative tag award from me.

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

    + If your life is a hard drive, Christ can be your backup. +

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-ports @
categoriespostgresql
postedJun 27, '08 at 11:25p
activeJul 5, '08 at 2:56a
posts9
users3
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase