Обсуждение: Postgres 6.5.1 on IRIX 6.5.4 with -o32 bit libraries
I am installing a client postgres on an SGI O2 (IRIX 6.5.4) using both
the 64 bit and -o32 bit libraries. The 64 bit works fine, but the -o32
bit library gives me this on execution of a C program :
o21:reina::/database > TEST_SQL_PROGRAM
65584:TEST_SQL_PROGRAM: rld: Fatal Error: Cannot Successfully map soname
'libpq.so.2.0' under any of the filenames
/usr/local/pgsql/lib/libpq.so.2.0:/usr/local/matlab/extern/lib/sgi/libpq.so.2.0:/usr/lib/libpq.so.2.0:/usr/lib/internal/libpq.so.2.0:/lib/libpq.so.2.0:/lib/cmplrs/cc/libpq.so.2.0:/usr/lib/cmplrs/cc/libpq.so.2.0:/opt/lib/libpq.so.2.0:
Now /usr/local/pgsql/lib/libpq.so.2.0 does exist but is the 64 bit
flavor. The -o32 bit is in /usr/local/pgsql_o32/lib/libpq.so.2.0. Is
there someway that I can tell postgres to look for it there (preferably
during compilation) ? I am adding the pointers
-I/usr/local/pgsql_o32/include -L/usr/local/pgsql_o32/lib -lpq to the cc
compilation line but that doesn't seem to be correcting the problem.
Thanks.
-Tony
> I am installing a client postgres on an SGI O2 (IRIX 6.5.4) using both > the 64 bit and -o32 bit libraries. The 64 bit works fine, but the -o32 > bit library gives me this on execution of a C program : > > o21:reina::/database > TEST_SQL_PROGRAM > 65584:TEST_SQL_PROGRAM: rld: Fatal Error: Cannot Successfully map soname > 'libpq.so.2.0' under any of the filenames > /usr/local/pgsql/lib/libpq.so.2.0:/usr/local/matlab/extern/lib/sgi/libpq.so.2.0:/usr/lib/libpq.so.2.0:/usr/lib/internal/libpq.so.2.0:/lib/libpq.so.2.0:/lib/cmplrs/cc/libpq.so.2.0:/usr/lib/cmplrs/cc/libpq.so.2.0:/opt/lib/libpq.so.2.0: > > > > Now /usr/local/pgsql/lib/libpq.so.2.0 does exist but is the 64 bit > flavor. The -o32 bit is in /usr/local/pgsql_o32/lib/libpq.so.2.0. Is > there someway that I can tell postgres to look for it there (preferably > during compilation) ? I am adding the pointers > -I/usr/local/pgsql_o32/include -L/usr/local/pgsql_o32/lib -lpq to the cc > compilation line but that doesn't seem to be correcting the problem. > > Thanks. > -Tony > > I don't immediately spot the problem, but the details for searching the libraries is listed in the SGI Insight Manual "MipsPro Compiling and Performance Tuning Guide". Chapter 3.5 describes the way the run-time loader locates and loads the shared object libraries for different compiler models (-o32, -n32, -64). It also says that you can force the run-time loader to look for your library using the LD_LIBRARY_PATH environment variable. Hope this helps, Mark -- Mark Dalphin email: mdalphin@amgen.com Mail Stop: 29-2-A phone: +1-805-447-4951 (work) One Amgen Center Drive +1-805-375-0680 (home) Thousand Oaks, CA 91320 fax: +1-805-499-9955 (work)
Mark Dalphin wrote: > It also says that you can force the run-time loader to look for your > library using the LD_LIBRARY_PATH environment variable. > > Hope this helps, > Mark Thanks Mark. I'll try adding the path to LD_LIBRARY_PATH and see what happens. -Tony
I wrote on July 28, 1999:
> > I am installing a client postgres on an SGI O2 (IRIX 6.5.4) using both
> > the 64 bit and -o32 bit libraries. The 64 bit works fine, but the -o32
> > bit library gives me this on execution of a C program :
> >
> > o21:reina::/database > TEST_SQL_PROGRAM
> > 65584:TEST_SQL_PROGRAM: rld: Fatal Error: Cannot Successfully map soname
> > 'libpq.so.2.0' under any of the filenames
> > /usr/local/pgsql/lib/libpq.so.2.0:/usr/local/matlab/extern/lib/sgi/libpq.so.2.0:
> /usr/lib/libpq.so.2.0:/usr/lib/internal/libpq.so.2.0:/lib/libpq.so.2.0:/lib/cmplrs/cc/libpq.so.2.0:
> /usr/lib/cmplrs/cc/libpq.so.2.0:/opt/lib/libpq.so.2.0:
Here's my update:
Okay I have figured out how to make this work but it is kludge. I simply copy the libpq.so.2.0 library into
/usr/lib(where the -o32 libraries reside for IRIX 6.5.4). For the -n32 version of postgres, I copy the libpq.so.2.0 (a
different one compiled for -n32) into /usr/lib32 (where the n-32 libraries reside for IRIX 6.5.4). For the 64 bit, do
thesame except it goes in /usr/lib64.
Note that for some reason I can't just link the libraries to those directories. They physically need to be copied
intothe directory in order to work.
What still doesn't make sense is why it is looking in the wrong places for the library. When I compile a C program
foruse with SQL, I specifically tell it where the include and library directories for Postgres are located:
cc -o32 test_sql_program.c -o TEST_SQL_PROGRAM -I/usr/local/pgsql_o32/include -L/usr/local/pgsql_o32/lib -lpq
It seems that this is the MIPSPro compilers fault and not Postgres'. But I thought that maybe someone else whos
compiledthe new Postgres on IRIX 6.5 has run into the same thing?
Thanks.
-Tony
Mark Dalphin wrote:
> I have not compiled for multiple modes, only -n32, but I have run into exactly the same problem. Version 6.4.2 seemed
toknow where to look for the shared object, but something has changed for 6.5.1. I am not sure what, though I have
> been looking. There is also more information about this under "man rld", but my reading of it suggests that your cc
line,above, should work. My current work around is to specify LD_LIBRARY_PATH when I start the postmaster. That
> won't help when compiling other programs, however, I think
>
Mark,
Yeah, from my understanding cc should know where to look for the libraries since I specify the correct place with
the-L option. It seems like cc isn't even recognizing that this option has been set.
The only difference I can see between Postgres 6.4.2 and 6.5.1 in this matter is that the library has changed from
libpq.ato libpq.so.2. For some reason I think that move from .a to .so has made the difference. Copying the
lipq.so.2 over to the /usr/lib32 directory will fix the bug (or at least I haven't found any problems with it so far).
But,I'd rather like to figure out specifically why this is occuring rather than kludging a work around.
Maybe between the two of us working on the problem we'll have a better chance of coming across the reason.
-Tony
Mark,
Okay, I think we're getting closer here. My co-worker, Dan, has figured out that if you move the lipq.so.'s out of
the/usr/local/pgsql/lib directory and into a sub-directory (call it libso, for example), the C programs will execute
fine. It looks like the C compiler is first looking to link the lipq.so.2 first when it really wants to get the libpq.a
file(or at least that's what we are guessing). So if the lipq.so.2 is moved from that directory, it by default
finds the .a file and works fine. The only problem now is that 'psql' wants to use the lipq.so.2 library and so it
won'twork. One step forward, two steps back ...
Does anyone know how to compile the 'psql' binary so that it wants to use lipq.a and not lipq.so.2?
-Tony
Hi,
Some time ago (Jul 30 for the contents of the letter copied below), there was some discussion about why release 6.5.1
ofPostgreSQL seemed to have a problem locating shared object libraries (DSOs) under IRIX 6.5. This problem seems to
have been introduced with the release of 6.5.1 and was not present in 6.4.2. What changed?
I have located a change that fixes the problem for me which involves a command line switch during compilation (ie on
the"cc" line, although the swich is actually passed to 'ld'.) which specifies to the dynamic loader, 'rld', where to
locate the particular shared object in question. The relevant section from the man page for 'ld' reads:
-rpath library_path
Adds the library_path to the search path for DSOs. Each
library path is appended to the list of directories at the
time the executable or DSO is loaded. This option directs
rld(5) to look in the named directories, but to look only
for DSOs, and to stop looking when the correct one is found.
This option can be specified only when the -shared or
-call_shared options are also in effect. For more
information, see the rld(5) man page. (C, C++, F77, F90)
A patch to 'Makefile.shlib' is supplied below:
*** Makefile.shlib.orig Mon Aug 30 11:00:23 1999
--- Makefile.shlib Mon Aug 30 11:01:47 1999
***************
*** 59,65 ****
ifeq ($(PORTNAME), irix5)
install-shlib-dep := install-shlib
shlib := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
! LDFLAGS_SL := -shared
CFLAGS += $(CFLAGS_SL)
endif
--- 59,65 ----
ifeq ($(PORTNAME), irix5)
install-shlib-dep := install-shlib
shlib := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
! LDFLAGS_SL := -shared -rpath $(LIBDIR)
CFLAGS += $(CFLAGS_SL)
endif
"G. Anthony Reina" wrote:
> Mark Dalphin wrote:
>
> > I have not compiled for multiple modes, only -n32, but I have run into exactly the same problem. Version 6.4.2
seemedto know where to look for the shared object, but something has changed for 6.5.1. I am not sure what, though I
have
> > been looking. There is also more information about this under "man rld", but my reading of it suggests that your
ccline, above, should work. My current work around is to specify LD_LIBRARY_PATH when I start the postmaster. That
> > won't help when compiling other programs, however, I think
> >
>
> Mark,
>
> Yeah, from my understanding cc should know where to look for the libraries since I specify the correct place with
the-L option. It seems like cc isn't even recognizing that this option has been set.
>
> The only difference I can see between Postgres 6.4.2 and 6.5.1 in this matter is that the library has changed
fromlibpq.a to libpq.so.2. For some reason I think that move from .a to .so has made the difference. Copying the
> lipq.so.2 over to the /usr/lib32 directory will fix the bug (or at least I haven't found any problems with it so
far).But, I'd rather like to figure out specifically why this is occuring rather than kludging a work around.
>
> Maybe between the two of us working on the problem we'll have a better chance of coming across the reason.
>
> -Tony
--
Mark Dalphin email: mdalphin@amgen.com
Mail Stop: 29-2-A phone: +1-805-447-4951 (work)
One Amgen Center Drive +1-805-375-0680 (home)
Thousand Oaks, CA 91320 fax: +1-805-499-9955 (work)
Mark Dalphin wrote: > A patch to 'Makefile.shlib' is supplied below: > > *** Makefile.shlib.orig Mon Aug 30 11:00:23 1999 > --- Makefile.shlib Mon Aug 30 11:01:47 1999 > *************** > *** 59,65 **** > ifeq ($(PORTNAME), irix5) > install-shlib-dep := install-shlib > shlib := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION) > ! LDFLAGS_SL := -shared > CFLAGS += $(CFLAGS_SL) > endif > > --- 59,65 ---- > ifeq ($(PORTNAME), irix5) > install-shlib-dep := install-shlib > shlib := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION) > ! LDFLAGS_SL := -shared -rpath $(LIBDIR) > CFLAGS += $(CFLAGS_SL) > endif > Thanks Mark. This makes sense. I ended up just linking and/or copying the libraries by hand. However, this solution seemslike it solves the heart of the glitch rather than just a simple patch. Hopefully, this can be added to 6.5.2 before it gets released (I think tomorrow). -Tony
Applied. > Hi, > > Some time ago (Jul 30 for the contents of the letter copied below), there was some discussion about why release 6.5.1 ofPostgreSQL seemed to have a problem locating shared object libraries (DSOs) under IRIX 6.5. This problem seems to > have been introduced with the release of 6.5.1 and was not present in 6.4.2. What changed? > > I have located a change that fixes the problem for me which involves a command line switch during compilation (ie on the"cc" line, although the swich is actually passed to 'ld'.) which specifies to the dynamic loader, 'rld', where to > locate the particular shared object in question. The relevant section from the man page for 'ld' reads: > > -rpath library_path > Adds the library_path to the search path for DSOs. Each > library path is appended to the list of directories at the > time the executable or DSO is loaded. This option directs > rld(5) to look in the named directories, but to look only > for DSOs, and to stop looking when the correct one is found. > > This option can be specified only when the -shared or > -call_shared options are also in effect. For more > information, see the rld(5) man page. (C, C++, F77, F90) > > A patch to 'Makefile.shlib' is supplied below: > > *** Makefile.shlib.orig Mon Aug 30 11:00:23 1999 > --- Makefile.shlib Mon Aug 30 11:01:47 1999 > *************** > *** 59,65 **** > ifeq ($(PORTNAME), irix5) > install-shlib-dep := install-shlib > shlib := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION) > ! LDFLAGS_SL := -shared > CFLAGS += $(CFLAGS_SL) > endif > > --- 59,65 ---- > ifeq ($(PORTNAME), irix5) > install-shlib-dep := install-shlib > shlib := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION) > ! LDFLAGS_SL := -shared -rpath $(LIBDIR) > CFLAGS += $(CFLAGS_SL) > endif > > "G. Anthony Reina" wrote: > > > Mark Dalphin wrote: > > > > > I have not compiled for multiple modes, only -n32, but I have run into exactly the same problem. Version 6.4.2 seemedto know where to look for the shared object, but something has changed for 6.5.1. I am not sure what, though I have > > > been looking. There is also more information about this under "man rld", but my reading of it suggests that your ccline, above, should work. My current work around is to specify LD_LIBRARY_PATH when I start the postmaster. That > > > won't help when compiling other programs, however, I think > > > > > > > Mark, > > > > Yeah, from my understanding cc should know where to look for the libraries since I specify the correct place withthe -L option. It seems like cc isn't even recognizing that this option has been set. > > > > The only difference I can see between Postgres 6.4.2 and 6.5.1 in this matter is that the library has changed fromlibpq.a to libpq.so.2. For some reason I think that move from .a to .so has made the difference. Copying the > > lipq.so.2 over to the /usr/lib32 directory will fix the bug (or at least I haven't found any problems with it so far).But, I'd rather like to figure out specifically why this is occuring rather than kludging a work around. > > > > Maybe between the two of us working on the problem we'll have a better chance of coming across the reason. > > > > -Tony > > -- > Mark Dalphin email: mdalphin@amgen.com > Mail Stop: 29-2-A phone: +1-805-447-4951 (work) > One Amgen Center Drive +1-805-375-0680 (home) > Thousand Oaks, CA 91320 fax: +1-805-499-9955 (work) > > > > > ************ > > -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026