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_miku...@hotmail.com ________________________________ From: Tom Lane <t...@sss.pgh.pa.us> Sent: Thursday, October 20, 2016 10:18 AM To: Andre Mikulec Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] make PostgreSQL with TCLSH: No rule to make target Andre Mikulec <andre_miku...@hotmail.com> 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
