Re: postgres 8.3.8 and Solaris 10_x86 64 bit problems?

So I compiled postgres with Solaris 10 and have problems running it.

# ./pg_ctl
ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
/usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
0xfffffd7fff1cf210 does not fit
Killed

# ldd pg_ctl
libpq.so.5 => /usr/local/postgres64/lib/libpq.so.5
libm.so.2 => /usr/lib/64/libm.so.2
libxml2.so.2 => /usr/lib/64/libxml2.so.2
libz.so.1 => /usr/lib/64/libz.so.1
libreadline.so.6 => /usr/local/lib/libreadline.so.6
libcurses.so.1 => /usr/lib/64/libcurses.so.1
librt.so.1 => /usr/lib/64/librt.so.1
libsocket.so.1 => /usr/lib/64/libsocket.so.1
libc.so.1 => /usr/lib/64/libc.so.1
libpthread.so.1 => /usr/lib/64/libpthread.so.1
libnsl.so.1 => /lib/64/libnsl.so.1
libgcc_s.so.1 => /usr/sfw/lib/amd64/libgcc_s.so.1
libaio.so.1 => /lib/64/libaio.so.1
libmd.so.1 => /lib/64/libmd.so.1
libmp.so.2 => /lib/64/libmp.so.2
libscf.so.1 => /lib/64/libscf.so.1
libdoor.so.1 => /lib/64/libdoor.so.1
libuutil.so.1 => /lib/64/libuutil.so.1
libgen.so.1 => /lib/64/libgen.so.1

# file /usr/local/postgres64/lib/libpq.so.5
/usr/local/postgres64/lib/libpq.so.5: ELF 64-bit LSB dynamic lib AMD64
Version 1 [SSE CMOV], dynamically linked, not stripped

What am I missing???

Here's my environment.

Solaris 10 x86_64 with postgres 8.3.8 and openssl 98k using gcc version
3.4.3 (csl-sol210-3_4-branch+sol_rpath)
, sunstudio12.1 and GNU Make 3.80

I've even monkied with LD_LIBRARY_PATH but getting the same issues.
Seems when I don't compile in openssl everything is fine.

Thanks!

u235sentinel wrote:
> So I compiled postgres with Solaris 10 and have problems running it.
>
> # ./pg_ctl
> ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
> /usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
> 0xfffffd7fff1cf210 does not fit
> Killed
>

Maybe libpq.so wasn't built with the PIC option (gcc -fPIC, sun compiler -Kpic).

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/

Andrew Chernow <ac(at)esilo(dot)com> writes:
> u235sentinel wrote:
>> So I compiled postgres with Solaris 10 and have problems running it.
>>
>> # ./pg_ctl
>> ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
>> /usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
>> 0xfffffd7fff1cf210 does not fit

> Maybe libpq.so wasn't built with the PIC option (gcc -fPIC, sun compiler -Kpic).

That is sort of what the error suggests, all right, but Makefile.solaris
has set up CFLAGS_SL that way for a long time. Perhaps CFLAGS_SL is
getting overridden from somewhere?

regards, tom lane

Andrew Chernow wrote:
> u235sentinel wrote:
>> So I compiled postgres with Solaris 10 and have problems running it.
>>
>> # ./pg_ctl
>> ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
>> /usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
>> 0xfffffd7fff1cf210 does not fit
>> Killed
>>
>
> Maybe libpq.so wasn't built with the PIC option (gcc -fPIC, sun
> compiler -Kpic).
>
I'll give that a shot. It's possible.

Thanks for the hint :D

You can look on
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=ghost_moth&dt=2009-10-07%2021:06:00

How it is built. You also does not needed own version of Openssl. All
security fixes are backported. It is located in /usr/sfw/lib or
/usr/sfw/lib/64

Sometimes are problem with gcc and solaris linker. IIRC, I had problem
with PLPerl compilation.

Zdenek

