Mailing List ArchiveSupport open source code!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: tlug: Acrobat reader and libXt
- To: TLUG mailing list <tlug@example.com>
- Subject: Re: tlug: Acrobat reader and libXt
- From: "Stephen J. Turnbull" <turnbull@example.com>
- Date: Sun, 17 Jan 1999 18:04:17 +0900 (JST)
- Content-Transfer-Encoding: 7bit
- Content-Type: text/plain; charset=us-ascii
- In-Reply-To: <Pine.LNX.3.96.990117015730.2365B-100000@example.com>
- References: <Pine.LNX.3.96LJ1.1b7.990117010900.563I-100000@example.com><Pine.LNX.3.96.990117015730.2365B-100000@example.com>
- Reply-To: tlug@example.com
- Sender: owner-tlug@example.com
>>>>> "kyomu" writes: kyomu> On Sun, 17 Jan 1999, Jonathan Byrne wrote: >> I just installed Acrobat reaader for Linux 3.01, and when I run >> it, it says "can't load libary 'libXt.s0.6' and dies. Can >> somebody clue me in as to what libXt.so.6 is, where it should >> be, and if it's normal for that to not be in TurboLinux >> (3.0-J)? Just blow off the libXt stuff and wait for Adobe to get its shit together and put out a glibc version of Acrobat is my advice. There may already be one on the server, go look. Or use gv over Aladdin Ghostscript >= 5.10. If you really want to know, "read on, MacDuff". >> Oh, and what to do about getting libXt.so.6, too :-) kyomu> i am not really sure but.... but it should be in kyomu> your /usr/X11R6/lib/ or in your /usr/ix86-linuxaout/lib/. kyomu> It usually gos in /usr/ix86-linuxaout/lib, and it is kyomu> used to provide backwards compatibility for dynamically kyomu> linked a.out format X binaries. (i think...) I beg to differ :-) First of all, it has nothing to do with a.out format. There probably is a backwards-compatibility issue here, but it's H.J.Liu libc5 against the forces of Good and Light, aka Uli Drepper's GNU libc "ta da!" Version Two-point-X. (1) Where do libraries live? Libraries can live almost anywhere. Fortunately, the ones that do live in arbitrary places are either statically linked or come with wrapper scripts to load them up (eg the original liblocale.so for muriyari Netscrap). DLLs (.so) live where the dynamic linker ld.so can find them. This is configured via /etc/ld.so.conf. `cat /etc/ld.so.conf' will give you a list of the standard directories where .so's are found. `man ld.so' should (and does on Debian systems) give you details about hairy options and environment variables to modify this basic behavior, but probably will not (TurboLinux should be taken out behind the woodshed about its documentation, /usr/doc is populated with all sorts of wonderful information about window managers I don't use, but nothing about ld.so, and `man' and `info' often come up empty...). To find out if ld.so knows about a particular library, and if so where the versions it will use live, use `ldconfig -p' (a non-root user may need to do `/sbin/ldconfig -p'): ldconfig -p | fgrep libXt.so Output is omitted to encourage you to try this out at home. It's not dangerous, really. (2) What does "can't load library ..." mean? It means "I can't find a file with the name ... that matches the object format (a.out DLL or ELF) and version information (major should match exactly, IIRC, and minor should be no smaller) requested by the executable being loaded." This is particularly confusing with respect to the X11 libraries, since the major number of the .so did not get incremented when the shift to glibc was made. It is often the case that an apparently appropriate library exists but does not satisfy version information. (3) What is libXt.so? This is the library implementing the Xt "X toolkit" library, the granddaddy of all X toolkits. Most X toolkits are built either on top of Xt (the MIT Athena widgets) or on a modified version of Xt (Motif). Without this library, your mouse won't point, your events won't happen, and in general you may as well give up, or you're stuck programming in Xlib calls (the GUI equivalent of assembly language). (4) Where does libXt.so live? Normally in /usr/X11R6/lib/. Possibly in /usr/lib/libc5-compat (IIRC, I know the theory, not the practice, and that may be a Debianism) if you have a system which is primarily glibc but is supporting binaries linked with libc5. (5) Is it normal for that not to be in TL-3.0J? No, that's very abnormal. However, the message didn't say it couldn't _find_ libXt.so, it said it couldn't _load_ it. Probably due to the libc5 vs. glibc conflict. TL-3.x systems are glibc through-and-through; (since I accidentally got dropped from the J-beta list) I don't have one to check how (if) it supports libc5 backward compatibility, which is especially difficult for X. But Scott will be by shortly to explain and/or fix all this, I'm sure. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." ------------------------------------------------------------------- Next Nomikai: 14 January 1999, 19:30 Tengu TokyoEkiMae 03-3275-3691 *** it will will be Jan 14 (Thu), as Jan 15 (Fri) is a natl holiday Next Technical Meeting: Feb 13 (Sat), 12:30 ace: Temple Univ. ------------------------------------------------------------------- more info: http://tlug.linux.or.jp Sponsor: PHT
- Follow-Ups:
- Re: tlug: Acrobat reader and libXt
- From: Scott Stone <sstone@example.com>
- References:
- tlug: Acrobat reader and libXt
- From: Jonathan Byrne <jq@example.com>
- Re: tlug: Acrobat reader and libXt
- From: =?iso-2022-jp?Q?=1B$B5uL5=1B=28B?= <kyomu@example.com>
Home | Main Index | Thread Index
- Prev by Date: Re: tlug: 2.2.0-pre? kernels on Sparc
- Next by Date: tlug: Acrobat reader and libXt
- Prev by thread: Re: tlug: Acrobat reader and libXt
- Next by thread: Re: tlug: Acrobat reader and libXt
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links