Need help with Tcl7.6/Tk4.2, gcc, FORTRAN/C/C++ shared libraries (LONG)

Need help with Tcl7.6/Tk4.2, gcc, FORTRAN/C/C++ shared libraries (LONG)

Post by Eric M. Boe » Sat, 22 Feb 1997 04:00:00



I have had an assortment of problems using shared libraries for dynamic
loading with Tcl/Tk. I'll try to keep this brief but there is a lot to go
through. I have had to go through some real contortions to get things to
work. I am hoping that someone can give me a better, simpler way.

I am using gcc/g++/libg++ 2.7.2. SparcCompiler 3.0.1 for FORTRAN under Solaris
2.5.1.

I started having problems after I built a shared library for tree 4.1
(C++). When I tried "load libTkTree4.1.so" I got error messages about
unresolved symbols that were in libstdc++.

I searched dejanews and came up with the following answers:
1. Build libg++ as a shared library
2. When building shared libraries, don't call the linker directly. Use the
   compiler and pass the right flags to the linker.

I rebuilt Tcl/Tk and tree with these modifications. When I tried to load tree,
I still have unresolved symbols (__register_exceptions). This symbol is in
libgcc.a.

I believe the problem stems from the fact that the main interpreter was linked
with gcc  and that normal linking doesn't bring in symbols that aren't
needed/referenced.

In any event, after linking the main interpreter with g++, this problem
appeared to be solved. This might not have been necessary had I linked the
shared library with the main interpreter -- but that shouldn't be necessary.

Now, the situation becomes more complex. I also have a shared library with
several FORTRAN modules as well as a C module that is the interface between
Tcl/Tk and the FORTRAN code.

Again, when I try to load the FORTRAN, I get unresolved symbols. I was able to
get around part of it by linking libM77.so.2 and libI77.so.2 shared libraries
with my shared library. After this, I was still missing routines in
libsunmath.a. I couldn't link this with the shared library because of text
relocation errors.

Linking the main interpreter with libsunmath.a also had no effect (it didn't
bring in the required routines). I had to link the main interpreter with
libsunmath.a AND my FORTRAN shared library.

The final configuration is to use g++ to link that main interpreter and also
link in libsunmath.a and my FORTRAN shared library.

This seems like a lot of work to go through. It also seems to defeat the
purpose of shared libraries since I end up with all these dependencies that
are difficult to resolve. The linker seem to be "too smart" and it is
difficult to get it to do the right thing.

If anyone has hints or suggestions, I would greatly appreciate it.
--

Senior System Analyst                         Engineous Software, Inc.

 
 
 

Need help with Tcl7.6/Tk4.2, gcc, FORTRAN/C/C++ shared libraries (LONG)

Post by Frank Pilhof » Sun, 23 Feb 1997 04:00:00



Quote:>I believe the problem stems from the fact that the main interpreter was linked
>with gcc  and that normal linking doesn't bring in symbols that aren't
>needed/referenced.

 Right. Unfortunately, this problem -- dynamically loadable shared
libraries depending on other, non-shared libraries, does not have a
simple solution. You have done about the best things possible; every
potential solution is, in a way, ugly.

 For example, the missing __register_exceptions symbol from libgcc.a
could be solved by recompiling libgcc into a shared library. Or, if
this is a function, you could grab its code from the gcc sources and
add them to your modules. Sounds like a hack? It is.

[about Fortran modules]

Quote:

>Linking the main interpreter with libsunmath.a also had no effect (it didn't
>bring in the required routines).

 This is because Tcl does not need any functions from this library, so
the linker does not add that library. However, there's a trick around
this -- the linker only performs selective linking with libraries, but
not with object files.
 A workaround is to extract all object files from the library (use ar)
and to hard-link them into the Tcl core.

 You see, the main problem is that non-shared functions can *only*
be resolved from the main executable as they cannot be dynamically
linked on demand, and there's no way around this. This problem will
haunt us as long as static libraries exist.

        Frank

--

 |                                      http://www.uni-frankfurt.de/~fp/ |
 +---- Life would be a very great deal less weird without you.  - DA ----+

 
 
 

1. Tcl7.4/Tk4.0 extension a.out shared libraries

Noting the lack of binary a.out extension libraries for the latest
Tcl/Tk release, I built a set.  I'd like to share, but I need assigned
addresses for most of them (my shared infomagic tclX library is at an
address that now loses with Tk4.0, so I had to move it).

Who is the contact for such matters?

Does anybody still care about a.out format?
--

2. dos,win98,winNT and Linux

3. Building Tcl7.4/Tk4.0 as shared libraries in Linux?

4. Setting the command prompt to reflect PWD

5. Linux-Makefile shared [Tcl7.4/Tk4.0]b4 libs, used by tclsh+wish

6. Newbie Needs Help ON Three Points PLEASE

7. help with tcl7.5 tk4.1

8. bitslice & crypt(3) choice

9. Help needed with C++ libraries & gcc/g++

10. Help with C++ Debuggers - need to load huge shared libraries

11. How to: tcl7.5a1 and tk4.1a1 for Linux ELF

12. Need help on AIX with gcc & shared library development

13. Compiling tcl7.4 and tk4.0 under LInux for ELF