Re: [PATCHES] HEAD doesn't cope with libraries in non-default

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] HEAD doesn't cope with libraries in non-default

Peter Eisentraut-2
Andrew Dunstan wrote:
> I was also slightly dubious about it. However, we do still need to
> solve the problem that the patch addressed. Buildfarm members
> platypus and cuckoo are currently failing because dblink is picking
> up the wrong libpq (and it appears that incorrect libraries are also
> being picked up in the ecpg libraries, although this isn't causing a
> buildfarm failure.)

We have four pieces of information when linking a shared library:

B: in-tree libraries that we might need (in case of ecpglib: libpq)
A: path to those in-tree libraries
D: external libraries that we might need (in case of ecpglib in my case:
-lcrypt -lm)
C: path to those external libraries (e.g., /usr/local/lib)

On the linker command line, we need this information in one of the
following two orders:

A B C D
A C B D

The Makefile.shlib receives from the respective main makefile "A B D" in
SHLIB_LINK and would have to insert "C" in the middle somewhere.  
Currently, the actual behavior is "C A B D" and the failed patch wanted
to do "A B D C", both of which are wrong.

So either we code up some intelligence to put the "C" in the right
position or we have to pass down "A B" and "D" separately from the main
makefile.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] HEAD doesn't cope with libraries in non-default

Decibel!
On Mon, Jul 04, 2005 at 05:58:27PM +0200, Peter Eisentraut wrote:

> Andrew Dunstan wrote:
> > I was also slightly dubious about it. However, we do still need to
> > solve the problem that the patch addressed. Buildfarm members
> > platypus and cuckoo are currently failing because dblink is picking
> > up the wrong libpq (and it appears that incorrect libraries are also
> > being picked up in the ecpg libraries, although this isn't causing a
> > buildfarm failure.)
>
> We have four pieces of information when linking a shared library:
>
> B: in-tree libraries that we might need (in case of ecpglib: libpq)
> A: path to those in-tree libraries

Is A even represented in the build at all right now? ISTM it's not, so
simply adding it in front of C might suffice. What would be a reasonable
way to add that to the makefiles?

> D: external libraries that we might need (in case of ecpglib in my case:
> -lcrypt -lm)
> C: path to those external libraries (e.g., /usr/local/lib)
>
> On the linker command line, we need this information in one of the
> following two orders:
>
> A B C D
> A C B D
>
> The Makefile.shlib receives from the respective main makefile "A B D" in
> SHLIB_LINK and would have to insert "C" in the middle somewhere.  
> Currently, the actual behavior is "C A B D" and the failed patch wanted
> to do "A B D C", both of which are wrong.
>
> So either we code up some intelligence to put the "C" in the right
> position or we have to pass down "A B" and "D" separately from the main
> makefile.
>
> --
> Peter Eisentraut
> http://developer.postgresql.org/~petere/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>

--
Jim C. Nasby, Database Consultant               [hidden email]
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] HEAD doesn't cope with libraries in non-default

Peter Eisentraut-2
Jim C. Nasby wrote:
> > B: in-tree libraries that we might need (in case of ecpglib: libpq)
> > A: path to those in-tree libraries
>
> Is A even represented in the build at all right now? ISTM it's not,

Sure it is.  How else would anything like psql and pg_dump find libpq?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [hidden email] so that your
       message can get through to the mailing list cleanly
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] HEAD doesn't cope with libraries in non-default

Peter Eisentraut-2
In reply to this post by Peter Eisentraut-2
I wrote:
> So either we code up some intelligence to put the "C" in the right
> position or we have to pass down "A B" and "D" separately from the
> main makefile.

The following patch might just do the former.  Please try it out.


diff -ur ../cvs-pgsql/src/Makefile.shlib ./src/Makefile.shlib
--- ../cvs-pgsql/src/Makefile.shlib     2005-07-04 16:32:57.000000000 +0200
+++ ./src/Makefile.shlib        2005-07-05 22:02:10.556162778 +0200
@@ -240,7 +240,7 @@
   SHLIB_LINK           += -ltermcap -lstdc++.r4 -lbind -lsocket -L/boot/develop/lib/x86
 endif