Dne 8.10.09 03:48, u235sentinel napsal(a):
> So I compiled postgres with Solaris 10 and have problems running it.
>
> # ./pg_ctl
> ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
> /usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
> 0xfffffd7fff1cf210 does not fit
> Killed
>
> # ldd pg_ctl
> libpq.so.5 => /usr/local/postgres64/lib/libpq.so.5
> libm.so.2 => /usr/lib/64/libm.so.2
> libxml2.so.2 => /usr/lib/64/libxml2.so.2
> libz.so.1 => /usr/lib/64/libz.so.1
> libreadline.so.6 => /usr/local/lib/libreadline.so.6
> libcurses.so.1 => /usr/lib/64/libcurses.so.1
> librt.so.1 => /usr/lib/64/librt.so.1
> libsocket.so.1 => /usr/lib/64/libsocket.so.1
> libc.so.1 => /usr/lib/64/libc.so.1
> libpthread.so.1 => /usr/lib/64/libpthread.so.1
> libnsl.so.1 => /lib/64/libnsl.so.1
> libgcc_s.so.1 => /usr/sfw/lib/amd64/libgcc_s.so.1
> libaio.so.1 => /lib/64/libaio.so.1
> libmd.so.1 => /lib/64/libmd.so.1
> libmp.so.2 => /lib/64/libmp.so.2
> libscf.so.1 => /lib/64/libscf.so.1
> libdoor.so.1 => /lib/64/libdoor.so.1
> libuutil.so.1 => /lib/64/libuutil.so.1
> libgen.so.1 => /lib/64/libgen.so.1
>
> # file /usr/local/postgres64/lib/libpq.so.5
> /usr/local/postgres64/lib/libpq.so.5: ELF 64-bit LSB dynamic lib AMD64
> Version 1 [SSE CMOV], dynamically linked, not stripped
>
>
> What am I missing???
>
> Here's my environment.
>
> Solaris 10 x86_64 with postgres 8.3.8 and openssl 98k using gcc version
> 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
> , sunstudio12.1 and GNU Make 3.80
>
> I've even monkied with LD_LIBRARY_PATH but getting the same issues.
> Seems when I don't compile in openssl everything is fine.
>
> Thanks!
>

Zdenek Kotala wrote:
> You can look on
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=ghost_moth&dt=2009-10-07%2021:06:00
>
>
> How it is built. You also does not needed own version of Openssl. All
> security fixes are backported. It is located in /usr/sfw/lib or
> /usr/sfw/lib/64
>
> Sometimes are problem with gcc and solaris linker. IIRC, I had problem
> with PLPerl compilation.
>
> Zdenek
>

Thanks for the note. I'll check it out in the morning.

thanks again!

Are you sure about this? When I try to build and don't have openssl in
the lib/include path it claims it needs it. As I'm building 64 bit I
can now build postgres in 64 bit with openssl 98k just fine. However
when I run it I'm getting the same error message.

