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

Use a package within an extension

65 views
Skip to first unread message

Оlе Ѕtrеісhеr

unread,
Jun 4, 2016, 3:58:54 AM6/4/16
to
Hi,

how is it possible to use a package (tkblt) from within an extension?
So, is there an equivalent to "package require" on the C level?

I want to avoid an explicite linking of the library, since its path is
not the standard path, but in the Tcl path, and this may change from
system to system.

How would I do that?

Best regards

Ole

Оlе Ѕtrеісhеr

unread,
Jun 4, 2016, 4:11:10 AM6/4/16
to
ole-use...@gmx.net (Оlе Ѕtrеісhеr) writes:
> how is it possible to use a package (tkblt) from within an extension?
> So, is there an equivalent to "package require" on the C level?
>
> I want to avoid an explicite linking of the library, since its path is
> not the standard path, but in the Tcl path, and this may change from
> system to system.

I forgot to mention: I tried Tcl_PkgRequire(interp, "tkblt", NULL, 0),
however then I cannot load the extension:

couldn't load file "lib/tksao1.0/libtksao1.0.so": lib/tksao1.0/libtksao1.0.so: undefined symbol: Blt_GetVector

(BltGetVector is one of the functions I want to call).

Best regards

Ole

EL

unread,
Jun 4, 2016, 6:44:04 AM6/4/16
to
Am 04.06.16 um 10:11 schrieb Оlе Ѕtrеісhеr:

>> I want to avoid an explicite linking of the library, since its path is
>> not the standard path, but in the Tcl path, and this may change from
>> system to system.
>
> I forgot to mention: I tried Tcl_PkgRequire(interp, "tkblt", NULL, 0),
> however then I cannot load the extension:
>
> couldn't load file "lib/tksao1.0/libtksao1.0.so": lib/tksao1.0/libtksao1.0.so: undefined symbol: Blt_GetVector

You must link against the libbltstubs.so that it provides. I am not sure
if Blt provides a stubs library, but Tcl C extensions which expose C
functions do usually provide a stubs library to link against.
Then you must initialize this stubs library, which connects the function
pointers to the real library. This is usually something like
Blt_InitStubs(), by convention ...

If there is no stubs library for Blt, then there is no way around
platform dependent linking against libblt.so.


--
EL

Robert Heller