-SHLIB_LINK := $(filter -L%, $(LDFLAGS)) $(SHLIB_LINK)
+SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFLAGS)) $(filter-out -L%, $(SHLIB_LINK))
 ifeq ($(enable_rpath), yes)
 SHLIB_LINK += $(rpath)
 endif


--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] HEAD doesn't cope with libraries in non-default

Decibel!
On Tue, Jul 05, 2005 at 10:09:19PM +0200, Peter Eisentraut wrote:

> I wrote:
> > So either we code up some intelligence to put the "C" in the right
> > position or we have to pass down "A B" and "D" separately from the
> > main makefile.
>
> The following patch might just do the former.  Please try it out.
>
>
> diff -ur ../cvs-pgsql/src/Makefile.shlib ./src/Makefile.shlib
> --- ../cvs-pgsql/src/Makefile.shlib     2005-07-04 16:32:57.000000000 +0200
> +++ ./src/Makefile.shlib        2005-07-05 22:02:10.556162778 +0200
> @@ -240,7 +240,7 @@
>    SHLIB_LINK           += -ltermcap -lstdc++.r4 -lbind -lsocket -L/boot/develop/lib/x86
>  endif
>
> -SHLIB_LINK := $(filter -L%, $(LDFLAGS)) $(SHLIB_LINK)
> +SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFLAGS)) $(filter-out -L%, $(SHLIB_LINK))
>  ifeq ($(enable_rpath), yes)
>  SHLIB_LINK += $(rpath)
>  endif

Worked on platypus:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2005-07-05%2022:03:35
--
Jim C. Nasby, Database Consultant               [hidden email]
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] HEAD doesn't cope with libraries in non-default

Andrew Dunstan

Could we please get this patch applied? It seems like the right thing to do.

cheers

andrew

Jim C. Nasby wrote:

>On Tue, Jul 05, 2005 at 10:09:19PM +0200, Peter Eisentraut wrote:
>  
>
>>I wrote:
>>    
>>
>>>So either we code up some intelligence to put the "C" in the right
>>>position or we have to pass down "A B" and "D" separately from the
>>>main makefile.
>>>      
>>>
>>The following patch might just do the former.  Please try it out.
>>
>>
>>diff -ur ../cvs-pgsql/src/Makefile.shlib ./src/Makefile.shlib
>>--- ../cvs-pgsql/src/Makefile.shlib     2005-07-04 16:32:57.000000000 +0200
>>+++ ./src/Makefile.shlib        2005-07-05 22:02:10.556162778 +0200
>>@@ -240,7 +240,7 @@
>>   SHLIB_LINK           += -ltermcap -lstdc++.r4 -lbind -lsocket -L/boot/develop/lib/x86
>> endif
>>
>>-SHLIB_LINK := $(filter -L%, $(LDFLAGS)) $(SHLIB_LINK)
>>+SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFLAGS)) $(filter-out -L%, $(SHLIB_LINK))
>> ifeq ($(enable_rpath), yes)
>> SHLIB_LINK += $(rpath)
>> endif
>>    
>>
>
>Worked on platypus:
>http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2005-07-05%2022:03:35
>  
>

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] HEAD doesn't cope with libraries in non-default

Bruce Momjian-2
In reply to this post by Peter Eisentraut-2


Patch applied.  Thanks.

---------------------------------------------------------------------------


Peter Eisentraut wrote:

> I wrote:
> > So either we code up some intelligence to put the "C" in the right
> > position or we have to pass down "A B" and "D" separately from the
> > main makefile.
>
> The following patch might just do the former.  Please try it out.
>
>
> diff -ur ../cvs-pgsql/src/Makefile.shlib ./src/Makefile.shlib
> --- ../cvs-pgsql/src/Makefile.shlib     2005-07-04 16:32:57.000000000 +0200
> +++ ./src/Makefile.shlib        2005-07-05 22:02:10.556162778 +0200
> @@ -240,7 +240,7 @@
>    SHLIB_LINK           += -ltermcap -lstdc++.r4 -lbind -lsocket -L/boot/develop/lib/x86
>  endif
>
> -SHLIB_LINK := $(filter -L%, $(LDFLAGS)) $(SHLIB_LINK)
> +SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFLAGS)) $(filter-out -L%, $(SHLIB_LINK))
>  ifeq ($(enable_rpath), yes)
>  SHLIB_LINK += $(rpath)
>  endif
>
>
> --
> Peter Eisentraut
> http://developer.postgresql.org/~petere/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to [hidden email]
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  [hidden email]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] HEAD doesn't cope with libraries in non-default

