Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

unable to load pgtcl

82 views
Skip to first unread message

patnai...@gmail.com

unread,
Sep 21, 2015, 6:38:36 PM9/21/15
to
Hello,

I downloaded Postgres 9.4 and also the pgtcl from sourceforge and have not succeeded in sourcing the package.

I ensured the postgres bin is listed as first element in path.

I am getting odd errors:

My path var:
env(PATH) = C:\Program Files\PostgreSQL\9.4\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem

package require Pgtcl
couldn't load library "C:/Tcl8419/lib/pgtcl/libpgtcl.dll": invalid argument

Any ideas? Thanks

Dave

unread,
Sep 21, 2015, 7:19:05 PM9/21/15
to
It might be a 32-bit dll that you're trying to load in a 64-bit Tcl...
or vice versa.

--
computerjock AT mail DOT com

Robert Heller

unread,
Sep 21, 2015, 7:47:58 PM9/21/15
to
At Mon, 21 Sep 2015 18:19:00 -0500 Dave <nor...@nohost.com> wrote:

>
> On 9/21/2015 5:38 PM, patnai...@gmail.com wrote:
> > Hello,
> >
> > I downloaded Postgres 9.4 and also the pgtcl from sourceforge and have not succeeded in sourcing the package.
> >
> > I ensured the postgres bin is listed as first element in path.

Does the postgres bin directory contain the libpq.dll file? And other needful
DLL files?

> >
> > I am getting odd errors:
> >
> > My path var:
> > env(PATH) = C:\Program Files\PostgreSQL\9.4\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem
> >
> > package require Pgtcl
> > couldn't load library "C:/Tcl8419/lib/pgtcl/libpgtcl.dll": invalid argument
> >
> > Any ideas? Thanks
> >
>
> It might be a 32-bit dll that you're trying to load in a 64-bit Tcl...
> or vice versa.
>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

Rich

unread,
Sep 21, 2015, 7:50:38 PM9/21/15
to
Note, Tcl does not use your "PATH" variable to find its loadable
packages.

It uses its own "auto_path" variable.

You do realise, as well, that the pgtcl library needs to be compiled
first?

lj

unread,
Sep 21, 2015, 10:21:42 PM9/21/15
to
patnai...@gmail.com wrote:
>...
> package require Pgtcl
> couldn't load library "C:/Tcl8419/lib/pgtcl/libpgtcl.dll": invalid argument

To clarify:

If you are talking about pgtclng on Sourceforge, I only have 32-bit DLLs in
the download, since that is all I can make at present. If you are on a
64-bit Windows, you are on your own. Sorry.

Yes the Windows download includes libpgtcl.dll - if you are on a compatible
32-bit system, you will not need to compile it.

Although Tcl does not use PATH to find loadable packages, it does use PATH
to find the DLL needed by the loadable package. If you are using
EnterpriseDB PostgreSQL, it actually needs a lot more than just libpq.dll,
so the whole thing needs to be on the PATH. But it sounds like the OP
already did that.

Unfortunately, "invalid argument" is not very helpful - Windows is telling you
that something went wrong loading the DLL and and it's up to you to figure
out what.

Robert Heller

unread,
Sep 21, 2015, 10:29:46 PM9/21/15
to
At Mon, 21 Sep 2015 23:48:39 +0000 (UTC) Rich <ri...@example.invalid> wrote:

>
> patnai...@gmail.com wrote:
> > Hello,
>
> > I downloaded Postgres 9.4 and also the pgtcl from sourceforge and
> > have not succeeded in sourcing the package.
>
> > I ensured the postgres bin is listed as first element in path.
>
> > I am getting odd errors:
>
> > My path var:
> > env(PATH) = C:\Program Files\PostgreSQL\9.4\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem
>
> > package require Pgtcl
> > couldn't load library "C:/Tcl8419/lib/pgtcl/libpgtcl.dll": invalid argument
>
> Note, Tcl does not use your "PATH" variable to find its loadable
> packages.

But *MS-Windows* probably uses the PATH variable to load dependent shared
libraries...

>
> It uses its own "auto_path" variable.
>
> You do realise, as well, that the pgtcl library needs to be compiled
> first?

Unless the OP downloaded a *compiled binary* package...

Rich

unread,
Sep 21, 2015, 10:58:09 PM9/21/15
to
Robert Heller <hel...@deepsoft.com> wrote:
> At Mon, 21 Sep 2015 23:48:39 +0000 (UTC) Rich <ri...@example.invalid> wrote:
> > patnai...@gmail.com wrote:
> > > Hello,
> >
> > > I downloaded Postgres 9.4 and also the pgtcl from sourceforge and
> > > have not succeeded in sourcing the package.
> >
> > > I ensured the postgres bin is listed as first element in path.
> >
> > > I am getting odd errors:
> >
> > > My path var:
> > > env(PATH) = C:\Program Files\PostgreSQL\9.4\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem
> >
> > > package require Pgtcl
> > > couldn't load library "C:/Tcl8419/lib/pgtcl/libpgtcl.dll":
> > > invalid argument
> >
> > Note, Tcl does not use your "PATH" variable to find its loadable
> > packages.