unread,
Jun 4, 2016, 7:43:35 AM6/4/16
to
This is not necessarily true (it might be in the *specific* case of the tkblt
extension). In the general case, you need the proper pkgIndex.tcl files (+
<mumble>.so/.tcl files) in the proper places (eg somewhere under the
driectories specified in auto_path). Also, if this is a in a StarPack the
various files need to be packed into the StarPack (or kit file) and you might
need to use Tcl_Eval("package require ..."), to make sure it uses the VFS code
[I don't know if that is needed or not].

Sometimes in the *specific* case of a *binary* extension/package, there are
issues of dependent libraries, that are not themselves Tcl/Tk extensions, that
might not be installed on the target system (or might not be in the 'standard'
place (eg /usr/lib[64]). Unfortunately, the Tcl [load] command does not have a
way of dealing with this.

>
>

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

Оlе Ѕtrеісhеr

unread,
Jun 4, 2016, 8:26:08 AM6/4/16
to
Robert Heller <hel...@deepsoft.com> writes:
> At Sat, 4 Jun 2016 12:30:17 +0200 EL <elehm...@gmail.com> wrote:
>> You must link against the libbltstubs.so that it provides. I am not sure
>> if Blt provides a stubs library, but Tcl C extensions which expose C
>> functions do usually provide a stubs library to link against.

It does not (yet). Since I have the source: how could I create the stubs?

>> If there is no stubs library for Blt, then there is no way around
>> platform dependent linking against libblt.so.
>
> This is not necessarily true (it might be in the *specific* case of
> the tkblt extension). In the general case, you need the proper
> pkgIndex.tcl files (+ <mumble>.so/.tcl files) in the proper places (eg
> somewhere under the driectories specified in auto_path).

This is there. So, in wish:

% package require tkblt

works well. However, I still can't access the functions from C even after

if (Tcl_PkgRequire(interp, "tkblt", NULL, 0) == NULL)
return TCL_ERROR;

because they are not linked and so the extension fails to load before
it is executed.

> Also, if this is a in a StarPack

It is just a plain extension, with plain tcl/tk.

Best regards

Ole

Robert Heller

unread,
Jun 4, 2016, 9:42:48 AM6/4/16
to
OK, this is a case where yes, you need the tkblt stubs library. C/C++ does not
really support 'dynamic' function loading, in the same sense as the Tcl
interpreter -- eg, there isn't a dynamic lookup table mapping a 'proc' to a
piece of code, at least not as part of the core language. A 'stubs', is in
fact a lookup table / jump table -- the 'Tcl_PkgRequire' esentually fills in
the table. One 'cheat', is to call the functions in the tkblt extension by way
of Tcl_Eval(). This will make use of Tcl's dynamic lookup table. It does mean
converting everything from C'ish data objects to Tcl_Obj()'s and back again.

Note: *some* extensions don't provide a C/C++ API at all and only define
things with Tcl_...Command() calls. This sort of extension can *only* be used
from Tcl (or via Tcl_Eval()). In other cases, there isn't a stubs library, but
only a regular (shared) library that might expose a C/C++ API, but one that
might be *different* from the Tcl API. In that case you just have to link
against the extension lib. In which case it becomes a dependent library. There
*might* be trouble loading the extension if the library is NOT in some
'standard' place (eg /usr/lib[64]), which might be cured by [load]ing it first
(eg coding the pkgIndex.tcl file to include a 'package require whatever'
before loading your extension).

>
> > Also, if this is a in a StarPack
>
> It is just a plain extension, with plain tcl/tk.
>
> Best regards
>
> Ole
>

Оlе Ѕtrеісhеr

unread,
Jun 4, 2016, 9:58:32 AM6/4/16
to
Robert Heller <hel...@deepsoft.com> writes:
> OK, this is a case where yes, you need the tkblt stubs library. C/C++ does not
> really support 'dynamic' function loading, in the same sense as the Tcl
> interpreter -- eg, there isn't a dynamic lookup table mapping a 'proc' to a
> piece of code, at least not as part of the core language. A 'stubs', is in
> fact a lookup table / jump table -- the 'Tcl_PkgRequire' esentually fills in
> the table. One 'cheat', is to call the functions in the tkblt extension by way
> of Tcl_Eval(). This will make use of Tcl's dynamic lookup table. It does mean
> converting everything from C'ish data objects to Tcl_Obj()'s and back
> again.

So how do I create one if I have the source of tkblt?

> Note: *some* extensions don't provide a C/C++ API at all and only define
> things with Tcl_...Command() calls. This sort of extension can *only* be used
> from Tcl (or via Tcl_Eval()).

This is not the case here? tkblt provides a header file with the API.

> In other cases, there isn't a stubs library, but only a regular
> (shared) library that might expose a C/C++ API, but one that might be
> *different* from the Tcl API. In that case you just have to link
> against the extension lib.

This is what I want to avoid. Is there a way to create the stub myself?

Best regards

Ole

EL

unread,
Jun 4, 2016, 12:44:04 PM6/4/16
to
Am 04.06.16 um 15:58 schrieb Оlе Ѕtrеісhеr:

> So how do I create one if I have the source of tkblt?

This is not too easy. You need to create stub functions for every Blt_*
function that you want to expose, and then create a static stubs library
with the connections to the real functions. It requires some knowledge
of C and digging into / expanding the C sources of BLT.

There are examples out in the wild, look i.e. for Itcl (up to version
3.x) here:
http://incrtcl.cvs.sourceforge.net/viewvc/incrtcl/incrTcl/itcl/generic/

You see the itclStubInit.c and itclStubLib.c files, they merely show
what needs to be done. And the itclDecls.h/itcl.decls, itclIntDecls.h
files for the definitions. The intDecls are for internal declarations,
afaik.
Then you must ensure that the library functions are *always* loaded
through the stubs rather than directly.

If BLT doesn't provide that yet, it would be a great and useful
extension. And I guess every BLT user would praise you :)


--
EL

EL

unread,
Jun 4, 2016, 1:02:04 PM6/4/16
to
Am 04.06.16 um 18:28 schrieb EL:

> If BLT doesn't provide that yet, it would be a great and useful
> extension. And I guess every BLT user would praise you :)

Because then it is not only possible to load and use BLT into arbitrary
C extensions.
As a stubs enabled extension, BLT could also be used with *any* Tcl
version >=8, without the need to recompile it. That would mean that it
is not anymore tied to a particular version of Tcl/Tk, finally.
And furthermore it would also be possible to use BLT with starkits.


--
EL

Robert Heller

