Обсуждение: PostgreSQL 6.5.1: libpq++ libraries on IRIX 6.5
There is a problem with libpq++.so on IRIX 6.5 (MIPSpro 7.2.1, -n32).
If you compile and link a simple program like the following:
#include "libpq++/pgdatabase.h"
main(int argc, char **argv)
{
PgDatabase *db = new PgDatabase("dbname=mydb");
db->Exec("SELECT * FROM TEST");
db->PrintTuples();
delete db;
}
and run it, you'll get the following error:
46407:./a.out: rld: Error: unresolvable symbol in
/5xxRoot/ALG/pgsql/lib/libpq++.so.3.0:
__node_allocator_lock__Q2_3std45__default_alloc_template__pt__13_XCbL11XCiL10
46407:./a.out: rld: Error: unresolvable symbol in
/5xxRoot/ALG/pgsql/lib/libpq++.so.3.0:
free_list__Q2_3std45__default_alloc_template__pt__13_XCbL11XCiL10
46407:./a.out: rld: Fatal Error: this executable has unresolvable symbols
I think this has to do with some quirks of the SGI MIPSpro compiler when
creating libraries for C++. For shared library, instead of "ld -shared",
"CC -shared" should be used to enable pre-linking (for template
instantiation). And for static library, "CC -ar" should be used instead
of "ar" (although right now if I use the static library the run-time error
does not occur).
I'm not sure whether using "CC" to create libraries for the pure C
modules would work (my guess is it should and I'll try it). If it does
then it'll be easy to patch the IRIX makefile template. But then the
downside is people will be required to have the C++ compiler even if
they don't care about libpq++.
--Yu Cao
************
Yu Cao <yucao@falcon.kla-tencor.com> writes:
> I'm not sure whether using "CC" to create libraries for the pure C
> modules would work (my guess is it should and I'll try it). If it does
> then it'll be easy to patch the IRIX makefile template. But then the
> downside is people will be required to have the C++ compiler even if
> they don't care about libpq++.
Not necessarily. Since 6.4 or so, the "template" files are not just
static assignments of variable values --- they can actually contain
arbitrary fragments of shell script (see configure.in's code that
reads them). So you could do something like
if [ -x /usr/bin/CC ]
then
CC= CC
else
CC= cc
fi
in the IRIX template.
regards, tom lane
Hi Tom, thanks for the tip. I ended up just adding a few lines to
Makefile.shlib. Attached is the context diff. The patch has been
tested on IRIX 6.5.2 with MIPSpro C and C++ compiler version 7.2.1
using -n32 ABI.
--Yu Cao
On Sat, 4 Sep 1999, Tom Lane wrote:
> Yu Cao <yucao@falcon.kla-tencor.com> writes:
> > I'm not sure whether using "CC" to create libraries for the pure C
> > modules would work (my guess is it should and I'll try it). If it does
> > then it'll be easy to patch the IRIX makefile template. But then the
> > downside is people will be required to have the C++ compiler even if
> > they don't care about libpq++.
>
> Not necessarily. Since 6.4 or so, the "template" files are not just
> static assignments of variable values --- they can actually contain
> arbitrary fragments of shell script (see configure.in's code that
> reads them). So you could do something like
> if [ -x /usr/bin/CC ]
> then
> CC= CC
> else
> CC= cc
> fi
> in the IRIX template.
>
> regards, tom lane
>
> ************
>
>
>
*** Makefile.shlib.orig Sun Sep 5 23:30:36 1999
--- Makefile.shlib Sun Sep 5 23:41:09 1999
***************
*** 61,66 ****
--- 61,72 ----
shlib := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
LDFLAGS_SL := -shared
CFLAGS += $(CFLAGS_SL)
+ ifeq ($(NAME), pq++)
+ AR := CC
+ AROPT := -ar -o
+ LD := CC
+ LDFLAGS_SL := -shared
+ endif
endif
ifeq ($(PORTNAME), freebsd)
Yu Cao <yucao@falcon.kla-tencor.com> writes:
> Hi Tom, thanks for the tip. I ended up just adding a few lines to
> Makefile.shlib. Attached is the context diff. The patch has been
> tested on IRIX 6.5.2 with MIPSpro C and C++ compiler version 7.2.1
> using -n32 ABI.
That fix bothers me, because it would interfere with someone trying
to use gcc/g++, wouldn't it? Seems safer to just alter configure's
default...
regards, tom lane
That's a good point (about interfering with gcc/g++). But I'm still a bit hesitant about changing the default AR and LD for all other libraries (although in theory it shouldn't do any harm). And if we changed the default, gcc/g++ users (who happen to have CC installed on their system) would again have to find a way to override it. So attached is another try: I put the mods in interfaces/libpq++/Makefile.in. That file already had some checks on PORTNAME (for windows) and CXX (for g++), so it seems adding more checks (for irix5 and CC) doesn't make it uglier and also gets the job done with minimal impact on other things. --Yu Cao On Mon, 6 Sep 1999, Tom Lane wrote: > Yu Cao <yucao@falcon.kla-tencor.com> writes: > > Hi Tom, thanks for the tip. I ended up just adding a few lines to > > Makefile.shlib. Attached is the context diff. The patch has been > > tested on IRIX 6.5.2 with MIPSpro C and C++ compiler version 7.2.1 > > using -n32 ABI. > > That fix bothers me, because it would interfere with someone trying > to use gcc/g++, wouldn't it? Seems safer to just alter configure's > default... *** interfaces/libpq++/Makefile.in.orig Mon Sep 6 16:05:01 1999 --- interfaces/libpq++/Makefile.in Mon Sep 6 16:10:15 1999 *************** *** 48,53 **** --- 48,61 ---- SHLIB_LINK= -L../libpq -lpq endif + ifeq ($(PORTNAME), irix5) + ifeq ($(CXX), CC) + AR = CC + AROPT = -ar -o + LD = CC + endif + endif + # Shared library stuff, also default 'all' target include $(SRCDIR)/Makefile.shlib
Yu Cao <yucao@falcon.kla-tencor.com> writes:
> attached is another try: I put the mods in interfaces/libpq++/Makefile.in.
> That file already had some checks on PORTNAME (for windows) and CXX (for
> g++), so it seems adding more checks (for irix5 and CC) doesn't make it
> uglier and also gets the job done with minimal impact on other things.
That looks good to me; will commit it. Thanks.
regards, tom lane