> But *MS-Windows* probably uses the PATH variable to load dependent shared
> libraries...

Yes, but does Tcl, on windows, use windows native dll path finding, or
does it use the pkgIndex.tcl files to [load] the dll (like it does for
every other Tcl package)? What few windows compiled Tcl packages I've
used, all had pkgIndex.tcl files and loaded their .dll's via [load]
from the pkgIndex.tcl file.

> > It uses its own "auto_path" variable.
> >
> > You do realise, as well, that the pgtcl library needs to be
> > compiled first?

> Unless the OP downloaded a *compiled binary* package...

That is true. In any case, as with most of the initial questions,
there's not enough information provided to do much more than guess at
what might be the problem.

Gerald W. Lester

unread,
Sep 21, 2015, 11:30:14 PM9/21/15
to
On 9/21/15 9:56 PM, Rich wrote:
> Robert Heller <hel...@deepsoft.com> wrote:
>> At Mon, 21 Sep 2015 23:48:39 +0000 (UTC) Rich <ri...@example.invalid> wrote:
>>> patnai...@gmail.com wrote:
>>>> Hello,
>>>
>>>> I downloaded Postgres 9.4 and also the pgtcl from sourceforge and
>>>> have not succeeded in sourcing the package.
>>>
>>>> I ensured the postgres bin is listed as first element in path.
>>>
>>>> I am getting odd errors:
>>>
>>>> My path var:
>>>> env(PATH) = C:\Program Files\PostgreSQL\9.4\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem
>>>
>>>> package require Pgtcl
>>>> couldn't load library "C:/Tcl8419/lib/pgtcl/libpgtcl.dll":
>>>> invalid argument
>>>
>>> Note, Tcl does not use your "PATH" variable to find its loadable
>>> packages.
>
>> But *MS-Windows* probably uses the PATH variable to load dependent shared
>> libraries...
>
> Yes, but does Tcl, on windows, use windows native dll path finding, or
> does it use the pkgIndex.tcl files to [load] the dll (like it does for
> every other Tcl package)? What few windows compiled Tcl packages I've
> used, all had pkgIndex.tcl files and loaded their .dll's via [load]
> from the pkgIndex.tcl file.

On Windows it uses auto_path to find the package index files. The next step
is that it uses the what the package index says to load the initial DLL.
Dependent DLLs are automatically handled by the OS and thus use the PATH.


>
>>> It uses its own "auto_path" variable.
>>>
>>> You do realise, as well, that the pgtcl library needs to be
>>> compiled first?
>
>> Unless the OP downloaded a *compiled binary* package...
>
> That is true. In any case, as with most of the initial questions,
> there's not enough information provided to do much more than guess at
> what might be the problem.
>

Yeah, whats new.

--
+------------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+------------------------------------------------------------------------+

Christian Gollwitzer

unread,
Sep 22, 2015, 1:06:31 AM9/22/15
to
Am 22.09.15 um 04:21 schrieb lj:
> patnai...@gmail.com wrote:
> To clarify:
>
> If you are talking about pgtclng on Sourceforge, I only have 32-bit DLLs in
> the download, since that is all I can make at present. If you are on a
> 64-bit Windows, you are on your own. Sorry.

I suspect this is the problem, see below.

> Unfortunately, "invalid argument" is not very helpful - Windows is
> telling you
> that something went wrong loading the DLL and and it's up to you to figure
> out what.

Windows does have error codes for this, but Tcl converts the errors into
Unix E* error codes and maps everything which is not known to EINVAL. In
my experience, EINVAL was most often thrown if there is a bit mismatch.
If dependent libraries are not found, a "file not found" error appears.

Alternatively, Tcl8.6 includes a PostGreSQL driver for TDBC - maybe you
can use that instead of pgtcl?

Christian

Ralf Fassel

unread,
Sep 22, 2015, 3:55:23 AM9/22/15
to
* Rich <ri...@example.invalid>
| > > Note, Tcl does not use your "PATH" variable to find its loadable
| > > packages.
>
| > But *MS-Windows* probably uses the PATH variable to load dependent
| > shared libraries...
>
| Yes, but does Tcl, on windows, use windows native dll path finding, or
| does it use the pkgIndex.tcl files to [load] the dll (like it does for
| every other Tcl package)? What few windows compiled Tcl packages I've
| used, all had pkgIndex.tcl files and loaded their .dll's via [load]
| from the pkgIndex.tcl file.

The initial dll (the one "package require" asks for) is found via TCL's
auto_path/pkgIndex.tcl, but any dll this initial one depends on (like MS
runtime-dlls or others against which the initial dll is linked) are
searched for via the regular MS search mechanism (which includes PATH,
amongst others).

R'

Ralf Fassel

unread,
Sep 22, 2015, 4:00:10 AM9/22/15
to
* lj <lj...@pobox.com>
| To clarify:
>
| If you are talking about pgtclng on Sourceforge, I only have 32-bit
| DLLs in the download, since that is all I can make at present. If you
| are on a 64-bit Windows, you are on your own. Sorry.