unread,
Jun 4, 2016, 1:16:39 PM6/4/16
to
Not without a fair amount of coding. You basically need to create a 'jump
table', something like what is in tclDecls.h. And that will include an
initializer function, to fill in the jump table upon loading -- eg a "C/C++"
version of the _init() function that gets passed the staticly linked jump
table to be filled in. Since Tcl/Tk is itself open source, you can probably
'steal' the basic code and edit it to suit. The 'stubs' library contains the
un-filled jump table and the related infrastructure, probably along with code
to use the libdl calls to load the library and then call the _init() function
to fill in the library. And you would need a stubs header file.

Is there a really good reason to avoid just linking with the regular extension
library and arange for it to be pre-loaded with your extension?

Оlе Ѕtrеісhеr

unread,
Jun 4, 2016, 2:55:09 PM6/4/16
to
Robert Heller <hel...@deepsoft.com> writes:
>> This is what I want to avoid. Is there a way to create the stub myself?
>
> Not without a fair amount of coding. You basically need to create a
> 'jump table', something like what is in tclDecls.h. And that will
> include an initializer function, to fill in the jump table upon
> loading -- eg a "C/C++" version of the _init() function that gets
> passed the staticly linked jump table to be filled in.

This looks a quite formal transformation. And there is no script which
generates this from the header file?

> Since Tcl/Tk is itself open source, you can probably 'steal' the basic
> code and edit it to suit. The 'stubs' library contains the un-filled
> jump table and the related infrastructure, probably along with code to
> use the libdl calls to load the library and then call the _init()
> function to fill in the library. And you would need a stubs header
> file.

Puh, this looks really hard.

> Is there a really good reason to avoid just linking with the regular
> extension library and arange for it to be pre-loaded with your
> extension?

The reason is that I am going to prepare Debian packages for both tkblt
(first version is already in Debian) and the other, tksao package.

Since they are (now) independent Tcl packages, it makes sense to keep
them separately. And over time, one may be updated and the other still
kept in its old version. Also, users may have written some programs or
extensions that use tkblt, and they probably don't want to recompile
just because there is an update of tkblt.

There is a way in Debian that deals with updates of shared libraries
(using SONAME); however for this I would need to patch tkblt anyway, and
it also does not sound very "Tcl-ish".

I am wondering, Tcl is such an mature language, with version 8.1 (where
the stubs were introduced) 17 years old, and there is still no
convenient way to generate them?

Best regards

Ole

Оlе Ѕtrеісhеr

unread,
Jun 4, 2016, 2:57:43 PM6/4/16
to
EL <elehm...@gmail.com> writes:

> Am 04.06.16 um 15:58 schrieb Оlе Ѕtrеісhеr:
>> So how do I create one if I have the source of tkblt?
>
> If BLT doesn't provide that yet, it would be a great and useful
> extension. And I guess every BLT user would praise you :)

It is not BLT, but tkblt which is a subset only. And since I am not a
Tcl guru, the chances that this happens are minimal unless there is a
script that does the work for me.

Best regards

Ole

Robert Heller

unread,
Jun 4, 2016, 3:28:39 PM6/4/16
to
At Sat, 04 Jun 2016 20:55:06 +0200 ole-use...@gmx.net (=?utf-8?B?0J5s0LUg0IV0ctC10ZbRgWjQtXI=?=) wrote:

>
> Robert Heller <hel...@deepsoft.com> writes:
> >> This is what I want to avoid. Is there a way to create the stub myself?
> >
> > Not without a fair amount of coding. You basically need to create a
> > 'jump table', something like what is in tclDecls.h. And that will
> > include an initializer function, to fill in the jump table upon
> > loading -- eg a "C/C++" version of the _init() function that gets
> > passed the staticly linked jump table to be filled in.
>
> This looks a quite formal transformation. And there is no script which
> generates this from the header file?
>
> > Since Tcl/Tk is itself open source, you can probably 'steal' the basic
> > code and edit it to suit. The 'stubs' library contains the un-filled
> > jump table and the related infrastructure, probably along with code to
> > use the libdl calls to load the library and then call the _init()
> > function to fill in the library. And you would need a stubs header
> > file.
>
> Puh, this looks really hard.

Yes...

