Windows 8.1 short file names fail on import

[neil456]

Unfortunately PostgreSQL Windows install reports file names in the short 8dot3 format.

Code Select Expand


C:Usersnt>pg_config --libdir
C:/PROGRA~1/POSTGR~1/9.4/lib


When I try to use this to create a path to the dll the following error occurs.

Code Select Expand


ERR: problem loading library in function import : "C:/PROGRA~1/POSTGR~1/9.4/lib/libpq.dll"


However if I do a directory listing, then the short name path seems to work fine.

Code Select Expand


C:Usersnt>dir  "C:/PROGRA~1/POSTGR~1/9.4/lib/"
 Volume in drive C has no label.
 Volume Serial Number is 8081-5731

 Directory of C:PROGRA~1POSTGR~19.4lib

02/12/2015  04:55 PM    <DIR>          .
02/12/2015  04:55 PM    <DIR>          ..
02/03/2015  03:19 AM            15,360 adminpack.dll
02/03/2015  03:23 AM             7,680 ascii_and_mic.dll
. . . . .
02/03/2015  03:22 AM            70,656 libpgtypes.dll
02/03/2015  03:22 AM            12,150 libpgtypes.lib
02/03/2015  03:18 AM           178,688 libpq.dll
02/03/2015  03:18 AM            32,510 libpq.lib
02/03/2015  03:18 AM            16,384 libpqwalreceiver.dll
05/08/2014  12:18 AM           368,982 libxml2.lib
. . . . .


Evidently one of two things are wrong; 1) I am not very good with Windows witchcraft, or 2) the import function in newLISP should somehow handle short file names.



I would be happy for some direction in solving this problem.



Thank you.

Neil

[Lutz]

Don't have Postgres on my Windows installation, but long filenames work importing newlisp.dll on Windows XP SP2.

Code Select Expand


newLISP v.10.6.2 32-bit on Win32 IPv4/6 libffi, options: newlisp -h

> (import "C:/PROGRA~1/newlisp/newlisp.dll" "newlispEvalStr")
newlispEvalStr@6BD7168F
> (get-string (newlispEvalStr "(* 6 7)"))
"42n"
>

or:

Code Select Expand


> (directory "C:/PROGRA~1")
("." ".." "7-Zip" "Apple Software Update" "Common Files" "ComPlus Applications" "Internet Explorer"
....
 "WinZip" "xerox")
>

Not sure what is going on with  the Postgress libpq.dll.

[neil456]

The following code works fine. It correctly finds libpq.dll and sets its path:

Code Select Expand


(println files)
("C:/PROGRA~1/POSTGR~1/9.4/lib/libpq.dylib" "C:/PROGRA~1/POSTGR~1/9.4/lib/libpq.so"
 "C:/PROGRA~1/POSTGR~1/9.4/lib/libpq.dll")

; find the library file
(set 'library (files (or
  (find true (map file? files))
  (throw-error "Cannot find libpq library!"))))


If I (println library) after the above code then the following is printed:

C:/PROGRA~1/POSTGR~1/9.4/lib/libpq.dll



The actual code that is failing is the following when fun_name = "PQcancel":

Code Select Expand


(define (pg_import fun_name)
  (import library fun_name "cdecl"))


Also I checked permissions and my user is marked read and execute for libpq and read, execute and list dir for 9.4/lib directory.

[neil456]

This should be the complete test code for Windows to produce the error;

Code Select Expand


; get pg_config if available  
(set 'pg_lib_dir (exec "pg_config --libdir"))

(if pg_lib_dir
  (set 'files
    (list
      (append (first pg_lib_dir) "/libpq.dylib")  ; shared Mac OS X libs
      (append (first pg_lib_dir) "/libpq.so")   ; loadable elf libs Posix Unix Linux
      (append (first pg_lib_dir) "/libpq.dll")  ; Windows lib
  ))
  (set 'files '(
    "/usr/local/lib/libpq.so.5.1" ; OpenBSD 4.6
    "/usr/lib/libpq.so" ; CentOS or other Linux
    "/usr/lib64/libpq.so" ; Linux 64bit
    "/usr/lib/libpq.so.5.1" ; Debian
    "/usr/local/pgsql/lib/libpq.dylib" ; Mac OS X
    "c:/Program Files/PostgreSQL/8.3/bin/libpq.dll" ; Win32
  )))

; find the library file
(set 'library (files (or
  (find true (map file? files))
  (throw-error "Cannot find libpq library!"))))

; import functions and throw error if not found
(define (pg_import fun_name)
  (import library fun_name "cdecl"))

(map pg_import (list
"PQcancel"
"PQclear"
"PQcmdStatus"
"PQcmdTuples"
))


[Lutz]

I would watch the input parameters and error result of the import function:

Code Select Expand


