Thread: 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@esilo.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