Tom,
Along with TCHSH that should reference the tclsh executable and should be TCLSH=/c/Tcl.8.5.18.0/bin/tclsh85.exe, the problem ended up being that the EnterpriseDB LanguagePack file
C:\EnterpriseDB\LanguagePack\9.5\x64\Tcl-8.5\lib\tclConfig.sh
has the has the hard-coded written line ...
TCL_LIB_SPEC = C:\EnterpriseDB\LanguagePack\9.5\x64\Tcl-8.5\lib\tcl85.lib
Looking at the results of
make -n -C tcl all 2>&1 | tee ../../make_n_C_tcl_all_ALONE.txt
I see
TCL_LIB_SPEC = C:\EnterpriseDB\LanguagePack\9.5\x64\Tcl-8.5\lib\tcl85.lib
tclwithver = $(subst -l,,$(filter -l%, $(TCL_LIB_SPEC)))
dlltool --dllname $(tclwithver).dll --def $(tclwithver).def --output-lib lib$(tclwithver).a
So the case seems that the
tclwithver value actually should be 'tcl85'.
ActiveTcl 8.5.18.0 has it different.
The file C:\Tcl.8.5.18.0\lib\tclConfig.sh has the line
TCL_LIB_SPEC='-LC:/Tcl.8.5.18.0/lib -ltcl85'
So maybe ( as you said ), tcl85 is extracted from '-ltcl85'?
Also, the ENTIRE ActiveTcl 8.5.18.0 tclConfig.sh file looks
*radically* different than the EnterpriseDB LanguagePack tclConfig.sh file.
So, I just installed
ActiveTcl8.5.18.0.298892-win32-x86_64-threaded.exe ( ActiveTcl 8.5.18.0 (64-bit) )
to C:\Tcl.8.5.18.0
Using x86_64-5.3.0-release-posix-seh-rt_v4-rev0 and MinGW and msys on Windows 7, I then put pexports.exe in the path ( from the 'PostgeSQL happy' Stawberry PERL ) in
C:\MinGW\msys\1.0\msys.bat
REM DBD::Pg -- the DBI PostgreSQL interface for Perl
set PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Strawberry\c\bin
Then I did
# ActiveTcl 8.5.18.0 )
./configure TCLSH=/c/Tcl.8.5.18.0/bin/tclsh85.exe --with-tcl --with-tclconfig=/c/Tcl.8.5.18.0/lib --with-includes=/c/Tcl.8.5.18.0/include:/c/Users/TargetUser/Documents/zlib-1.2.8-win32-x86_64/include --with-libraries=/c/Tcl.8.5.18.0/bin:/c/Tcl.8.5.18.0/lib:/c/Users/TargetUser/Documents/zlib-1.2.8-win32-x86_64/bin:/c/Users/TargetUser/Documents/zlib-1.2.8-win32-x86_64/lib
--host=x86_64-w64-mingw32 --prefix=/usr/local/pgsql_0ab9c56_debug --disable-rpath --enable-depend --enable-cassert --enable-debug --with-extra-version=_CFLAGS_O_0ab9c56 CFLAGS="-O -fno-omit-frame-pointer" 2>&1 | tee configure_OPTIONS_Tcl.8.5.18.0.txt
make 2>&1 | tee make_ALONE_Tcl.8.5.18.0.txt
make install 2>&1 | tee make_install_Tcl.8.5.18.0.txt
create language pltcl;
Then I followed
http://get.enterprisedb.com/docs/README-languagepack-950.txt
AND
https://www.postgresql.org/docs/9.5/static/pltcl-functions.html
CREATE FUNCTION tcl_max(integer, integer) RETURNS integer AS $$
if {$1 > $2} {return $1}
return $2
$$ LANGUAGE pltcl STRICT;
select tcl_max(5,3);
postgres=# select tcl_max(5,3);
tcl_max
---------
5
(1 row)
Thanks,
Andre Mikulec
Andre_Mikulec@xxxxxxxxxxx
From: Tom Lane <tgl@xxxxxxxxxxxxx>
Sent: Thursday, October 20, 2016 10:18 AM To: Andre Mikulec Cc: pgsql-general@xxxxxxxxxxxxxx Subject: Re: make PostgreSQL with TCLSH: No rule to make target Andre Mikulec <andre_mikulec@xxxxxxxxxxx> writes:
> I am trying to configure PostgreSQL with the pltcl language available. You're not having any luck with PLs at all, are you? > $ ./configure TCLSH=/c/EnterpriseDB/LanguagePack/9.5/x64/Tcl-8.5/bin I seriously doubt that that's a correct value for TCLSH; the variable is supposed to reference the tclsh executable, not a directory. > At the very end of the make, I am getting the error message. > make[3]: *** No rule to make target `/c/EnterpriseDB/LanguagePack/9.5/x64/Tcl-8.5//.dll', needed by `.def'. Stop. Comparing that to relevant entries in pl/tcl/Makefile, tclwithver = $(subst -l,,$(filter -l%, $(TCL_LIB_SPEC))) TCLDLL = $(dir $(TCLSH))/$(tclwithver).dll $(tclwithver).def: $(TCLDLL) pexports $^ > $@ it seems pretty clear that tclwithver is being set to the empty string, which suggests that TCL_LIB_SPEC is empty or doesn't contain any word starting with "-l". You could look into src/Makefile.global to see what value configure has obtained for TCL_LIB_SPEC. AFAICT, it gets that value verbatim from tclConfig.sh, so this suggests something messed-up about your Tcl installation. Or maybe the bad value for TCLSH is somehow causing this, though I'm not sure how. regards, tom lane |