>
> > Is there a really good reason to avoid just linking with the regular
> > extension library and arange for it to be pre-loaded with your
> > extension?
>
> The reason is that I am going to prepare Debian packages for both tkblt
> (first version is already in Debian) and the other, tksao package.
>
> Since they are (now) independent Tcl packages, it makes sense to keep
> them separately. And over time, one may be updated and the other still
> kept in its old version. Also, users may have written some programs or
> extensions that use tkblt, and they probably don't want to recompile
> just because there is an update of tkblt.
>
> There is a way in Debian that deals with updates of shared libraries
> (using SONAME); however for this I would need to patch tkblt anyway, and
> it also does not sound very "Tcl-ish".
>
> I am wondering, Tcl is such an mature language, with version 8.1 (where
> the stubs were introduced) 17 years old, and there is still no
> convenient way to generate them?
>

For the most part, it is *rare* for one *binary* extension* to make use of
*another* binary existension (this is the first *I* have every heard of doing
this). The *only* case *I* know of generally, is Tk, which like the core Tcl
does have a stubs library. The general practice is that every binary extension
is an 'island' that only calls Tcl_ or Tk_ functions (through the Tcl_ stubs
or Tk_ stubs). Everything is 'glued' together at the Tcl level. *Tcl* itself
is the 'glue' language.

Оlе Ѕtrеісhеr

unread,
Jun 4, 2016, 4:16:24 PM6/4/16
to
EL <elehm...@gmail.com> writes:
> Am 04.06.16 um 18:28 schrieb EL:
>> If BLT doesn't provide that yet, it would be a great and useful
>> extension. And I guess every BLT user would praise you :)
>
> Because then it is not only possible to load and use BLT into arbitrary
> C extensions.
> As a stubs enabled extension, BLT could also be used with *any* Tcl
> version >=8, without the need to recompile it.

This seems to work with tkblt "out of the box": it links to the Tcl and
Tk stubs only.

> That would mean that it is not anymore tied to a particular version of
> Tcl/Tk, finally.

Looks like so. However, tkblt is (as far as I know) not complete:
It includes only the Graph and Barchart Tk widgets, and the Tcl Vector
command.

https://github.com/SAOImageDS9/tkblt

> And furthermore it would also be possible to use BLT with starkits.

No idea.

Best regards

Ole

Оlе Ѕtrеісhеr

unread,
Jun 4, 2016, 4:21:46 PM6/4/16
to
Robert Heller <hel...@deepsoft.com> writes:
>> I am wondering, Tcl is such an mature language, with version 8.1 (where
>> the stubs were introduced) 17 years old, and there is still no
>> convenient way to generate them?
>
> For the most part, it is *rare* for one *binary* extension* to make use of
> *another* binary existension (this is the first *I* have every heard of doing
> this). The *only* case *I* know of generally, is Tk, which like the core Tcl
> does have a stubs library. The general practice is that every binary extension
> is an 'island' that only calls Tcl_ or Tk_ functions (through the Tcl_ stubs
> or Tk_ stubs). Everything is 'glued' together at the Tcl level. *Tcl* itself
> is the 'glue' language.

Wouldn't that be the case for every tcl package that somehow comes with
header files? Itcl was also already mentioned here. Itk as
well. tclexpect has header files. And many more... Header files imply
calling from C, which implies linking, which is done best (in the
"Tcl-is" way) via stubs, at least as I understand it from this thread.

Still wondering...

Best regards

Ole

EL

unread,
Jun 4, 2016, 5:22:05 PM6/4/16
to
Am 04.06.16 um 21:28 schrieb Robert Heller:

> For the most part, it is *rare* for one *binary* extension* to make use of
> *another* binary existension

No it isn't so rare. Its quite useful, to have this possibility.
Especially when you want to embed Tcl/Tk in a C program and use other C
based extensions, or when you want to code part of an application in
C(++) for speed reasons and need access to some C extensions for Tcl.

> *Tcl* itself is the 'glue' language.

Tcl's primary focus is also to be a DSL, embedded in some other
application. It was originally developed for this particular use case.


--
EL

EL

unread,
Jun 4, 2016, 5:44:03 PM6/4/16
to
Am 04.06.16 um 20:57 schrieb Оlе Ѕtrеісhеr:

> It is not BLT, but tkblt which is a subset only. And since I am not a
> Tcl guru, the chances that this happens are minimal unless there is a
> script that does the work for me.

I *think* the stubs.c and stubs.h files can be generated by a script
from definitions in a *.decls file. The TEA probably has such tools...
but the last time I looked at it was around 10 years ago.

The itcl.stubs file here looks like tcl script, which is meant to be
transformed in some way.

http://incrtcl.cvs.sourceforge.net/viewvc/incrtcl/incrTcl/itcl/generic/itclInt.decls?view=markup


--
EL

Robert Heller