This is a problem only if one is using a 64 bit TCL. A 32 bit TCL will
run on 64 bit Windows just fine, and can use the 32-bit DLL.
However, I don't know the requirements for the dependent DLLs (whether
they are all required in 32 bit, too (would make sense IMHO)).

R'

anj patnaik

unread,
Sep 23, 2015, 11:40:43 AM9/23/15
to
Hello all,

I am on a Windows 7 64-bit platform. I downloaded the pgtcl2.1.1-win32.zip file from sourceforge site.

I have the path variable pointing to the Postgres lib directory. And I do see libpq.dll amongst a myriad of dll files there. If i remove the path to the bin directory, I get a different error: this library or dependent library cannot be found. So putting the bin dir in the path causes that dependent library error to go away, but I get this "invalid argument" error.

Thanks.

Robert Heller

unread,
Sep 23, 2015, 12:56:17 PM9/23/15
to
At Wed, 23 Sep 2015 08:40:39 -0700 (PDT) anj patnaik <pat...@gmail.com> wrote:

>
> On Tuesday, September 22, 2015 at 4:00:10 AM UTC-4, Ralf Fassel wrote:
> > * lj <lj...@pobox.com>
> > | To clarify:
> > >
> > | If you are talking about pgtclng on Sourceforge, I only have 32-bit
> > | DLLs in the download, since that is all I can make at present. If you
> > | are on a 64-bit Windows, you are on your own. Sorry.
> >=20
> > This is a problem only if one is using a 64 bit TCL. A 32 bit TCL will
> > run on 64 bit Windows just fine, and can use the 32-bit DLL.
> > However, I don't know the requirements for the dependent DLLs (whether
> > they are all required in 32 bit, too (would make sense IMHO)).
> >=20
> > R'
>
> Hello all,
>
> I am on a Windows 7 64-bit platform. I downloaded the pgtcl2.1.1-win32.zip =
> file from sourceforge site.=20
>
> I have the path variable pointing to the Postgres lib directory. And I do s=
> ee libpq.dll amongst a myriad of dll files there. If i remove the path to t=
> he bin directory, I get a different error: this library or dependent librar=
> y cannot be found. So putting the bin dir in the path causes that dependent=
> library error to go away, but I get this "invalid argument" error.

Are the Postgres libraries you installed 64-bit or 32-bit? Is the version of
Tcl 64-bit or 32-bit? The DLL(s) in pgtcl2.1.1-win32.zip are 32-bit. This
means you need a *32-bit* version of the Postgres libraries and a *32-bit*
version of Tcl. It is not possible to mix bit-isms. (Only under MacOSX,
which supports 'multi-arch' libraries and binaries.)

I don't know if there is a (native) MS-Windows utility like objdump, which can
be used to display the arch:

ub1204-64% i686-w64-mingw32-objdump -x /home/heller/Win32/MRRSystem-2.1.36/Win32/Installer/.libs/libdiskfree.dll | head

/home/heller/Win32/MRRSystem-2.1.36/Win32/Installer/.libs/libdiskfree.dll: file format pei-i386
/home/heller/Win32/MRRSystem-2.1.36/Win32/Installer/.libs/libdiskfree.dll
architecture: i386, flags 0x0000013b:
HAS_RELOC, EXEC_P, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, D_PAGED
start address 0x6bc81420

Characteristics 0x2106
executable
line numbers stripped



>
> Thanks.

Rich

unread,
Sep 23, 2015, 12:56:26 PM9/23/15
to
anj patnaik <pat...@gmail.com> wrote:
> On Tuesday, September 22, 2015 at 4:00:10 AM UTC-4, Ralf Fassel wrote:
> > * lj <lj...@pobox.com>
> > | To clarify:
> > >
> > | If you are talking about pgtclng on Sourceforge, I only have 32-bit
> > | DLLs in the download, since that is all I can make at present. If you
> > | are on a 64-bit Windows, you are on your own. Sorry.
> >
> > This is a problem only if one is using a 64 bit TCL. A 32 bit TCL will
> > run on 64 bit Windows just fine, and can use the 32-bit DLL.
> > However, I don't know the requirements for the dependent DLLs (whether
> > they are all required in 32 bit, too (would make sense IMHO)).
> >
> > R'

> Hello all,

> I am on a Windows 7 64-bit platform. I downloaded the
> pgtcl2.1.1-win32.zip file from sourceforge site.

If you read the part of the grandparent post that you quote above, you
will see that the pgtcl2.1.1-win32.zip is for 32-bit only

Are you running a 64-bit Tcl. and/or 64-bit Postgres?

If so, then that is likely the issue, you can't mix 32 and 64 bit dll
items this way.

You'll either need to compile a 64-big pgtcl dll, or run 32-bit Tcl and
32-bit postgres.

anj patnaik

unread,
Sep 23, 2015, 1:24:39 PM9/23/15
to
postgres is 64 bit so that may be issue.

Rich

unread,
Sep 23, 2015, 2:13:12 PM9/23/15
to
Not 'may', the correct word would be 'is'.

You can not mix 32-bit pgtcl and 64-bit postgres.
0 new messages