Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-3401063 ] ldconfig was not ran, so libtcl8.5.so was not found later
|
From: SourceForge.net <no...@so...> - 2011-08-31 20:02:35
|
Bugs item #3401063, was opened at 2011-08-30 18:43 Message generated for change (Comment added) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3401063&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 50. Embedding Support Group: current: 8.5.10 Status: Open Resolution: None Priority: 5 Private: No Submitted By: joxy (joxy) Assigned to: Stuart Cassoff (stwo) Summary: ldconfig was not ran, so libtcl8.5.so was not found later Initial Comment: ubuntu 10.04 latest repos contain tcl 8.4.*; my machine had them installed. then (without uninstallation of tcl 8.4.*), i built tcl 8.5.10 from sources on ubuntu 10.04 (ubuntu was updated with latest stuff). tcl build line used was: $ ./configure --enable-threads --enable-shared --enable-symbols && make && make test && sudo make install all completed successfully. then, the program using tcl was built successfully. When ran, this program gave: error while loading shared libraries: libtcl8.5.so: cannot open shared object file: No such file or directory This seems to be a bug in tcl's make install: it didn't ran ldconfig at the end of installation (i.e. at the end of make install)... But I don't know for sure if this is tcl's duty to run ldconfig or not. When I consulted ld.so.conf.d, it had /usr/local/lib listed in libc.conf: $ cat /etc/ld.so.conf include /etc/ld.so.conf.d/*.conf $ cat /etc/ld.so.conf.d/libc.conf | grep local /usr/local/lib $ sudo ldconfig $ After that, the program referencing libtcl8.5.so found it successfully. ---------------------------------------------------------------------- >Comment By: Don Porter (dgp) Date: 2011-08-31 16:02 Message: And what would a patch look like that would make Tcl source distributions better match your expectations? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2011-08-31 16:01 Message: BTW, why is it that you're building from source, rather than using what Ubuntu distributes (which they've presumably adapted to their system conventions and expectations)? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2011-08-31 15:56 Message: So you're in the "don't use -rpath" camp. There's also a "must use -rpath" camp. I have no ability to resolve the long-raging debate., and it's impossible to make all happy. I'll leave the ticket open for someone better able than I am to comment further. I've offered what help I can. ---------------------------------------------------------------------- Comment By: joxy (joxy) Date: 2011-08-31 15:18 Message: 1. openmsx developers said that this tip (echo 'puts [tcl::pkgconfig get libdir,runtime]' | /path/to/tclsh) doesn't work for cross compilation... "in openMSX, we treat every build as a cross build; a native build is just a special cross build"... They also said: "we do find the tclConfig.sh though, but by trying various typical locations, not by executing the interpreter". --- But well, I don't want to discuss this particular issue, this is just for general information, a side thing which seems to be irrelevant to this tracker issue. 2. We discussed this issue with openmsx developers, and decided that openmsx binary's indirect reference to libtcl8.5.so (indirection via ld.so) is saner than a direct hardcoded full-file-name reference (to /usr/local/lib/libtcl8.5.so). So the conclusion I think is that TCL installer (TCL's make install) must configure the system and OS and ld.so so that ld.so would load libtcl8.5.so given the only string "libtcl8.5.so" string at appropriate place --- this string "libtcl8.5.so" must be the only information to be able to perform the indirect loading of "libtcl8.5.so". And currently TCL doesn't provide this. This is a defect. I think it is not the user's program's responsibility to configure the OS: to setup OS indirections related to TCL's internal configuration. And the path to the place where TCL's files reside is part of TCL's internal configuration. TCL must configure the OS so that libtcl8.5.so is findable. Do you agree? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2011-08-31 14:12 Message: Untested, but I think this is the recipe: LIB_RUNTIME_DIR should be in the Makefile (or whatever build scripts) of the openmsx program. It should be defined to hold the name of the directory where you found the tclConfig.sh file of the Tcl installation you are embedding in your program. Having done that, including $TCL_LD_SEARCH_FLAGS on your link line should take care of things. You seem to have been able to find the tclConfig.sh file, but if that's an issue, you can ask Tcl where it is: echo 'puts [tcl::pkgconfig get libdir,runtime]' | /path/to/tclsh ---------------------------------------------------------------------- Comment By: joxy (joxy) Date: 2011-08-31 13:44 Message: And the main point is to understand the best way to specify libtcl*.so exact filename for openmsx. It is either via ldconfig, or via -rpath (if the latter is possible at all). And the question in the first case (ldconfig's): who is responsible to run ldconfig? And when. ---------------------------------------------------------------------- Comment By: joxy (joxy) Date: 2011-08-31 13:42 Message: It's a failure of ld.so when called or referenced (directly or indirectly) by openmsx binary in order to load "libtcl8.5.so". ld.so fails to find libtcl8.5.so because neither openmsx nor ld.so know the path to libtcl8.5.so at runtime. Yes, kind of like that, it's "a failure of another program". I don't know what tclsh does. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2011-08-31 13:37 Message: joxy, so your complaint is not about a failure of the tclsh program installed by Tcl? It's a failure of another program that embeds and links to Tcl? I think that's a point of confusion. ---------------------------------------------------------------------- Comment By: joxy (joxy) Date: 2011-08-31 13:36 Message: If you specify where to dig, I could dig. Currently, the digging area is too broad -- please narrow... I'm not familiar with build systems of tcl and openmsx. ---------------------------------------------------------------------- Comment By: joxy (joxy) Date: 2011-08-31 13:31 Message: Comment title: Linker options for both tcl's make and for a program. (A program is openmsx, and openmsx chat log connected with this tcl tracker item is here -- might have some details: https://sourceforge.net/tracker/?func=detail&aid=3401010&group_id=38274&atid=421861 ) 1. openmsx's ldflags: TCL_LDFLAGS:=-L/usr/local/lib (So openmsx's build process found a correct location for TCL8.5.) 2. tcl's ldflags: Lines from /usr/local/lib/tclConfig.sh (attached to this tracker item): # Flags to pass to ld, such as "-R /usr/local/tcl/lib", that tell the # run-time dynamic linker where to look for shared libraries such as # libtcl.so. Used when linking applications. Only works if there # is a variable "LIB_RUNTIME_DIR" defined in the Makefile. TCL_CC_SEARCH_FLAGS='-Wl,-rpath,${LIB_RUNTIME_DIR}' TCL_LD_SEARCH_FLAGS='-Wl,-rpath,${LIB_RUNTIME_DIR}' This does not specify which Makefile must define this LIB_RUNTIME_DIR variable. ---------------------------------------------------------------------- Comment By: joxy (joxy) Date: 2011-08-31 13:15 Message: A typo: The item 2 in prev.msg. is supposed to be: "It seems that in Linux, there is no standard location for tcl's libtcl8.*.so". ---------------------------------------------------------------------- Comment By: joxy (joxy) Date: 2011-08-31 13:13 Message: I don't comprehend what your pronouns refer to. 1. "What linker options did it actually use?" Here, "it"=tcl's 'make' process OR "it"=a program that is using tcl? (In my next comment, I will try to list linker options for both tcl's make and for a program.) 2. "the -rpath option". It seems that in Linux, there is not standard location for tcl's libtcl8.*.so: in Ubuntu lucid repos, it is /usr/lib, and in the defaults of source package of tcl8.5, it is /usr/local/lib: $ ls /usr/lib/libtcl8.4.so /usr/lib/libtcl8.4.so $ ls /usr/local/lib/libtcl8.5.so /usr/local/lib/libtcl8.5.so $ Therefore, the user program cannot know where to search for libtcl*.so in a 'standard' tcl installation. Therefore, some mechanism like ld.so's path database (/etc/ld.so.conf) must be used. 3. "this should be enabled by default; it needs to be switched off for a build for a Linux distro though)." Here, what phrase "this" refers to? And also: what phrase "it" refers to? ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2011-08-31 05:23 Message: What linker options did it actually use? (The configuration system is tricky enough that I don't try to second guess what it did.) AIUI, we're supposed to be passing in the -rpath option to the linker so that the binary knows where the libs are without running ldconfig (and this should be enabled by default; it needs to be switched off for a build for a Linux distro though). ---------------------------------------------------------------------- Comment By: joxy (joxy) Date: 2011-08-30 18:48 Message: uname -a: Linux name1 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:08:37 UTC 2011 i686 GNU/Linux Problematic Behavior: ldconfig was not run by 'make install' process of tcl. Expected Behavior: ldconfig is run by 'make install' process of tcl. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3401063&group_id=10894 |