Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-541181 ] gcc compiled Tcl library needs libgcc
|
From: SourceForge.net <no...@so...> - 2004-11-17 19:28:17
|
Bugs item #541181, was opened at 2002-04-08 15:54 Message generated for change (Settings changed) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=541181&group_id=10894 Category: 51. Configure and Build Tools Group: obsolete: 8.4a5 Status: Open Resolution: Fixed Priority: 8 Submitted By: Don Porter (dgp) >Assigned to: Don Porter (dgp) Summary: gcc compiled Tcl library needs libgcc Initial Comment: CC -ptr./solaris -staticlib=Crun solaris/omfsh.o -L../../pkg/if/solaris -lif -L../../pkg/nb/solaris -lnb -L../../pkg/oc/solaris -loc -L/home/fs3c/dgp/sparc/solaris2/lib -ltk8.4 -L/home/fs3c/dgp/sparc/solaris2/lib -ltcl8.4 -L/usr/openwin/lib -lX11 -ldl -lsocket -lnsl -lm -o solaris/omfsh Undefined first referenced symbol in file __ashldi3 /home/fs3c/dgp/sparc/solaris2/lib/libtcl8.4.so __ashrdi3 /home/fs3c/dgp/sparc/solaris2/lib/libtcl8.4.so __floatdidf /home/fs3c/dgp/sparc/solaris2/lib/libtcl8.4.so ld: fatal: Symbol referencing errors. No output written to solaris/omfsh ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2004-11-17 13:59 Message: Logged In: YES user_id=80530 FWIW, this problem has shown up again on the HEAD. ---------------------------------------------------------------------- Comment By: Reinhard Max (rmax) Date: 2002-07-01 11:37 Message: Logged In: YES user_id=124643 Just for completeness. It is allowed to link libgcc.a to binaries that are not GPL, or not even open source. The C file for libgcc.a contains a comment, that says: In addition to the permissions in the GNU General Public License, the Software Foundation gives you unlimited permission to link the compiled version of this file into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. (The General Public License restrictions do apply in other respects; for example, they cover modification of the file, and distribution when not linked into a combine executable. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-06-28 16:51 Message: Logged In: YES user_id=80530 It appears that what must change is what gets run during the ${TCL_LIB_FILE} target. The key line is ${SHLIB_LD} -o $@ ${OBJS} ${LIBS} Perhaps {SHLIB_LD} needs to be some kind of invocation of gcc rather than /usr/ccs/bin/ld ? Or perhaps LIBS needs to include -L... -lgcc, but somehow, keep those additions out of the TCL_LIBS variable in tclConfig.sh ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-06-27 15:56 Message: Logged In: YES user_id=80530 OK, the linker options required are just to include libgcc among the items linked together to produce the Tcl shared library. I achieved success adding the appropriate -L... -lgcc to the MATH_LIBS, but that's not the right solution within the Makefile architecture. Can someone advise the better way? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-06-27 11:40 Message: Logged In: YES user_id=80530 Yes, of course. But that answer translates to "you cannot use gcc to build a binary distro of Tcl". The root of the problem is probably bad design choices in gcc, but if we can work around them it would be a good idea. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2002-06-27 06:17 Message: Logged In: YES user_id=79902 However, building with SunPro cc on Solaris should produce code that doesn't require these functions. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2002-06-27 04:33 Message: Logged In: YES user_id=79902 Linker options are not my specialty. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-06-27 01:06 Message: Logged In: YES user_id=80530 The missing symbols are routines supplied by gcc for doing math on "long long" values. The implementation of these routines is in libgcc.a, so the linking of the embedding application can be completed by adding that library to those linked, as Andreas suggested before. Note that I see this problem with both gcc-2.95.2 and gcc-3.0.3. It is a new problem because of new "long long" code within Tcl, not because of a change in compiler. So, one approach to fix this would be to see that the appropriate -L... -lgcc options get added to the TCL_LIBS value in tclConfig.sh. Another might be to require embedders to use the TCL_CC compiler recorded in tclConfig.sh. Neither of those is really a satisfactory answer though, because it requires the embedder to use the same toolset as the library builder. It would be better if the binary Tcl and Tk libraries could be distributed in a binary distribution for embedding into applications possibly by a different toolset. So, it would be best to find some options to pass to the linker during the construction of libtcl8.4.so that force it to pull the math support code out of libgcc and put it directly into libtcl8.4.so. (I'm assuming that libgcc is LGPL). Anyone know linker options well enough to proceed along that path? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-06-26 16:36 Message: Logged In: YES user_id=80530 Re-opening this. I'm seeing the same problem with the 8.4b1 sources. Investigating... ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2002-06-07 06:42 Message: Logged In: YES user_id=79902 OK, I think tclExecute.c is now right; any faults now are probably to do with the build system and/or not running configure and/or something else which I don't understand. (Doesn't mean I understand what those error messages really are though! :^)) ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2002-06-07 05:18 Message: Logged In: YES user_id=79902 Well, I've tried examining what the various definitions for FLT_MAX (and DBL_MAX) are on various platforms (Solaris/SPARC, Linux/ix86, and IRIX64 in both 32bit and 64-bit mode) and all report the same values: FLT_MAX=3.4028234663852886e+38 DBL_MAX=1.7976931348623157e+308 Examining the code, so long as "tclPort.h" is #included, we don't need to explicitly #include <float.h> anyway. But tclExecute.c is somewhat bizarre here. Will have a go at fixing it anyway. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2002-06-04 14:57 Message: Logged In: YES user_id=148712 We could safely eliminate <float.h> everywhere in the unix branch if we make sure that FLT_MAX is defined properly in unix/tclUnixPort.h. I do not really know what a good generic definition for FLT_MAX would be. I wonder if the default defined in unix/tclUnixPort.h is OK for all platforms or it is just a "safe" default. Donal: do you know? ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2002-04-26 18:09 Message: Logged In: YES user_id=148712 Those #include are in since the very first version on SF (1.1); what's more, compat/float.h has been empty since those days too! So: what is actually the point of #ifdef NO_FLOAT_H # include "../compat/float.h" #else # include <float.h> #endif Also, unix/tclUnixPort.h includes <float.h> to define FLT_MAX (used in generic/tclBinary.c) and FLT_MIN (unused); if float.h is not available, it tries <values.h>; if that is not available either, it defines default values that almost coincide with what I find in my /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/float.h Note that FLT_MAX is only used in [binary format], to represent too-large single-precision floats. So: what is really the point of <float.h> in tcl? Note: win/tclWinPort.h also includes <float.h>. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-04-26 16:30 Message: Logged In: YES user_id=80530 ditto on Soaris 8 ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2002-04-26 16:02 Message: Logged In: YES user_id=148712 Beats me; commenting out lines 20-24 compiles OK and passes the test suite on linux. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2002-04-26 15:58 Message: Logged In: YES user_id=75003 Bytecompiled expressions ? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-04-26 15:31 Message: Logged In: YES user_id=80530 Tracing futher, it appears the root of the trouble is the #include <float.h>. Why does tclExecute.c need that header file? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-04-26 15:25 Message: Logged In: YES user_id=80530 Perhaps, but if additional libraries are required for successful static linking against the Tcl library, those libraries should be part of the TCL_LIBS definition in tclConfig.sh. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2002-04-26 12:47 Message: Logged In: YES user_id=75003 The missing thing could be that the tcl library was not linked against -lgcc, i.e. the gcc support library. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2002-04-26 08:50 Message: Logged In: YES user_id=148712 I don't even know where to start looking; anybody to whack me with a big clue-by-four? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-04-08 16:26 Message: Logged In: YES user_id=80530 I traced the problem to a compiler/linker mismatch. The Tcl library was compiled with gcc, but the program that embeds Tcl was compiled with the Sun Workshop compiler. That difference seems to cause the trouble. When I compiled both with the Sun compiler, everything worked fine. So, I do have a workaround, but it seems to me that compiler matching should not be necessary. That is, the shared libraries produced by Tcl's build process ought to be able to be linked into programs using any compiler -- at least on reasonable operating systems... ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-04-08 15:57 Message: Logged In: YES user_id=80530 These symbols seem to come in due to generic/tclExecute.c. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=541181&group_id=10894 |