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

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 decibel@decibel.org
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

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 majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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 majordomo@postgresql.org

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_...-05%2022:03:35
--
Jim C. Nasby, Database Consultant decibel@decibel.org
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

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_...-05%2022:03:35
>
>

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

http://www.postgresql.org/docs/faq

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 majordomo@postgresql.org
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (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

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

Andrew Dunstan <andrew@dunslane.net> 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

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> 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