Andrew Dunstan

This patch seems to have broken builds on Windows and other boxes (e.g.
buildfarm's octopus, a FreeBSD box). Maybe this should be reverted until
we find a more robust solution :-(

cheers

andrew

Bruce Momjian wrote:

>Patch applied.  Thanks.
>
>---------------------------------------------------------------------------
>
>
>Peter Eisentraut wrote:
>  
>
>>I wrote:
>>    
>>
>>>So either we code up some intelligence to put the "C" in the right
>>>position or we have to pass down "A B" and "D" separately from the
>>>main makefile.
>>>      
>>>
>>The following patch might just do the former.  Please try it out.
>>
>>
>>diff -ur ../cvs-pgsql/src/Makefile.shlib ./src/Makefile.shlib
>>--- ../cvs-pgsql/src/Makefile.shlib     2005-07-04 16:32:57.000000000 +0200
>>+++ ./src/Makefile.shlib        2005-07-05 22:02:10.556162778 +0200
>>@@ -240,7 +240,7 @@
>>   SHLIB_LINK           += -ltermcap -lstdc++.r4 -lbind -lsocket -L/boot/develop/lib/x86
>> endif
>>
>>-SHLIB_LINK := $(filter -L%, $(LDFLAGS)) $(SHLIB_LINK)
>>+SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFLAGS)) $(filter-out -L%, $(SHLIB_LINK))
>> ifeq ($(enable_rpath), yes)
>> SHLIB_LINK += $(rpath)
>> endif
>>    
>>

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] HEAD doesn't cope with libraries in non-default