unread,
Jun 4, 2016, 7:07:13 PM6/4/16
to
I will explain what *I* have done.

I have written some libraries in C++. And then I used SWIG to create a Tcl
binding. There are two ways to use these libraries:

1) Write a C++ program and then link with the library (eg g++ ... -l<mumble>).

2) Write a Tcl (/Tk) prorgam and [load] the library (eg [load lib<mumble>.so],
or [package require <mumble>]).

Normally you would NOT write some *other* Tcl extension and link that against
the lib<mumble>.so file and 99% of Tcl/Tk extensions don't expect to be used
that way. *Some* Tcl/Tk extensions can be used as plain old C/C++ libraries
with plain old C/C++ *programs* (no Tcl/Tk code at all) and those extensions
provide not only the library .so file (and pkgIndex.tcl file), but also header
files. If a binary extension is built with the stubs libraries, it is not
actually linked to Tcl/Tk, it is only linked to a *static* library that only
contains an *empty* jump table. If the "C/C++" API *does not* use the Tcl_/Tk_
API, then the library can be safely used from a pure C/C++ program. When one
(for example) uses SWIG to create the Tcl binding *only* the SWIG interface
code uses the Tcl API (via the stubs libraries). The only public (extern)
function exposed is the <mumble>_Init() function, which should only ever be
called from the Tcl [load] command. This function calls the stubs
initialization function (fills the jump table) and then calls
Tcl_Create..Command() function to define Tcl commands in the Tcl Interpeter
(thus 'creating' the Tcl bindings). SWIG creates the little functions that
Tcl_Create..Command() 'binds' to the Tcl command words -- these little
functions call the C/C++ functions using 'native' C/C++ calls.

It sounds like tkblt is much the same (I wonder if it uses SWIG...).

I belive the Itcl/Itk libraries have stubs, just like Tcl/Tk, and like Tcl/Tk
can be [loaded] or linked or *both* (via stubs libraries). I believe Itcl/Itk
can be used *instead* of Tcl/Tk.

>
> Still wondering...
>
> Best regards
>
> Ole
>

EL

unread,
Jun 5, 2016, 7:02:04 AM6/5/16
to
Am 05.06.16 um 01:07 schrieb Robert Heller:

> It sounds like tkblt is much the same (I wonder if it uses SWIG...).

As far as I see, tkblt is a fork of BLT, which is a pure C extension to
Tcl/Tk and does not connect external C(++) libraries. So there is no
need for SWIG here.

> I belive the Itcl/Itk libraries have stubs, just like Tcl/Tk, and like Tcl/Tk
> can be [loaded] or linked or *both* (via stubs libraries). I believe Itcl/Itk
> can be used *instead* of Tcl/Tk.

No. Itcl_InitStubs() is complementary to Tcl_InitStubs(), you need the
latter to have the former.
Clearly, the Itcl package exposes a C interface, which is meant to have
access to Itcl functionality on C level, in conjunction with the Tcl C
library. Its usage is described in the itcl-intro documentation here:

http://incrtcl.sourceforge.net/itcl/doc/itcl-intro.tar.gz

Page 64f. in the .ps file.

The OP is asking for such functionality in tkblt.


--
EL

EL

unread,
Jun 5, 2016, 7:22:03 AM6/5/16
to
Am 04.06.16 um 22:21 schrieb Оlе Ѕtrеісhеr:

> Wouldn't that be the case for every tcl package that somehow comes with
> header files?

Not necessarily. It depends on the extension author(s) and the intention
of the package. For Itcl the intention is very clearly to have that
functionality exposed on C level, but others might not be designed in
that way.
If there is a C header file, library and no stubs library, that means
the extension can be used the "old style", that is to include the header
and link against the library, with the maximum in platform, version and
installation dependence that is involved with this approach. You can do
that, but you loose quite a few advantages, as you've already found out.
But it used to be the way to go in the dark (middle 90's) ages.

As for tkblt, this is based on the very old BLT extension, which wasn't
touched in ages although it seems to be very useful.
At the time back when BLT was developed, there was obviously no need or
possibility to have a stubs library, or to expose BLT functionality for
other C extensions. So it is simply not there, because nobody has
implemented it. However, that doesn't mean that it couldn't be done now ;-).


--
EL

Оlе Ѕtrеісhеr

unread,
Jun 5, 2016, 7:33:57 AM6/5/16
to
EL <elehm...@gmail.com> writes:
> I *think* the stubs.c and stubs.h files can be generated by a script
> from definitions in a *.decls file. The TEA probably has such tools...
> but the last time I looked at it was around 10 years ago.

