LD_LIBRARY_PATH & /usr/openwin/lib

LD_LIBRARY_PATH & /usr/openwin/lib

Post by Michael Wald » Wed, 17 Jul 1996 04:00:00



Sorry for bringing up this once again ...

There are a lot of public domain programs which compile/work propperly if
LD_LIBRARY_PATH contains /usr/openwin/lib. But without it I get (for my point)
mysterious results, see e.g. xrn. A `ldd xrn' gives:

        libXaw.so.5 =>   (not found)
        libXmu.so.4 =>   (not found)
        libXt.so.4 =>    /usr/lib/libXt.so.4
        libXext.so.0 =>  (not found)
        libX11.so.4 =>   /usr/lib/libX11.so.4
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libXext.so.0 =>  /usr/openwin/lib/libXext.so.0
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libw.so.1 =>     /usr/lib/libw.so.1
        libintl.so.1 =>  /usr/lib/libintl.so.1

Please note that somewhere it misses libXext.so.0, but some lines later it's
ok. I have played for a while with editing Imakefiles, but I can't find a
convincing solution.

I guess it may have to do with -L (naming library pathes during linking) and -R
(naming library pathes during run-time). Am I right if one has to do something
_BOTH_ like

        -L /usr/openwin/lib -lXext -R /usr/openwin/lib
?

Which variable within Imakefile is to be changeged to get propper libraries?
Or is it some file within /usr/openwin/lib/config?

Is it possible to change the "search path" within a binary?

Currently I only succeed if I edit some Makefiles (after doing the xmkmfs; make
Makefiles). And that's the wrong way, I know.

If everythings fails what do you think of symbolic links bringing together all
missing libraries within /usr/lib?

 
 
 

LD_LIBRARY_PATH & /usr/openwin/lib

Post by Andreas Karr » Wed, 17 Jul 1996 04:00:00



>There are a lot of public domain programs which compile/work propperly if
>LD_LIBRARY_PATH contains /usr/openwin/lib. But without it I get (for my point)
>mysterious results, see e.g. xrn. A `ldd xrn' gives:

[shared X11 libraries not found]

Quote:

>I guess it may have to do with -L (naming library pathes during linking) and -R
>(naming library pathes during run-time). Am I right if one has to do something
>_BOTH_ like

>    -L /usr/openwin/lib -lXext -R /usr/openwin/lib

That's the right approach. You're dealing with Solaris 2.4 or earlier, these had
broken config files for imake. You could even say:

        -R/usr/openwin/lib:/usr/X11R6/lib:/usr/X11R6.1/lib:/usr/lib/X11

or set the LD_RUN_PATH variable at link time.

Quote:>Or is it some file within /usr/openwin/lib/config?

One could probably get config files from a 2.5 machine, but no guarantee...

Quote:>Is it possible to change the "search path" within a binary?

Only when -R was specified at link time, and you can only change it
to a shorter path (that's the rationale for the long -R path above). A
"setrpath" program that does this exists; alternatively, find the current
RPATH with

  dump -Lv executable | grep RPATH

and change it with

  perl -pi -e 's|/old/r/path|/new/r/path|g' executable

but make sure the two strings are of the same length. Pad with nulls
if neccessary.

Quote:>Currently I only succeed if I edit some Makefiles (after doing the xmkmfs; make
>Makefiles). And that's the wrong way, I know.

Until you upgrade to 2.5, do

   setenv LD_RUN_PATH \
          /usr/openwin/lib:/usr/X11R6/lib:/usr/X11R6.1/lib:/usr/lib/X11

before you compile/link any X11 programs. This has the same effect
as using -R, but you don't have to fiddle with Imakefiles. If both
-R and LD_RUN_PATH are used, -R wins. Also, -R is not understood by
old versions of gcc.

+-----------
  Andi Karrer, Institute for Electronics, ETH Zuerich, Switzerland
"set sourceany":  Read startup files not owned by the current user.
                  This option will never be implemented.
   -- Keith Bostic, nvi manual page

 
 
 

1. /usr/openwin/lib/libtt.so vs /usr/dt/lib/libtt.so (and ttsession) ?

  What are the differences between these two (other than one contains
symbols the other doesn't) ? We're finding having a common LD_LIBRARY_PATH
with both /usr/dt/lib and /usr/openwin/lib creates problems for "ttsession"
(if they call the opposing binary) :

LD_LIBRARY_PATH=/usr/lib:/usr/local/X11/lib:/usr/dt/lib:/usr/openwin/lib

% /usr/openwin/bin/ttsession   (open windows sessions)
ld.so.1: /usr/openwin/bin/ttsession: fatal: relocation error: symbol not found: _tt_setdtablesize__Fi: referenced in /usr/openwin/bin/ttsession

% ldd /usr/openwin/bin/ttsession
        libtt.so.2 =>    /usr/dt/lib/libtt.so.2
        ...

% ldd /usr/dt/bin/ttsession
        libtt.so.2 =>    /usr/dt/lib/libtt.so.2
        ...

  We have not tested CDE with /usr/openwin/lib first in the LD_LIBRARY_PATH,
although the library binds successfully.

  Not particularly familiar with the OpenWin/CDE inner workings, which
set of libraries is more suitable to be first (libtt.so is the only
conflicting library between the two trees) ?

  Our environment requires references to both, but maintaining some
mechanism to handle correct ordering of *PATHs depending on which
desktop environment is used sounds rather messy.

  Is this incompatibility by design, or by simply having two different
working groups ?

-eric

--
  Eric Berggren             | "Parts of this product may be derived from
  Portland State University |  from UNIX and Berkeley 4.3 BSD systems..."

2. some more advice? :)

3. su cellopt -c "sh -c 'LD_LIBRARY_PATH=/usr/lib; echo $LD_LIBRARY_PATH'"

4. seagate drive compatibility with Risc 6000 machine ?

5. /usr/lib/gcc-lib/i386-linux and /usr/lib/gcc-lib/i486-linux

6. Welcome to comp.unix.shell [Frequent posting]

7. Tell "configure" to use /usr/local/lib/sparcv9/ instead of /usr/local/lib/

8. Removing volume groups, logical volume, and paging space

9. linking /usr/local/lib/* to /usr/lib/

10. /usr/X386/lib/X11 <-> /usr/lib/X11

11. Wanted: /usr/openwin/lib/sparcv9/libxil.so

12. can't map '/usr/openwin/lib/libxview.so.3.2.2

13. Why don't /usr/openwin/lib/config/* reflect SVR4 by default?!