Tom Lane-2
Andrew Dunstan <[hidden email]> writes:
> This patch seems to have broken builds on Windows and other boxes (e.g.
> buildfarm's octopus, a FreeBSD box). Maybe this should be reverted until
> we find a more robust solution :-(

The only thing I see any evidence for is a broken version of gmake on
octopus.

gmake[3]: Entering directory `/raid0/buildfarm/buildfarm/HEAD/pgsql.54583/src/backend/utils/mb/conversion_procs/ascii_and_mic'
../../../../../../src/Makefile.shlib:250: *** missing separator.  Stop.
gmake[3]: Leaving directory `/raid0/buildfarm/buildfarm/HEAD/pgsql.54583/src/backend/utils/mb/conversion_procs/ascii_and_mic'
gmake[2]: *** [all] Error 2

If there were a genuine syntax error in that command, we'd all be seeing
this.

What gmake version is octopus using, anyway?

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] HEAD doesn't cope with libraries in non-default

Andrew Dunstan


Tom Lane wrote:

>Andrew Dunstan <[hidden email]> writes:
>  
>
>>This patch seems to have broken builds on Windows and other boxes (e.g.
>>buildfarm's octopus, a FreeBSD box). Maybe this should be reverted until
>>we find a more robust solution :-(
>>    
>>
>
>The only thing I see any evidence for is a broken version of gmake on
>octopus.
>
>gmake[3]: Entering directory `/raid0/buildfarm/buildfarm/HEAD/pgsql.54583/src/backend/utils/mb/conversion_procs/ascii_and_mic'
>../../../../../../src/Makefile.shlib:250: *** missing separator.  Stop.
>gmake[3]: Leaving directory `/raid0/buildfarm/buildfarm/HEAD/pgsql.54583/src/backend/utils/mb/conversion_procs/ascii_and_mic'
>gmake[2]: *** [all] Error 2
>
>If there were a genuine syntax error in that command, we'd all be seeing
>this.
>
>What gmake version is octopus using, anyway?
>  
>

I wondered about that. Certainly the compiler is very old indeed.

Jim?

Meanwhile,  we are now choking on building plperl for Windows, at least
with the ActiveState perl port, where we were not before.
Makefile.global gets these settings:

PERL            = "/c/perl/bin//perl"
perl_archlibexp     = C:\Perl\lib
perl_privlibexp     = C:\Perl\lib
perl_useshrplib     = yes
perl_embed_ldflags  =  -nologo -nodefaultlib -debug -opt:ref,icf  
-libpath:"C:\Perl\lib\CORE"  -machine:x86  C:\Perl\lib\CORE\perl58.lib


and we see this error:

dllwrap  -o libplperl.dll --dllname libplperl.dll  --def plperl.def plperl.o spi_internal.o SPI.o -L -L../../../src/backend -L../../../src/port -L/c/tcl/lib C:/Perl/lib/CORE -lperl58 -lpostgres
c:\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3\..\..\..\..\mingw32\bin\ld.exe: cannot open C:/Perl/lib/CORE: Permission denied
c:\mingw\bin\dllwrap.exe: c:\mingw\bin\gcc exited with status 1

which looks very odd indeed, especially:

  -L -L../../../src/backend -L../../../src/port -L/c/tcl/lib C:/Perl/lib/CORE -lperl58


cheers

andrew










---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] HEAD doesn't cope with libraries in non-default

Tom Lane-2
Andrew Dunstan <[hidden email]> writes:
> which looks very odd indeed, especially:

>   -L -L../../../src/backend -L../../../src/port -L/c/tcl/lib C:/Perl/lib/CORE -lperl58

Ah, I see the problem:

ifeq ($(PORTNAME), win32)
perl_archlibexp := $(subst \,/,$(perl_archlibexp))
perl_privlibexp := $(subst \,/,$(perl_privlibexp))
perl_embed_ldflags := -L $(perl_archlibexp)/CORE -lperl58
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
override CPPFLAGS += -DPLPERL_HAVE_UID_GID
endif

The filter hack depends on -L and the following argument to not be
space-separated.  We made the no-space assumption before for -L in
LDFLAGS, but not for -L in SHLIB_LINK.

I've removed the space in CVS tip, we'll see where that takes us.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] HEAD doesn't cope with libraries in non-default

Andrew Dunstan
In reply to this post by Bruce Momjian-2


Jim C. Nasby wrote:

>Turns out there was a cvs conflict. Doh!
>  
>

Ouch. I have repeatedly warned buildfarm owners not to make any changes
or run builds in buildfarm's local CVS repo. Use a copy if necessary.

>Hmm... would probably be a good idea to have the script check for
>conflicts and throw a CVS error if it finds any. Here's what CVS does on
>a conflict:
>
>RCS file: /projects/cvsroot/pgsql/src/Makefile.shlib,v
>retrieving revision 1.93
>retrieving revision 1.94
>Merging differences between 1.93 and 1.94 into Makefile.shlib
>rcsmerge: warning: conflicts during merge
>cvs update: conflicts found in Makefile.shlib
>C Makefile.shlib
>
>It also creates a .# file. I'm not really sure what the best way to test
>for this would be.
>  
>

I can look for it. It's a pity that cvs doesn't exit with a non-zero
status when it does this. I am assuming we don't ever have such files in
CVS.

>BTW, it would probably be handy to have logs available for all steps of
>the build, even if they succeed.
>  
>

They are available locally in the directory lastrun-logs. I made a
deliberate decision not to clog up the server with them. At roughly 1Mb
per build it seemed quite unnecessary - I wanted to keep traffic down
and server storage requirements modest.

>In any case, I've cleared the conflict and I'm running a build right
>now.
>
>  
>
>

OK, cool.


cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
Reply | Threaded
Open this post in threaded view
|

pthread stack on FreeBSD WAS: HEAD doesn't cope with libraries in non-default

Decibel!
On Wed, Jul 13, 2005 at 01:24:17PM -0400, Andrew Dunstan wrote:
> >In any case, I've cleared the conflict and I'm running a build right
> >now.

octopus is building again, and is back to the behavior I mentioned in
http://archives.postgresql.org/pgsql-bugs/2005-07/msg00096.php. Is this
something that should be fixed in code? There are two patches in the
FreeBSD ports tree for postgresql 8:

decibel@flake.2[14:18]/usr/ports/databases/postgresql80-server/files:47>cat patch-plpython-Makefile patch-src-makefiles-Makefile.freebsd
--- src/pl/plpython/Makefile.orig       Fri Nov 19 20:23:01 2004
+++ src/pl/plpython/Makefile    Tue Dec 28 23:32:16 2004
@@ -9,7 +9,7 @@
 # shared library.  Since there is no official way to determine this
 # (at least not in pre-2.3 Python), we see if there is a file that is
 # named like a shared library.
-ifneq (,$(wildcard $(python_libdir)/libpython*$(DLSUFFIX)*))
+ifneq (,$(wildcard $(python_libdir)/../../libpython*$(DLSUFFIX)*))
 shared_libpython = yes
 endif
 
--- src/makefiles/Makefile.freebsd.orig Fri Nov 19 01:41:39 2004
+++ src/makefiles/Makefile.freebsd      Tue Dec 21 02:44:09 2004
@@ -11,7 +11,7 @@
 ifeq ($(findstring sparc,$(host_cpu)), sparc)
 CFLAGS_SL = -fPIC -DPIC
 else
-CFLAGS_SL = -fpic -DPIC
+CFLAGS_SL = -fPIC -DPIC
 endif
 
 
@@ -29,3 +29,5 @@
 endif
 
 sqlmansect = 7
+
+allow_nonpic_in_shlib = yes

The first of these patches makes me think that octopus might actually be
finding the wrong library, though things are fine on platypus with
python 2.3 (octopus is running 2.4).

I'm upgrading platypus to 2.4 right now to see what that changes, if
anything.
--
Jim C. Nasby, Database Consultant               [hidden email]
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] HEAD doesn't cope with libraries in non-default