After some more investigation, I found out that at the and, it is not
*so* difficult: One needs a script genStubs.tcl which actually generates
the stub sources (tkbltDecls.h and tkbltStubInit.c) from an .decl file,
which looks like this:

-----------------------------------8<-------------------------------
library tkblt
interface tkblt
declare 0 generic {
int Blt_CreateVector(Tcl_Interp* interp, const char *vecName,
int size, Blt_Vector** vecPtrPtr)
}
...
-----------------------------------8<-------------------------------

And then one needs to create a tkbltStubLib.C file with mainly

-----------------------------------8<-------------------------------
#include <tcl.h>
void *tkbltStubsPtr;
CONST char * Tkblt_InitStubs(Tcl_Interp *interp, CONST char *version, int exact){
CONST char *result;

result = Tcl_PkgRequireEx(interp, "tkblt", version, exact,
(ClientData *) &tkbltStubsPtr);
if (!result || !tkbltStubsPtr) {
return (char *) NULL;
}

return result;
}
-----------------------------------8<-------------------------------

Then some other Voodoo (since [tk]blt is C++ and not C), the first two
files go into the tkblt.so and the last creates the libtkbltstub.a,
compile the dependent package with -DUSE_TKBLT_STUBS and voila: I have a
tksao that does not to be linked directly to the tkblt shared library.

More-or-less described here: http://wiki.tcl.tk/3358

I am wondering now why this is not the standard procedure for
extensions.

Remaining problem is just how I can tell TEA to autogenerate the stub
files from the .decl, and how TEA can be instructed to actually create
libtkbltstub.a. Just setting

TEA_ADD_STUB_SOURCES([src/tkbltStubLib.c])

is not enough. Any idea here?

Best regards

Ole

Rolf Ade

unread,
Jun 5, 2016, 7:50:58 AM6/5/16
to

ole-use...@gmx.net (Оlе Ѕtrеісhеr) writes:
> Remaining problem is just how I can tell TEA to autogenerate the stub
> files from the .decl, and how TEA can be instructed to actually create
> libtkbltstub.a. Just setting
>
> TEA_ADD_STUB_SOURCES([src/tkbltStubLib.c])
>
> is not enough. Any idea here?

You need also a few changes in Makefile.in. Take a look at an example,
what to do. tDOM would be one example of a TEA build extension, that
generates a stub library. Take a look at

https://core.tcl.tk/tdom/artifact/3965f5b535b48290

and see, if that helps.

Оlе Ѕtrеісhеr

unread,
Jun 5, 2016, 8:24:29 AM6/5/16
to
Rolf Ade <ro...@pointsman.de> writes:
> ole-use...@gmx.net (Оlе Ѕtrеісhеr) writes:
>> Remaining problem is just how I can tell TEA to autogenerate the stub
>> files from the .decl, and how TEA can be instructed to actually create
>> libtkbltstub.a. Just setting
>>
>> TEA_ADD_STUB_SOURCES([src/tkbltStubLib.c])
>>
>> is not enough. Any idea here?
>
> You need also a few changes in Makefile.in.

Thank you; I got it working. For reference, this is the pull request
with all the changes:

https://github.com/SAOImageDS9/tkblt/pull/2

Best regards

Ole

EL

unread,
Jun 5, 2016, 10:02:04 AM6/5/16
to
Am 05.06.16 um 14:24 schrieb Оlе Ѕtrеісhеr:

> Thank you; I got it working. For reference, this is the pull request
> with all the changes:
>
> https://github.com/SAOImageDS9/tkblt/pull/2

Good to see :).
You might want to notify the maintainers of tkblt on sourceforge, maybe
they are interrested in merging your changes into the tkblt sources.

https://sourceforge.net/projects/tkblt/


--
EL

Оlе Ѕtrеісhеr

unread,
Jun 5, 2016, 12:17:14 PM6/5/16
to
EL <elehm...@gmail.com> writes:
> Am 05.06.16 um 14:24 schrieb Оlе Ѕtrеісhеr:
>> https://github.com/SAOImageDS9/tkblt/pull/2
> Good to see :).
> You might want to notify the maintainers of tkblt on sourceforge, maybe
> they are interrested in merging your changes into the tkblt sources.
>
> https://sourceforge.net/projects/tkblt/

They are identical; I am in contact. No worry :-)

BTW, critical reviews are welcome...

Cheers

Ole
0 new messages