• Re: package requiere Mk4tcl

    From Roderick@21:1/5 to Roderick on Wed Dec 15 20:42:07 2021
    Compiling Mk4tcl with clang the error is similar, but not identical:

    # /usr/opt/tcl84/bin/tclsh8.4
    % package require Mk4tcl
    couldn't load file "/usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so": /usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so: Undefined symbol "__cxa_pure_virtual"


    On Wed, 15 Dec 2021, Roderick wrote:


    Ehat does the following error mean?

    # tclsh8.4
    % package require Mk4tcl
    couldn't load file "/usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so": /usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so: Undefined symbol "_ZTVN10__cxxabiv117__class_type_infoE"
    %

    Thanks for any hint!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roderick@21:1/5 to Rich on Wed Dec 15 21:06:50 2021
    On Wed, 15 Dec 2021, Rich wrote:

    Roderick <hruodr@gmail.com> wrote:

    Ehat does the following error mean?

    # tclsh8.4
    % package require Mk4tcl
    couldn't load file "/usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so": >> /usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so: Undefined symbol
    "_ZTVN10__cxxabiv117__class_type_infoE"
    %

    Best guess, based on the cxx in the middle, is a missing, or
    incompatible C++ library.

    What does ldd report for libMk4tcl2.4.9.7.so:

    ldd /usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so

    # ldd /usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so /usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so:
    #

    Interesting. No dependency, but needs a library!!!!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roderick@21:1/5 to All on Wed Dec 15 20:34:08 2021
    Ehat does the following error mean?

    # tclsh8.4
    % package require Mk4tcl
    couldn't load file "/usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so": /usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so: Undefined symbol "_ZTVN10__cxxabiv117__class_type_infoE"
    %

    Thanks for any hint!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to Roderick on Wed Dec 15 21:04:57 2021
    Roderick <hruodr@gmail.com> wrote:

    Ehat does the following error mean?

    # tclsh8.4
    % package require Mk4tcl
    couldn't load file "/usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so": /usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so: Undefined symbol "_ZTVN10__cxxabiv117__class_type_infoE"
    %

    Best guess, based on the cxx in the middle, is a missing, or
    incompatible C++ library.

    What does ldd report for libMk4tcl2.4.9.7.so:

    ldd /usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roderick@21:1/5 to Rich on Wed Dec 15 21:24:33 2021
    On Wed, 15 Dec 2021, Rich wrote:

    Hmm, unexpected. I expected to find ldd indicating that it requested another, missing, library.

    Did you compile libMk4tcl2.4.9.7.so yourself, or was it already
    compiled? If already compiled then it looks like maybe a version
    missmatch with your Tcl binary files. But that's largely a guess on my
    part, and this is rapidly exceeding my knowledge of how shared object
    linking at runtime operates.

    I compiled myself. No, it is not missmatch. I compiled it many times
    before, with the same tcl84.

    What changed is the environement, the OS version, the compiler.

    Strange.

    R.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to Roderick on Wed Dec 15 21:22:00 2021
    Roderick <hruodr@gmail.com> wrote:

    On Wed, 15 Dec 2021, Rich wrote:

    Roderick <hruodr@gmail.com> wrote:

    Ehat does the following error mean?

    # tclsh8.4
    % package require Mk4tcl
    couldn't load file "/usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so": >>> /usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so: Undefined symbol
    "_ZTVN10__cxxabiv117__class_type_infoE"
    %

    Best guess, based on the cxx in the middle, is a missing, or
    incompatible C++ library.

    What does ldd report for libMk4tcl2.4.9.7.so:

    ldd /usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so

    # ldd /usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so /usr/opt/tcl84/lib/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.so:
    #

    Interesting. No dependency, but needs a library!!!!

    Hmm, unexpected. I expected to find ldd indicating that it requested
    another, missing, library.

    Did you compile libMk4tcl2.4.9.7.so yourself, or was it already
    compiled? If already compiled then it looks like maybe a version
    missmatch with your Tcl binary files. But that's largely a guess on my
    part, and this is rapidly exceeding my knowledge of how shared object
    linking at runtime operates.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to Roderick on Wed Dec 15 23:11:42 2021
    Roderick <hruodr@gmail.com> wrote:

    On Wed, 15 Dec 2021, Rich wrote:

    Hmm, unexpected. I expected to find ldd indicating that it requested
    another, missing, library.

    Did you compile libMk4tcl2.4.9.7.so yourself, or was it already
    compiled? If already compiled then it looks like maybe a version
    missmatch with your Tcl binary files. But that's largely a guess on my
    part, and this is rapidly exceeding my knowledge of how shared object
    linking at runtime operates.

    I compiled myself. No, it is not missmatch. I compiled it many times
    before, with the same tcl84.

    What changed is the environement, the OS version, the compiler.

    Strange.

    Very much so. Unfortunately I'm out of suggestions to try with the
    news that you compiled it yourself. That should have resulted in a
    working library.

    Maybe someone else here will have some useful suggestions.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Christian Gollwitzer@21:1/5 to All on Thu Dec 16 08:12:25 2021
    Am 15.12.21 um 22:24 schrieb Roderick:

    On Wed, 15 Dec 2021, Rich wrote:

    Hmm, unexpected. I expected to find ldd indicating that it requested
    another, missing, library.

    I compiled myself. No, it is not missmatch. I compiled it many times
    before, with the same tcl84.

    What changed is the environement, the OS version, the compiler.

    2 questions

    1) Is there a strong reason that you want Tcl 8.4 instead of a modern 8.6??

    2) If you can use 8.5 or 8.6, maybe you can use an automated build
    system. For example, this fork of kbs could work:

    https://github.com/auriocus/kbskit

    I haven't tried it on *BSD, it works on Linux, though.

    Christian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roderick@21:1/5 to Christian Gollwitzer on Thu Dec 16 07:54:26 2021
    On Thu, 16 Dec 2021, Christian Gollwitzer wrote:

    1) Is there a strong reason that you want Tcl 8.4 instead of a modern 8.6??

    It is to run an old, but very important piece of software (Grimms
    German Dictionary in CD ROM), not written by me, I need:

    tcl8.4.20
    tk8.4.20
    Tix8.4.3
    BLT2.4z
    metakit-2.4.9.7
    mkZiplib10

    I always run it with that, taking new version I may get incompatibilities. Trying to compile metakit with tcl8.6 I get other errors.

    2) If you can use 8.5 or 8.6, maybe you can use an automated build system.

    I would be glad to have less dependencies ...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roderick@21:1/5 to Rich on Thu Dec 16 09:03:35 2021
    On Wed, 15 Dec 2021, Rich wrote:

    I compiled myself. No, it is not missmatch. I compiled it many times
    before, with the same tcl84.

    What changed is the environement, the OS version, the compiler.

    Strange.

    Very much so. Unfortunately I'm out of suggestions to try with the
    news that you compiled it yourself. That should have resulted in a
    working library.

    Maybe someone else here will have some useful suggestions.

    After googling I found a possible explanation, but still no solution:

    https://blog.spacepatroldelta.com/a?ID=00950-8a2a00e1-a7b6-47e8-a49b-7df1de18b2c5

    It may have to do with the inflation of C and C++ compilers and
    run time libraries in the system.

    But changing LDFLAGS, CC in ./configure till now does not work.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roderick@21:1/5 to Roderick on Thu Dec 16 11:06:50 2021
    I added manually at the last step of the building process of Mk4tcl:
    -lc++

    Namely

    ld -Bshareable -x -o libMk4tcl2.4.9.7.so column.o custom.o derived.o
    field.o fileio.o format.o handler.o persist.o remap.o std.o store.o
    string.o table.o univ.o view.o viewx.o mk4tcl.o mk4too.o
    -L/usr/opt/tcl84/lib -ltclstub84 -lc++

    With this it worked. I have no idea why now a c++ is necessary.
    Mk4tcl became "bitroten" because changes made to gcc.

    No, I I get this effect with configure?

    The following did *not* add -lc++ at that position:

    configure --prefix=/usr/opt/tcl84 --enable-threads \
    --with-tcl=/usr/opt/tcl84/lib \
    CFLAGS="-L/usr/local/lib/gcc10 -lc++" \
    LDFLAGS="-L/usr/local/lib/gcc10 -lc++" CC=g++

    Also to set previously the environement?

    R.




    On Thu, 16 Dec 2021, Roderick wrote:


    On Wed, 15 Dec 2021, Rich wrote:

    I compiled myself. No, it is not missmatch. I compiled it many times
    before, with the same tcl84.

    What changed is the environement, the OS version, the compiler.

    Strange.

    Very much so. Unfortunately I'm out of suggestions to try with the
    news that you compiled it yourself. That should have resulted in a
    working library.

    Maybe someone else here will have some useful suggestions.

    After googling I found a possible explanation, but still no solution:

    https://blog.spacepatroldelta.com/a?ID=00950-8a2a00e1-a7b6-47e8-a49b-7df1de18b2c5

    It may have to do with the inflation of C and C++ compilers and
    run time libraries in the system.

    But changing LDFLAGS, CC in ./configure till now does not work.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ralf Fassel@21:1/5 to All on Thu Dec 16 15:05:22 2021
    * Roderick <hruodr@gmail.com>
    | The following did *not* add -lc++ at that position:

    | configure --prefix=/usr/opt/tcl84 --enable-threads \
    | --with-tcl=/usr/opt/tcl84/lib \
    | CFLAGS="-L/usr/local/lib/gcc10 -lc++" \
    | LDFLAGS="-L/usr/local/lib/gcc10 -lc++" CC=g++

    | Also to set previously the environement?

    Depends on how the 'configure' is written, but typically these UPPERCASE
    are taken from the environment, so you need to change the order to

    LDFLAGS="-L/usr/local/lib/gcc10 -lc++" CC=cc ./configure ...

    Note that listing linker flags like -L and -l in CFLAGS usually makes no
    sense, since CFLAGS is meant for *compilation* flags like -g or -O.

    HTH
    R'

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roderick@21:1/5 to Ralf Fassel on Thu Dec 16 14:38:37 2021
    On Thu, 16 Dec 2021, Ralf Fassel wrote:

    Note that listing linker flags like -L and -l in CFLAGS usually makes no sense, since CFLAGS is meant for *compilation* flags like -g or -O.

    I put there for the case that it compiles and links with gcc.
    I do not know if LDFLAGS would have been enough in that case.

    These configure scripts are a mystery for me. I have no idea
    what they exactly do. As long as they work it is all very easy,
    no need to edit Makefiles, etc.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ralf Fassel@21:1/5 to All on Thu Dec 16 16:19:11 2021
    * Roderick <hruodr@gmail.com>
    | These configure scripts are a mystery for me. I have no idea
    | what they exactly do. As long as they work it is all very easy,
    | no need to edit Makefiles, etc.

    Rest assured, you're not alone with this :-))) I once tried to follow
    the flow in some ./configure, but gave up after my colleague said
    "what's that weird look on your face, what about the twitching, and why
    are you drooling?" *bg*

    R'

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helmut Giese@21:1/5 to Roderick on Fri Dec 17 20:23:12 2021
    Roderick <hruodr@gmail.com> schrieb:


    On Thu, 16 Dec 2021, Christian Gollwitzer wrote:

    1) Is there a strong reason that you want Tcl 8.4 instead of a modern 8.6??

    It is to run an old, but very important piece of software (Grimms
    German Dictionary in CD ROM), not written by me, I need:

    tcl8.4.20
    tk8.4.20
    Tix8.4.3
    BLT2.4z
    metakit-2.4.9.7
    mkZiplib10

    I always run it with that, taking new version I may get incompatibilities. >Trying to compile metakit with tcl8.6 I get other errors.

    2) If you can use 8.5 or 8.6, maybe you can use an automated build system.

    I would be glad to have less dependencies ...
    Hi,
    I'm a bit late, but how about solving your problem once and for all
    (?) by means of a virtual machine?
    - take an OS version where everything was still ok,
    - create a VM running this OS and
    - install your Tcl program in there.
    As long as this VM will be supported by future versions of your OS you
    should be fine.
    Just my 2 € cents.
    Helmut

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roderick@21:1/5 to Helmut Giese on Sat Dec 18 10:40:00 2021
    On Fri, 17 Dec 2021, Helmut Giese wrote:

    I'm a bit late, but how about solving your problem once and for all
    (?) by means of a virtual machine?

    Yes, that may be the use of virtual machines is a solution for the
    future, when there is no other chance.

    But it is a program for consulting a dictionary that is also in the
    internet. Then I have to decide between using my slow internet
    connection or booting a system only for seeing a word entry.

    Rod.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helmut Giese@21:1/5 to All on Sat Dec 18 17:47:31 2021
    Yes, that may be the use of virtual machines is a solution for the
    future, when there is no other chance.

    But it is a program for consulting a dictionary that is also in the
    internet. Then I have to decide between using my slow internet
    connection or booting a system only for seeing a word entry.

    Rod.
    Hi,
    'booting a system'?
    I don't know about Linux but on Windows when I close a VM I can decide
    whether to
    - turn off the machine completely,
    - save the current state or
    - just quit.
    So my suggestion would be:
    - You create a virtual machine,
    - you boot it and start your app
    - and then you close it /in this state/.

    Then you tell / teach your users to install the VM manager program,
    send them the VM you created and tell them never to close the VM using
    option 1.
    To use it they would have to
    - start the VM manager and
    - start the VM.
    And since you saved the VM with your program up and running they will
    find themselves just in this state.

    On Windows I would know how to always do step (1) on startup and
    minimize the manager (in these days one shouldn't have to care about
    one more program lingering in the background).
    And if you could automate both steps your users would probably kiss
    your feet in gratitude :) : To start your program they only need to
    activate (bring to front) the VM. No more loading and initialising
    your app - this has already been taken care of.
    HTH
    Helmut

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)