Andrew Dunstan
In reply to this post by Tom Lane-2


Tom Lane wrote:

>Andrew Dunstan <[hidden email]> writes:
>  
>
>>which looks very odd indeed, especially:
>>    
>>
>
>  
>
>>  -L -L../../../src/backend -L../../../src/port -L/c/tcl/lib C:/Perl/lib/CORE -lperl58
>>    
>>
>
>Ah, I see the problem:
>
>ifeq ($(PORTNAME), win32)
>perl_archlibexp := $(subst \,/,$(perl_archlibexp))
>perl_privlibexp := $(subst \,/,$(perl_privlibexp))
>perl_embed_ldflags := -L $(perl_archlibexp)/CORE -lperl58
>                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
>override CPPFLAGS += -DPLPERL_HAVE_UID_GID
>endif
>
>The filter hack depends on -L and the following argument to not be
>space-separated.  We made the no-space assumption before for -L in
>LDFLAGS, but not for -L in SHLIB_LINK.
>
>I've removed the space in CVS tip, we'll see where that takes us.
>
>
>  
>

Seems to have done the trick on Windows. I think this stuff is now fixed
- thanks for your help.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
Reply | Threaded
Open this post in threaded view
|

Re: pthread stack on FreeBSD WAS: HEAD doesn't cope with libraries

Bruce Momjian-2
In reply to this post by Decibel!

Patch applied.  Thanks.  If we made plpython worse, we will hear about
it soon enough.  The freebsd-specific changes seem safe, considering
they came from the FreeBSD port maintainers themselves.

---------------------------------------------------------------------------


Jim C. Nasby wrote:

> On Wed, Jul 13, 2005 at 01:24:17PM -0400, Andrew Dunstan wrote:
> > >In any case, I've cleared the conflict and I'm running a build right
> > >now.
>
> octopus is building again, and is back to the behavior I mentioned in
> http://archives.postgresql.org/pgsql-bugs/2005-07/msg00096.php. Is this
> something that should be fixed in code? There are two patches in the
> FreeBSD ports tree for postgresql 8:
>
> decibel@flake.2[14:18]/usr/ports/databases/postgresql80-server/files:47>cat patch-plpython-Makefile patch-src-makefiles-Makefile.freebsd
> --- src/pl/plpython/Makefile.orig       Fri Nov 19 20:23:01 2004
> +++ src/pl/plpython/Makefile    Tue Dec 28 23:32:16 2004
> @@ -9,7 +9,7 @@
>  # shared library.  Since there is no official way to determine this
>  # (at least not in pre-2.3 Python), we see if there is a file that is
>  # named like a shared library.
> -ifneq (,$(wildcard $(python_libdir)/libpython*$(DLSUFFIX)*))
> +ifneq (,$(wildcard $(python_libdir)/../../libpython*$(DLSUFFIX)*))
>  shared_libpython = yes
>  endif
>  
> --- src/makefiles/Makefile.freebsd.orig Fri Nov 19 01:41:39 2004
> +++ src/makefiles/Makefile.freebsd      Tue Dec 21 02:44:09 2004
> @@ -11,7 +11,7 @@
>  ifeq ($(findstring sparc,$(host_cpu)), sparc)
>  CFLAGS_SL = -fPIC -DPIC
>  else
> -CFLAGS_SL = -fpic -DPIC
> +CFLAGS_SL = -fPIC -DPIC
>  endif
>  
>  
> @@ -29,3 +29,5 @@
>  endif
>  
>  sqlmansect = 7
> +
> +allow_nonpic_in_shlib = yes
>
> The first of these patches makes me think that octopus might actually be
> finding the wrong library, though things are fine on platypus with
> python 2.3 (octopus is running 2.4).
>
> I'm upgrading platypus to 2.4 right now to see what that changes, if
> anything.
> --
> Jim C. Nasby, Database Consultant               [hidden email]
> Give your computer some brain candy! www.distributed.net Team #1828
>
> Windows: "Where do you want to go today?"
> Linux: "Where do you want to go tomorrow?"
> FreeBSD: "Are you guys coming, or what?"
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  [hidden email]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [hidden email] so that your
       message can get through to the mailing list cleanly
Reply | Threaded
Open this post in threaded view
|

Re: pthread stack on FreeBSD WAS: HEAD doesn't cope with libraries

Tom Lane-2
Bruce Momjian <[hidden email]> writes:
> Patch applied.  Thanks.  If we made plpython worse, we will hear about
> it soon enough.

You did, and you're hearing about it.  Please revert the
plpython/Makefile change; it is certainly wrong for every other
platform.  What's more, it's unnecessary given the port makefile
change --- if you have allow_nonpic_in_shlib, it doesn't matter
whether shared_libpython gets set.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
Reply | Threaded
Open this post in threaded view
|

Re: pthread stack on FreeBSD WAS: HEAD doesn't cope with libraries

Bruce Momjian-2
Tom Lane wrote:
> Bruce Momjian <[hidden email]> writes:
> > Patch applied.  Thanks.  If we made plpython worse, we will hear about
> > it soon enough.
>
> You did, and you're hearing about it.  Please revert the
> plpython/Makefile change; it is certainly wrong for every other
> platform.  What's more, it's unnecessary given the port makefile
> change --- if you have allow_nonpic_in_shlib, it doesn't matter
> whether shared_libpython gets set.

OK, backed out.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  [hidden email]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [hidden email] so that your
       message can get through to the mailing list cleanly
Reply | Threaded
Open this post in threaded view
|

Re: pthread stack on FreeBSD WAS: HEAD doesn't cope with libraries in non-default

Jim C. Nasby
In reply to this post by Bruce Momjian-2
Unfortunately, it looks like the allow_non_pic_in_shlib setting broke
platypus: http://lnk.nu/pgbuildfarm.org/3l3.pl

If I back that part of the patch out, playtypus works fine.

On Fri, Aug 12, 2005 at 04:57:58PM -0400, Bruce Momjian wrote:

>
> Patch applied.  Thanks.  If we made plpython worse, we will hear about
> it soon enough.  The freebsd-specific changes seem safe, considering
> they came from the FreeBSD port maintainers themselves.
>
> ---------------------------------------------------------------------------
>
>
> Jim C. Nasby wrote:
> > On Wed, Jul 13, 2005 at 01:24:17PM -0400, Andrew Dunstan wrote:
> > > >In any case, I've cleared the conflict and I'm running a build right
> > > >now.
> >
> > octopus is building again, and is back to the behavior I mentioned in
> > http://archives.postgresql.org/pgsql-bugs/2005-07/msg00096.php. Is this
> > something that should be fixed in code? There are two patches in the
> > FreeBSD ports tree for postgresql 8:
> >
> > decibel@flake.2[14:18]/usr/ports/databases/postgresql80-server/files:47>cat patch-plpython-Makefile patch-src-makefiles-Makefile.freebsd
> > --- src/pl/plpython/Makefile.orig       Fri Nov 19 20:23:01 2004
> > +++ src/pl/plpython/Makefile    Tue Dec 28 23:32:16 2004
> > @@ -9,7 +9,7 @@
> >  # shared library.  Since there is no official way to determine this
> >  # (at least not in pre-2.3 Python), we see if there is a file that is
> >  # named like a shared library.
> > -ifneq (,$(wildcard $(python_libdir)/libpython*$(DLSUFFIX)*))
> > +ifneq (,$(wildcard $(python_libdir)/../../libpython*$(DLSUFFIX)*))
> >  shared_libpython = yes
> >  endif
> >  
> > --- src/makefiles/Makefile.freebsd.orig Fri Nov 19 01:41:39 2004
> > +++ src/makefiles/Makefile.freebsd      Tue Dec 21 02:44:09 2004
> > @@ -11,7 +11,7 @@
> >  ifeq ($(findstring sparc,$(host_cpu)), sparc)
> >  CFLAGS_SL = -fPIC -DPIC
> >  else
> > -CFLAGS_SL = -fpic -DPIC
> > +CFLAGS_SL = -fPIC -DPIC
> >  endif
> >  
> >  
> > @@ -29,3 +29,5 @@
> >  endif
> >  
> >  sqlmansect = 7
> > +
> > +allow_nonpic_in_shlib = yes
> >
> > The first of these patches makes me think that octopus might actually be
> > finding the wrong library, though things are fine on platypus with
> > python 2.3 (octopus is running 2.4).
> >
> > I'm upgrading platypus to 2.4 right now to see what that changes, if
> > anything.
> > --
> > Jim C. Nasby, Database Consultant               [hidden email]
> > Give your computer some brain candy! www.distributed.net Team #1828
> >
> > Windows: "Where do you want to go today?"
> > Linux: "Where do you want to go tomorrow?"
> > FreeBSD: "Are you guys coming, or what?"
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: Don't 'kill -9' the postmaster
> >
>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   [hidden email]               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
>

--
Jim C. Nasby, Sr. Engineering Consultant      [hidden email]
Pervasive Software        http://pervasive.com        512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
Reply | Threaded
Open this post in threaded view
|

Re: pthread stack on FreeBSD WAS: HEAD doesn't cope with libraries in non-default

Tom Lane-2
"Jim C. Nasby" <[hidden email]> writes:
> Unfortunately, it looks like the allow_non_pic_in_shlib setting broke
> platypus: http://lnk.nu/pgbuildfarm.org/3l3.pl

> If I back that part of the patch out, playtypus works fine.

So what's different between platypus and the machines where it works?
We might need a version check or something ...

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match
Reply | Threaded
Open this post in threaded view
|

Re: pthread stack on FreeBSD WAS: HEAD doesn't cope with libraries

jlam-2
Tom Lane wrote:

> "Jim C. Nasby" <[hidden email]> writes:
>
>>Unfortunately, it looks like the allow_non_pic_in_shlib setting broke
>>platypus: http://lnk.nu/pgbuildfarm.org/3l3.pl
>
>
>>If I back that part of the patch out, playtypus works fine.
>
>
> So what's different between platypus and the machines where it works?
> We might need a version check or something ...

platypus is amd64, not x86.  AFAIK, amd64 does not allow non-PIC code to
be mixed with PIC code in the same object, whereas it's just fine for
x86.  In NetBSD pkgsrc, we've had to fix a lot of software that makes
this same assumption.

        Cheers,

        -- Johnny Lam <[hidden email]>

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
12