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

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

Post by Steven L. Ba » Wed, 23 Aug 1995 04:00:00



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

 
 
 

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

Post by N J Andrew » Sat, 26 Aug 1995 04:00:00



: 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?

Well, I did; I even picked up some aout binaries only to find that they
were compiled for libc4.6.x which I didn't have and had so much difficulty
compiling with gcc 2.5.8 that I gave up in the end and am re-installing
my system with a new distribution because I can tell that it's going to
be too frustrating to attempt to make the upgrade to elf by hand.

Nigel

Looking silly - as usual.

Sorry for the long sentence but I got wound up no end by the number of
libraries I tried to use that either insisted on using libraries I didn't
have and not being able to build those other libraries because the aout build
was for later versions of libraries or compilers or for an elf based system
that had an aout compiler.

------------------------------------------------------------------------
Nigel J. Andrews                                   Tel: +44 191 374 2105
Astronomical Instrumentation Group                 Fax: +44 191 374 3749
Physics Department
University of Durham
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                   REAL programmers do it on a bus
------------------------------------------------------------------------

 
 
 

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

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.

2. Unix Guros - Help

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

4. The Evil Empires toadies don't even understand their scripts

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

6. Linking to Libraries on LD_LIBRARY_PATH:

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

8. pppd-2.2.0e

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

10. When to get tcl7.6 and tk4.2 ?

11. tcl7.5, tk4.1, scotty-2.1.5, linux 2.0.22

12. problems compiling uudeview code with tcl7.5/tk4.1

13. tkgnuplot for tcl7.4/tk4.0/Tix4.0?