Обсуждение: Fwd: 8.3.3 compile fails on Mac OS X 10.5.2
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
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 <rlucas@tercent.com> 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 >
"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
"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
On Fri, Jun 27, 2008 at 7:58 PM, Tom Lane <tgl@sss.pgh.pa.us> 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 ...
"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
On Tue, Jul 1, 2008 at 7:50 PM, Tom Lane <tgl@sss.pgh.pa.us> 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
On Wed, Jul 2, 2008 at 10:11 AM, Randall Lucas <rlucas@tercent.com> wrote: > On Tue, Jul 1, 2008 at 7:50 PM, Tom Lane <tgl@sss.pgh.pa.us> 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.
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. +