I'm curious if this is a lost hope. My boss is recommending we flatten
the Sun box and install redhat linux (which I'm fine with). I'd rather
not as threading in Solaris is better.

Thoughts?

thanks

Zdenek Kotala wrote:
> You can look on
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=ghost_moth&dt=2009-10-07%2021:06:00
>
>
> How it is built. You also does not needed own version of Openssl. All
> security fixes are backported. It is located in /usr/sfw/lib or
> /usr/sfw/lib/64
>
> Sometimes are problem with gcc and solaris linker. IIRC, I had problem
> with PLPerl compilation.
>
> Zdenek
>
> Dne 8.10.09 03:48, u235sentinel napsal(a):
>> So I compiled postgres with Solaris 10 and have problems running it.
>>
>> # ./pg_ctl
>> ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
>> /usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
>> 0xfffffd7fff1cf210 does not fit
>> Killed
>>
>> # ldd pg_ctl
>> libpq.so.5 => /usr/local/postgres64/lib/libpq.so.5
>> libm.so.2 => /usr/lib/64/libm.so.2
>> libxml2.so.2 => /usr/lib/64/libxml2.so.2
>> libz.so.1 => /usr/lib/64/libz.so.1
>> libreadline.so.6 => /usr/local/lib/libreadline.so.6
>> libcurses.so.1 => /usr/lib/64/libcurses.so.1
>> librt.so.1 => /usr/lib/64/librt.so.1
>> libsocket.so.1 => /usr/lib/64/libsocket.so.1
>> libc.so.1 => /usr/lib/64/libc.so.1
>> libpthread.so.1 => /usr/lib/64/libpthread.so.1
>> libnsl.so.1 => /lib/64/libnsl.so.1
>> libgcc_s.so.1 => /usr/sfw/lib/amd64/libgcc_s.so.1
>> libaio.so.1 => /lib/64/libaio.so.1
>> libmd.so.1 => /lib/64/libmd.so.1
>> libmp.so.2 => /lib/64/libmp.so.2
>> libscf.so.1 => /lib/64/libscf.so.1
>> libdoor.so.1 => /lib/64/libdoor.so.1
>> libuutil.so.1 => /lib/64/libuutil.so.1
>> libgen.so.1 => /lib/64/libgen.so.1
>>
>> # file /usr/local/postgres64/lib/libpq.so.5
>> /usr/local/postgres64/lib/libpq.so.5: ELF 64-bit LSB dynamic lib
>> AMD64 Version 1 [SSE CMOV], dynamically linked, not stripped
>>
>>
>> What am I missing???
>>
>> Here's my environment.
>>
>> Solaris 10 x86_64 with postgres 8.3.8 and openssl 98k using gcc
>> version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
>> , sunstudio12.1 and GNU Make 3.80
>>
>> I've even monkied with LD_LIBRARY_PATH but getting the same issues.
>> Seems when I don't compile in openssl everything is fine.
>>
>> Thanks!
>>
>
>

> I'm curious if this is a lost hope. My boss is recommending we flatten
> the Sun box and install redhat linux (which I'm fine with). I'd rather
> not as threading in Solaris is better.

Maybe solaris threads were better 10-15 years ago, but I'm not convinced that is
still the case. Any data supporting that argument, solaris 10 threads vs. linux
2.6.11+ kernel (p)threads?

Another thing to consider in your decision is that Sun was just bought by
oracle, leaving the solaris road map up in the air. At least for me, Linux is a
bit more reassuring ... or freebsd.

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/

u235sentinel píše v ne 18. 10. 2009 v 17:50 -0600:
> Are you sure about this? When I try to build and don't have openssl in
> the lib/include path it claims it needs it. As I'm building 64 bit I
> can now build postgres in 64 bit with openssl 98k just fine. However
> when I run it I'm getting the same error message.

If you want to link against to builtin OpenSSL you need following setup:

./configure ...
--with-openssl --with-includes=/usr/sfw/include
--with-libs=/usr/lib/amd64:/usr/sfw/lib/amd64

and important is:

LD_OPTIONS="-R/usr/sfw/lib/amd64 -L/usr/sfw/lib/amd64"

Or if you don't need own compilation, you can use built-in PostgreSQL
8.3. It is located in /usr/postgres/8.3/bin or /usr/postgres/8.3/bin/64.
See man postgres_83 for details. Also you need to apply last patch
138827-05:

http://sunsolve.sun.com/search/document.do?assetkey=1-21-138827-05-1

Or if you still needs own compilation try to compile openssl 98k with
Sun Studio.

Or if you cannot compile it with Sun Studio, you can try -mimpure-text
gcc switch to compile OpenSSL. It is workaround for some kind of linking
issues.

Let me know it it helps Zdenek

> I'm curious if this is a lost hope. My boss is recommending we flatten
> the Sun box and install redhat linux (which I'm fine with). I'd rather
> not as threading in Solaris is better.
>
> Thoughts?
>
> thanks
>
>
> Zdenek Kotala wrote:
> > You can look on
> > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=ghost_moth&dt=2009-10-07%2021:06:00
> >
> >
> > How it is built. You also does not needed own version of Openssl. All
> > security fixes are backported. It is located in /usr/sfw/lib or
> > /usr/sfw/lib/64
> >
> > Sometimes are problem with gcc and solaris linker. IIRC, I had problem
> > with PLPerl compilation.
> >
> > Zdenek
> >
> > Dne 8.10.09 03:48, u235sentinel napsal(a):
> >> So I compiled postgres with Solaris 10 and have problems running it.
> >>
> >> # ./pg_ctl
> >> ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
> >> /usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
> >> 0xfffffd7fff1cf210 does not fit
> >> Killed
> >>
> >> # ldd pg_ctl
> >> libpq.so.5 => /usr/local/postgres64/lib/libpq.so.5
> >> libm.so.2 => /usr/lib/64/libm.so.2
> >> libxml2.so.2 => /usr/lib/64/libxml2.so.2
> >> libz.so.1 => /usr/lib/64/libz.so.1
> >> libreadline.so.6 => /usr/local/lib/libreadline.so.6
> >> libcurses.so.1 => /usr/lib/64/libcurses.so.1
> >> librt.so.1 => /usr/lib/64/librt.so.1
> >> libsocket.so.1 => /usr/lib/64/libsocket.so.1
> >> libc.so.1 => /usr/lib/64/libc.so.1
> >> libpthread.so.1 => /usr/lib/64/libpthread.so.1
> >> libnsl.so.1 => /lib/64/libnsl.so.1
> >> libgcc_s.so.1 => /usr/sfw/lib/amd64/libgcc_s.so.1
> >> libaio.so.1 => /lib/64/libaio.so.1
> >> libmd.so.1 => /lib/64/libmd.so.1
> >> libmp.so.2 => /lib/64/libmp.so.2
> >> libscf.so.1 => /lib/64/libscf.so.1
> >> libdoor.so.1 => /lib/64/libdoor.so.1
> >> libuutil.so.1 => /lib/64/libuutil.so.1
> >> libgen.so.1 => /lib/64/libgen.so.1
> >>
> >> # file /usr/local/postgres64/lib/libpq.so.5
> >> /usr/local/postgres64/lib/libpq.so.5: ELF 64-bit LSB dynamic lib
> >> AMD64 Version 1 [SSE CMOV], dynamically linked, not stripped
> >>
> >>
> >> What am I missing???
> >>
> >> Here's my environment.
> >>
> >> Solaris 10 x86_64 with postgres 8.3.8 and openssl 98k using gcc
> >> version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
> >> , sunstudio12.1 and GNU Make 3.80
> >>
> >> I've even monkied with LD_LIBRARY_PATH but getting the same issues.
> >> Seems when I don't compile in openssl everything is fine.
> >>
> >> Thanks!
> >>
> >
> >
>
>

Andrew Chernow píše v ne 18. 10. 2009 v 21:09 -0400:
> > I'm curious if this is a lost hope. My boss is recommending we flatten
> > the Sun box and install redhat linux (which I'm fine with). I'd rather
> > not as threading in Solaris is better.
>
> Maybe solaris threads were better 10-15 years ago, but I'm not convinced that is
> still the case. Any data supporting that argument, solaris 10 threads vs. linux
> 2.6.11+ kernel (p)threads?

I can point on this article:

http://tweakers.net/reviews/649/all/database-test-sun-ultrasparc-t1-vs-punt-amd-opteron.html

Zdenek

Zdenek Kotala wrote:
> Andrew Chernow píše v ne 18. 10. 2009 v 21:09 -0400:
>>> I'm curious if this is a lost hope. My boss is recommending we flatten
>>> the Sun box and install redhat linux (which I'm fine with). I'd rather
>>> not as threading in Solaris is better.
>> Maybe solaris threads were better 10-15 years ago, but I'm not convinced that is
>> still the case. Any data supporting that argument, solaris 10 threads vs. linux
>> 2.6.11+ kernel (p)threads?
>
> I can point on this article:
>
> http://tweakers.net/reviews/649/all/database-test-sun-ultrasparc-t1-vs-punt-amd-opteron.html
>
> Zdenek
>
>

For starters, the original poster is using AMD64, so whether an
ultrasparc improves thread performance is immaterial here.

OP said:
"Solaris 10 x86_64 with postgres 8.3.8 and openssl 98k using gcc version
3.4.3"

Although the article is interesting, the data came from (or passed
through) Sun employees. I'm not saying the article's claims are not
true or intentionally misleading, but rather that I am skeptical about
the findings; especially since it reads more like a marketing piece than
a technical analysis.

BTW, I have nothing against Sun or Solaris (spent a few years on Solaris
7 & 8 sparc servers a while back and found them quite stable). I'm just
a hard sell do to endless exaggerated claims by all the top vendors and
techy outlets. I find myself weeding through all the hype with a machete :)

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/

Zdenek Kotala wrote:
> I can point on this article:
>
> http://tweakers.net/reviews/649/all/database-test-sun-ultrasparc-t1-vs-punt-amd-opteron.html
>
> Zdenek
>
>
>
Ok so I'm checking everything in my environment. The system actually
builds postgres with openssl98k. Comes back and says it's ready to
install. I run 'make install' and try to run something like pg_ctl
again. Seem to be seeing the same results.

# file pg_ctl
pg_ctl: ELF 64-bit LSB executable AMD64 Version 1 [SSE FXSR CMOV
FPU], dynamically linked, not stripped

# ./pg_ctl
ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
/usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
0xfffffd7fff1cf210 does not fit
Killed

So I run 'ldd pg_ctl' to see if everything is linking ok.

libpq.so.5 => /usr/local/postgres64/lib/libpq.so.5
libm.so.2 => /usr/lib/64/libm.so.2
libxml2.so.2 => /usr/lib/64/libxml2.so.2
libz.so.1 => /usr/lib/64/libz.so.1
libreadline.so.6 => /usr/local/lib/libreadline.so.6
libcurses.so.1 => /usr/lib/64/libcurses.so.1
librt.so.1 => /usr/lib/64/librt.so.1
libsocket.so.1 => /usr/lib/64/libsocket.so.1
libc.so.1 => /usr/lib/64/libc.so.1
libpthread.so.1 => /usr/lib/64/libpthread.so.1
libnsl.so.1 => /lib/64/libnsl.so.1
libgcc_s.so.1 => /usr/sfw/lib/amd64/libgcc_s.so.1
libaio.so.1 => /lib/64/libaio.so.1
libmd.so.1 => /lib/64/libmd.so.1
libmp.so.2 => /lib/64/libmp.so.2
libscf.so.1 => /lib/64/libscf.so.1
libdoor.so.1 => /lib/64/libdoor.so.1
libuutil.so.1 => /lib/64/libuutil.so.1
libgen.so.1 => /lib/64/libgen.so.1

And I'm wondering if there is a problem with libpq.so.5 as mentioned in
the original error

# file /usr/local/postgres64/lib/libpq.so.5

/usr/local/postgres64/lib/libpq.so.5: ELF 64-bit LSB dynamic lib AMD64
Version 1 [SSE CMOV], dynamically linked, not stripped

Ok. So looking good. Maybe there is a library or header libpq needs
that I'm missing in 64 bit?

# ldd /usr/local/postgres64/lib/libpq.so.5
libsocket.so.1 => /usr/lib/64/libsocket.so.1
libpthread.so.1 => /usr/lib/64/libpthread.so.1
libc.so.1 => /usr/lib/64/libc.so.1
libnsl.so.1 => /lib/64/libnsl.so.1
libmp.so.2 => /lib/64/libmp.so.2
libmd.so.1 => /lib/64/libmd.so.1
libscf.so.1 => /lib/64/libscf.so.1
libdoor.so.1 => /lib/64/libdoor.so.1
libuutil.so.1 => /lib/64/libuutil.so.1
libgen.so.1 => /lib/64/libgen.so.1
libm.so.2 => /lib/64/libm.so.2

Looks good. I'm not sure where to go from here. I have everything else
I need built in 64 bit except for Postgres with ssl :/

I've spent the last few weeks googling and talking to people about it.
Not sure what I'm missing here.

Thanks!

> # ./pg_ctl
> ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
> /usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
> 0xfffffd7fff1cf210 does not fit
> Killed
>

"symbol (unknown)". Can you turn on debugging symbols? Knowing the
symbol may point to a library that was not compiled properly.

> So I run 'ldd pg_ctl' to see if everything is linking ok.
>
> And I'm wondering if there is a problem with libpq.so.5 as mentioned in
> the original error
>
> # file /usr/local/postgres64/lib/libpq.so.5
>
>
> /usr/local/postgres64/lib/libpq.so.5: ELF 64-bit LSB dynamic lib AMD64
> Version 1 [SSE CMOV], dynamically linked, not stripped
>
> Ok. So looking good. Maybe there is a library or header libpq needs
> that I'm missing in 64 bit?
>
> # ldd /usr/local/postgres64/lib/libpq.so.5

Are you sure that all pg_ctl referenced libraries and all libpq.so
referenced libraries were built as 64-bit using PIC? Are you linking
with any static library that may contain 32-bit objects? That error is
most commonly PIC or arch-mismatch.

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/

Andrew Chernow píše v po 19. 10. 2009 v 14:14 -0400:
> > # ./pg_ctl
> > ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
> > /usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
> > 0xfffffd7fff1cf210 does not fit
> > Killed
> >
>
> "symbol (unknown)". Can you turn on debugging symbols? Knowing the
> symbol may point to a library that was not compiled properly.

Also you can try to run
LD_DEBUG=basic ./pg_ctl

and also

elfdump <my local lib> | grep R_AMD64_32

it should show when symbols came from. By theway what S10 version do you
use?

ld -V and uname -a also helps.

> > So I run 'ldd pg_ctl' to see if everything is linking ok.
> >
> > And I'm wondering if there is a problem with libpq.so.5 as mentioned in
> > the original error
> >
> > # file /usr/local/postgres64/lib/libpq.so.5
> >
> >
> > /usr/local/postgres64/lib/libpq.so.5: ELF 64-bit LSB dynamic lib AMD64
> > Version 1 [SSE CMOV], dynamically linked, not stripped
> >
> > Ok. So looking good. Maybe there is a library or header libpq needs
> > that I'm missing in 64 bit?
> >
> > # ldd /usr/local/postgres64/lib/libpq.so.5
>
> Are you sure that all pg_ctl referenced libraries and all libpq.so
> referenced libraries were built as 64-bit using PIC? Are you linking
> with any static library that may contain 32-bit objects? That error is
> most commonly PIC or arch-mismatch.
>

Agree, I went through linker bugs and missing PIC is often root cause of
this problem. See

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6261066

Problem was that ./configure badly setup PIC switch on amd64 platform.

Please, could you compile pure postgreSQL without other own libraries
like readline and openssl? It should help to find which library is
culprit.

Zdenek

Zdenek Kotala wrote:
> Andrew Chernow píše v po 19. 10. 2009 v 14:14 -0400:
>
>>> # ./pg_ctl
>>> ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
>>> /usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
>>> 0xfffffd7fff1cf210 does not fit
>>> Killed
>>>
{snip}
>>> /usr/local/postgres64/lib/libpq.so.5: ELF 64-bit LSB dynamic lib AMD64
>>> Version 1 [SSE CMOV], dynamically linked, not stripped
>>>
>>> Ok. So looking good. Maybe there is a library or header libpq needs
>>> that I'm missing in 64 bit?
>>>
>>> # ldd /usr/local/postgres64/lib/libpq.so.5
>>>
>> Are you sure that all pg_ctl referenced libraries and all libpq.so
>> referenced libraries were built as 64-bit using PIC? Are you linking
>> with any static library that may contain 32-bit objects? That error is
>> most commonly PIC or arch-mismatch.
>>
>>
>
> Agree, I went through linker bugs and missing PIC is often root cause of
> this problem. See
>
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6261066
>
> Problem was that ./configure badly setup PIC switch on amd64 platform.
>
> Please, could you compile pure postgreSQL without other own libraries
> like readline and openssl? It should help to find which library is
> culprit.
>
> Zdenek
>
>
>
>
I really appreciate all the comments about this problem. I'm not a
developer but I've been around the block a few times here.

I "think" I have it working now. At least it compiled and I was able to
run initdb, pg_ctl and psql to login to my new test database. All in 64
bit with openssl compiled in.

How I did it.

I've been SO focued on postgres thinking it was the entire problem that
I forgot about ssl. Even though openssl compiled just fine, it
contributed to the problem. After recompiling it with gcc and using
-fpic and -m64 I recompiled postgres also with -fpic and -m64. Seems
that was the magic sauce here.

Now I'm running and will add a few more things in like readline. The
goal is to build plr and plperl and load them into postgres.

Crossing my fingers those will go smoother.

Thanks a bunch!!

u235sentinel píše v út 20. 10. 2009 v 12:22 -0600:
> Now I'm running and will add a few more things in like readline. The
> goal is to build plr and plperl and load them into postgres.

Hmm, I'm afraid that 64bit plperl is a problem. Solaris 10 is not
shipped with 64bit perl :(.

Zdenek

Zdenek Kotala wrote:
> Hmm, I'm afraid that 64bit plperl is a problem. Solaris 10 is not
> shipped with 64bit perl :(.
>
> Zdenek
>
>
Found that the hard way today :-)

I'm downloading perl source and will make a 64 bit version. Anybody
know if -m64 will work with compiling 64 bit perl?

:-)

I'll hack the makefile and give it a shot.
Thanks!

> I'll hack the makefile and give it a shot.

No need to hack it, set CFLAGS during configure:

shell]# CFLAGS="-m64" ./configure (options)

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/

Andrew Chernow wrote:
>> I'll hack the makefile and give it a shot.
>
> No need to hack it, set CFLAGS during configure:
>
> shell]# CFLAGS="-m64" ./configure (options)
>
I tried that and it still built a 32 bit version of perl. When I
checked the make file it didn't have CFLAGS anywhere. I manually added
it but seems to be ignoring it. I'm regretting going with Solaris. I
don't recall it being this difficult to work with.

perhaps I can do something like CC="cc -m64" ./configure (options)

I'll have to play with that. Very weird :-)

Thanks