Thread: Solaris compile problem
============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================
Your name : Karl DeBisschop
Your email address : kdebisschop@alert.infoplease.com
System Configuration
---------------------
Architecture (example: Intel Pentium) : Sun E-450
Operating System (example: Linux 2.0.26 ELF) : Solaris 7
PostgreSQL version (example: PostgreSQL-6.5.1): postgresql-7.0.1
Compiler used (example: gcc 2.8.0) : gcc version egcs-2.91.66
19990314 (egcs-1.1.2 release)
Please enter a FULL description of your problem:
------------------------------------------------
after `./configure --prefix-/opt/postgresql-7.0.1`
make bailed on libpq++
make[2]: Entering directory `/u/kdebisschop/postgresql-7.0.1/src/interfaces/libpq++'
ld -G -o libpq++.so.3.1 pgconnection.o pgdatabase.o pgtransdb.o pgcursordb.o pglobject.o -L../../interfaces/libpq -lpq
-ldl-lsocket -lresolv -lnsl -lm -lc
pgconnection.o: could not read symbols: Bad value
make[2]: *** [libpq++.so.3.1] Error 1
I don't use libpq++.so.3.1 so I just did:
cd /u/kdebisschop/postgresql-7.0.1/src/interfaces/libpq++
gcc -shared -G -o libpq++.so.3.1 pgconnection.o pgdatabase.o pgtransdb.o pgcursordb.o pglobject.o
-L../../interfaces/libpq-lpq -ldl -lsocket -lresolv -lnsl -lm -lc
cd ~/postgresql-7.0.1/src
make
and everything picked up fine (I have not yet run regression tests)
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------
If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------
Karl DeBisschop <kdebisschop@h00a0cc3b7988.ne.mediaone.net> writes:
> after `./configure --prefix-/opt/postgresql-7.0.1`
> make bailed on libpq++
> make[2]: Entering directory `/u/kdebisschop/postgresql-7.0.1/src/interfaces/libpq++'
> ld -G -o libpq++.so.3.1 pgconnection.o pgdatabase.o pgtransdb.o pgcursordb.o pglobject.o -L../../interfaces/libpq
-lpq-ldl -lsocket -lresolv -lnsl -lm -lc
> pgconnection.o: could not read symbols: Bad value
> make[2]: *** [libpq++.so.3.1] Error 1
Hmm. Did it build for you in the 7.0 release? I just went looking
for changes that could've caused this between 7.0 and 7.0.1, and
didn't see anything obvious...
regards, tom lane
Tom Lane wrote: > > Karl DeBisschop <kdebisschop@h00a0cc3b7988.ne.mediaone.net> writes: > > after `./configure --prefix-/opt/postgresql-7.0.1` > > make bailed on libpq++ > > > make[2]: Entering directory `/u/kdebisschop/postgresql-7.0.1/src/interfaces/libpq++' > > ld -G -o libpq++.so.3.1 pgconnection.o pgdatabase.o pgtransdb.o pgcursordb.o pglobject.o -L../../interfaces/libpq -lpq-ldl -lsocket -lresolv -lnsl -lm -lc > > pgconnection.o: could not read symbols: Bad value > > make[2]: *** [libpq++.so.3.1] Error 1 > > Hmm. Did it build for you in the 7.0 release? I just went looking > for changes that could've caused this between 7.0 and 7.0.1, and > didn't see anything obvious... > > regards, tom lane Sorry - I only had time to compile 7.0 for linux. Actually, the only reason I'm compiling for solaris is to test a configure script for a different OSS project. So it doesn't really bother me personally if this doesn't get resolved immediately. One the other hand, if it does ring a bell with anyone and there is a potential fix, I'd be glad to try it out on the offending machine, just in the interest of making the build process a little more robust. -- Karl
Karl DeBisschop <kdebisschop@h00a0cc3b7988.ne.mediaone.net> writes:
>> Hmm. Did it build for you in the 7.0 release? I just went looking
>> for changes that could've caused this between 7.0 and 7.0.1, and
>> didn't see anything obvious...
> Sorry - I only had time to compile 7.0 for linux.
Can you say if libpq++ *ever* built on that platform? I'm guessing
that Solaris needs the same sort of hack that is present in libpq++'s
Makefile for irix5, ie set AR and LD to $(CXX). But if I'm right
then it'd never have worked...
regards, tom lane
Tom Lane wrote: > > Karl DeBisschop <kdebisschop@h00a0cc3b7988.ne.mediaone.net> writes: > >> Hmm. Did it build for you in the 7.0 release? I just went looking > >> for changes that could've caused this between 7.0 and 7.0.1, and > >> didn't see anything obvious... > > > Sorry - I only had time to compile 7.0 for linux. > > Can you say if libpq++ *ever* built on that platform? I'm guessing > that Solaris needs the same sort of hack that is present in libpq++'s > Makefile for irix5, ie set AR and LD to $(CXX). But if I'm right > then it'd never have worked... > > regards, tom lane it did work in 6.4.2 and ld does work in other parts of the make - it only fails in this one place. -- Karl
Karl DeBisschop <kdebisschop@h00a0cc3b7988.ne.mediaone.net> writes:
>> Can you say if libpq++ *ever* built on that platform? I'm guessing
>> that Solaris needs the same sort of hack that is present in libpq++'s
>> Makefile for irix5, ie set AR and LD to $(CXX). But if I'm right
>> then it'd never have worked...
> it did work in 6.4.2
OK, that's a useful datapoint.
> and ld does work in other parts of the make - it only fails in this one
> place.
Sure. I think the problem likely is that the stock "ld" on Solaris only
copes with C object files and not C++ object files. This only shows up
for libpq++ because we have no other C++ code in the distribution.
However, as far as I can tell from a quick scan through the CVS server,
6.4.* should've tried to use "ld" for libpq++ too. Could you rebuild
6.4.2 and see what the difference is in the build commands it uses?
regards, tom lane
Tom Lane wrote: > > Karl DeBisschop <kdebisschop@h00a0cc3b7988.ne.mediaone.net> writes: > >> Can you say if libpq++ *ever* built on that platform? I'm guessing > >> that Solaris needs the same sort of hack that is present in libpq++'s > >> Makefile for irix5, ie set AR and LD to $(CXX). But if I'm right > >> then it'd never have worked... > > > it did work in 6.4.2 > > OK, that's a useful datapoint. > > > and ld does work in other parts of the make - it only fails in this one > > place. > > Sure. I think the problem likely is that the stock "ld" on Solaris only > copes with C object files and not C++ object files. This only shows up > for libpq++ because we have no other C++ code in the distribution. > > However, as far as I can tell from a quick scan through the CVS server, > 6.4.* should've tried to use "ld" for libpq++ too. Could you rebuild > 6.4.2 and see what the difference is in the build commands it uses? > > regards, tom lane downloaded the source and rebuilt. make died at the same place. Yet the old install does have libpq++ in place. 6.4.2 was orignally compiled by another developer here. So I don't know if he had the same problem and used the same hack to get past it, or if there was a difference in his environment settings (or something has been upgraded in between times - it seems we may have been on Solaris 6 when 6.4.2 was last compiled, for instance) I'll talk to the developer when he gets in, but this tack may be a dead end. -- Karl