(define (pg_import fun_name)
    (unless (catch (import library fun_name "cdecl") 'result)
        (println library " " fun_name " " result))
)


[rickyboy]

I would watch the input parameters and error result of the import function

Exactly.  When Neil said "the code that is failing" and "code ... to produce the error", I was thinking to myself, "Well, what *is* the error (message)?"  :)

[neil456]

OK, lets start over and make it really simple.

Code Select Expand


Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:Usersnt>pg_config --libdir
C:/PROGRA~1/POSTGR~1/9.4/lib

C:Usersnt>newLISP -n
newLISP v.10.6.2 32-bit on Win32 IPv4/6 libffi, options: newlisp -h

> (import {C:/PROGRA~1/POSTGR~1/9.4/lib/libpq.dll} "PQcancel" "cdecl")

ERR: problem loading library in function import : "C:/PROGRA~1/POSTGR~1/9.4/lib/libpq.dll"

>  (import {C:/Program Files/PostgreSQL/9.4/lib/libpq.dll} "PQcancel" "cdecl")

ERR: problem loading library in function import : "C:/Program Files/PostgreSQL/9.4/lib/libpq.dll"
>

Now we know libpq is present with the following:

Code Select Expand


C:Usersnt>dir "C:/PROGRA~1/POSTGR~1/9.4/lib"
 Volume in drive C has no label.
 Volume Serial Number is 8081-5731

 Directory of C:PROGRA~1POSTGR~19.4lib

02/12/2015  04:55 PM    <DIR>          .
02/12/2015  04:55 PM    <DIR>          ..
02/03/2015  03:19 AM            15,360 adminpack.dll
. . . .
02/03/2015  03:22 AM            70,656 libpgtypes.dll
02/03/2015  03:22 AM            12,150 libpgtypes.lib
02/03/2015  03:18 AM           178,688 libpq.dll
02/03/2015  03:18 AM            32,510 libpq.lib
02/03/2015  03:18 AM            16,384 libpqwalreceiver.dll
. . . .
05/08/2014  02:51 AM           277,806 zlib.lib
02/03/2015  03:20 AM            44,032 _int.dll
             113 File(s)     20,039,632 bytes
               2 Dir(s)  26,978,947,072 bytes free

C:Usersnt>

or the following:

Code Select Expand


C:Program FilesPostgreSQL9.4lib>dir libp*
 Volume in drive C has no label.
 Volume Serial Number is 8081-5731

 Directory of C:Program FilesPostgreSQL9.4lib

02/03/2015  03:18 AM           275,050 libpgcommon.lib
02/03/2015  03:18 AM         1,119,138 libpgport.lib
02/03/2015  03:22 AM            70,656 libpgtypes.dll
02/03/2015  03:22 AM            12,150 libpgtypes.lib
02/03/2015  03:18 AM           178,688 libpq.dll
02/03/2015  03:18 AM            32,510 libpq.lib
02/03/2015  03:18 AM            16,384 libpqwalreceiver.dll
               7 File(s)      1,704,576 bytes
               0 Dir(s)  27,102,736,384 bytes free


[neil456]

OK, fixed.



I was using the 64-bit version of PostgreSQL, by uninstalling it and installing the 32-bit version everything seems to work.



Does anyone know of an easy way to detect 32-bit versus 64-bit libs on Windows?



Of course assuming that newLISP does not work with 64-bit libs?



Neil

[xytroxon]

The current newLISP Windows installer is only compatible wiith 32bit dlls...



I use Depedency Walker to check out the internals of dlls. Depedency Walker has both gui and command line modes.



http://www.dependencywalker.com/">//http://www.dependencywalker.com/



http://en.wikipedia.org/wiki/Dependency_Walker">//http://en.wikipedia.org/wiki/Dependency_Walker



-- xytroxon

[xytroxon]

There is a perl script at the bottpm of this post showing how to test for dll versions, it should be simple to make a newlisp version ;o)



http://stackoverflow.com/questions/495244/how-can-i-test-a-windows-dll-to-determine-if-it-is-32bit-or-64bit">//http://stackoverflow.com/questions/495244/how-can-i-test-a-windows-dll-to-determine-if-it-is-32bit-or-64bit



--xytroxon

[neil456]

Thanks,

Neil

[rickyboy]

Thanks for the clarification, Neil, and all your sleuthing.  That would have flummoxed me a bit too -- good report.

[neil456]

Yeah, I was confused by this in the download section, but should have known better.

Win32 installer v.10.6.2 (also runs on Windows 7/8 64-bit)

The meaning of which is obvious now, but it would have been clearer with:

Win32 installer v.10.6.2 (also runs on Windows 7/8 64-bit, in 32-bit mode with only 32-bit libraries)

I took the original to mean that the Win32 installer now installed both 32 and 64 bit.  Again my Windows witchcraft failed me. Macs (my main dev platform) got over this sickness some time ago as I only have one install of PostgreSQL and it works fine with newLISP without any of this silliness.