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

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)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