TEA Sample Extension, 64-bit MinGW: undefined reference to tclStubsPtr

[Will Duquette]

Howdy!

I just downloaded the latest version of the TEA sample extension from the timeline head at core.tcl.tk/sampleextension, and I'm trying to build it as is against ActiveTcl 8.6.4 64-bit.

My configure runs OK, but when I do make and it tries to link the extension I get lots of errors with

"undefined reference to tclStubsPtr". Apparently it's not picking up the tclstub86.lib in the link, but it looks like it should be. The gcc line producing the errors is

We did the configure like this:

configure --with-tcl=C:/Tcl/lib --enable-64bit

When we make, it builds the C code, then does this to link:

gcc -shared -o sample05.dll sample.o tclsample.o "/c/Tcl/lib/tclstub86.lib" -static-libgcc

That yields the error "undefined reference to tclStubsPtr" in many places.

Any idea what we're doing wrong?

[pal...@yahoo.com]

My guess is that the MinGW-64 gcc tool chain does not understand the 64-bit .lib format produced by VC 6 (which is the compiler ActiveState uses). This used to be an issue at one time, I don't know if the incompatibility has been fixed in newer mingw distributions.

One way to verify would be to rebuild Tcl using MinGW-64 and try linking against that.

/Ashok

[Will Duquette]

On Thursday, August 18, 2016 at 2:44:21 AM UTC-7, pal...@yahoo.com wrote:
> My guess is that the MinGW-64 gcc tool chain does not understand the 64-bit .lib format produced by VC 6 (which is the compiler ActiveState uses). This used to be an issue at one time, I don't know if the incompatibility has been fixed in newer mingw distributions.
>
> One way to verify would be to rebuild Tcl using MinGW-64 and try linking against that.

Thanks, we'll check that out.

Will

[Dave]

On 8/18/2016 4:44 AM, pal...@yahoo.com wrote:
> My guess is that the MinGW-64 gcc tool chain does not understand the 64-bit .lib format produced by VC 6 (which is the compiler ActiveState uses). This used to be an issue at one time, I don't know if the incompatibility has been fixed in newer mingw distributions.

Using my ActiveState Tcl 8.6.4, I just did a link under Msys2 64-bit and
it worked fine (except for the wonky error message that can be ignored).

$ ls /c/Program\ Files/Tcl\ -\ 8.6.4/lib
ppm/
tclConfig-shared.sh
teapot/
tclConfig.sh
tk8.6/
tkstub86.lib
fsdialog/
tclIndex
tk86.lib
treectrl2.4/
imgtools0.1/
tcl8/
tkConfig-shared.sh
twapi4.1.2.7/
itcl4.0.3/
tcl8.6/
tclstub86.lib
tkConfig.sh
tcl86.lib
tdbc1.0.2/
tkdnd2.8/

$ gcc -v
Using built-in specs.
COLLECT_GCC=D:\msys64\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-6.1.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64
--with-tune=generic
--enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared
--enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-time=yes --disable-libstdcxx-pch
--disable-libstdcxx-debug --disable-isl-version-check --enable-lto
--enable-libgomp --disable-multilib --enable-checking=release
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64
--with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64
--with-pkgversion='Rev1, Built by MSYS2 project'
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld
Thread model: posix
gcc version 6.1.0 (Rev1, Built by MSYS2 project)

$ g++ -shared -o Mk4tcl.dll mk4tcl.o mk4too.o column.o custom.o
derived.o fileio.o field.o format.o handler.o persist.o remap.o std.o
store.o string.o table.o univ.o view.o viewx.o '-L/c/Program Files/Tcl -
8.6.4/lib' -ltclstub86 -static-libgcc -static-libstdc++ -Wl,-Bstatic
-Wl,--whole-archive -lpthread -Wl,--no-whole-archive -Wl,-Bdynamic
Warning: corrupt .drectve at end of def file

The goofy warning is (from my memory) an artifact of some pragma thing
for windows that tells the linker hints or instructions about libraries
-- gcc does not understand them.


--
computerjock AT mail DOT com

[Will Duquette]

On Thursday, August 18, 2016 at 8:36:29 AM UTC-7, Dave wrote:
> On 8/18/2016 4:44 AM, pal...@yahoo.com wrote:
> > My guess is that the MinGW-64 gcc tool chain does not understand the 64-bit .lib format produced by VC 6 (which is the compiler ActiveState uses). This used to be an issue at one time, I don't know if the incompatibility has been fixed in newer mingw distributions.
>
>
> Using my ActiveState Tcl 8.6.4, I just did a link under Msys2 64-bit and
> it worked fine (except for the wonky error message that can be ignored).

So this is a direct use of gcc, not via the TEA Makefile?

