Very Computer

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.

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.

 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).

 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 ----+