Will

[Dave]

On 8/18/2016 12:04 PM, Will Duquette wrote:
> On Thursday, August 18, 2016 at 8:36:29 AM UTC-7, Dave wrote:
>> > On 8/18/2016 4:44 AM, pal...@yahoo.com wrote:
>>> > > My guess is that the MinGW-64 gcc tool chain does not understand the 64-bit .lib format produced by VC 6 (which is the compiler ActiveState uses). This used to be an issue at one time, I don't know if the incompatibility has been fixed in newer mingw distributions.
>> >
>> >
>> > Using my ActiveState Tcl 8.6.4, I just did a link under Msys2 64-bit and
>> > it worked fine (except for the wonky error message that can be ignored).
> So this is a direct use of gcc, not via the TEA Makefile?

I had grabbed metakit from github around the beginning of the month. I
did run 'configure' which I presume was generated using the tcl.m4
included with the download.

I did have to manually link against the stub library in addition to the
ld options to statically link the non-windows DLL's.

However, my comment was directed to the guess that gcc cannot deal with
.lib's -- it can. That was really my only point. Sorry if I was not very
clear about it.

[Will Duquette]

On Thursday, August 18, 2016 at 10:19:12 AM UTC-7, Dave wrote:
> > So this is a direct use of gcc, not via the TEA Makefile?
>
> I had grabbed metakit from github around the beginning of the month. I
> did run 'configure' which I presume was generated using the tcl.m4
> included with the download.
>
> I did have to manually link against the stub library in addition to the
> ld options to statically link the non-windows DLL's.
>
> However, my comment was directed to the guess that gcc cannot deal with
> .lib's -- it can. That was really my only point. Sorry if I was not very
> clear about it.

Oh, got that, and I'm glad to know it. I asked further because if you're building a TEA extension, I'm wanting to know if there was anything additional you needed to do to make it work.

You say you had to manually link against the stub library—specifically, how did you tell the build to do that?

[Dave]

I've never built an autoconf.in file so I don't know how to include the
tcl.m4 file. Furthermore, there does not seem to be any version id in
the tcl.m4 included with the github download:

https://github.com/jcw/metakit

I ran the supplied configure and then 'make'. The compiles worked with
some warnings but the link failed.

$ mkdir build
$ cd build
$ bash ../unix/configure --with-tcl=/c/Progra~1/Tcl/include
$ make
[compiles omitted]

g++ -shared -o Mk4tcl.dll mk4tcl.o mk4too.o column.o custom.o derived.o
fileio.o field.o format.o handler.o persist.o remap.o std.o store.o

string.o table.o univ.o view.o viewx.o -lpthread -lstdc++
mk4tcl.o:temp.cpp:(.text+0x3431): undefined reference to `Tcl_InitStubs'
mk4tcl.o:temp.cpp:(.rdata$.refptr.tclStubsPtr[.refptr.tclStubsPtr]+0x0):
undefined reference to `tclStubsPtr'
collect2.exe: error: ld returned 1 exit status

Clearly there is a problem with the configure or Makefile.in that does
not include the stubs library. Therefore I had to manually do the link.

I copied the link step from the 'script' output and modified it to
include the stubs library and do the static linking because I wanted a
windows-only DLL -- I had to statically link the GCC (non-windows)
libraries. I did not mess around with modifying the Makefile for this
single link.

BTW, a few more tests fail with this 64-bit build that with the 32-bit
build (even the ActiveState 64-bit version). There's probably some 32-
vs. 64-bit bug lurking in the code.

[Don Porter]

On 08/17/2016 02:12 PM, Will Duquette wrote:
> I just downloaded the latest version of the TEA sample extension from
> the timeline head at core.tcl.tk/sampleextension, and I'm trying to build
> it as is against ActiveTcl 8.6.4 64-bit.

I would assume that these days if you're looking for a sample on how
to do a TEA extension for Tcl, the better examples to look at are
things like Itcl, Thread, or TDBC that actually see human use regularly.

--
| Don Porter Applied and Computational Mathematics Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|

[Rolf Ade]

Don Porter <donald...@nist.gov> writes:
> On 08/17/2016 02:12 PM, Will Duquette wrote:
>> I just downloaded the latest version of the TEA sample extension from
>> the timeline head at core.tcl.tk/sampleextension, and I'm trying to build
>> it as is against ActiveTcl 8.6.4 64-bit.
>
> I would assume that these days if you're looking for a sample on how
> to do a TEA extension for Tcl, the better examples to look at are
> things like Itcl, Thread, or TDBC that actually see human use regularly.

Wait ... You say, sampleextension isn't a good starting point for a
tcl extension build system anymore, "these days"? Instead, one should
look, what that named extensions do?