Tech Insider					     Technology and Trends


			      USENET Archives

From: <abrah...@equinox.shaysnet.com>
Subject: Docs on shared libraries 
Date: 1996/11/11
Message-ID: <9611120230.AA0054@equinox.shaysnet.com>#1/1
X-Deja-AN: 195891762
sender: owner-linux-ib...@vger.rutgers.edu
x-hdr-sender: abrah...@equinox.shaysnet.com
x-env-sender: owner-linux-ibcs2-outgo...@vger.rutgers.edu
	from: Paul Abrahams <abrah...@equinox.shaysnet.com@russula>
newsgroups: linux.dev.ibcs2
illegal-object: Syntax error in From: address found on vger.rutgers.edu:


I've been trying unsuccessfully to get either the Solaris or UnixWare
version of a certain program (DynaText from Electronic Book
Technologies) to run under Linux using the ibcs2 emulator.  The problems
have to do with shared libraries.  The documentation files seem to have
some ambiguities in critical places:

>From the README file:

    Many programs require shared libraries. You can use the shared libraries
    from your existing system under Linux, but it is your responsibility to
    check whether your license allows you to do this whether directly or
    using NFS.

Does the reference to "your existing system" mean my Linux system or
some UnixWare system that I'm presumed to have?  

    A shared libc is being developed by Eric Youngdale and can be compiled
    both as ELF (for SVR4) and COFF (for SVR3/SCO). Replacements for
    the SVR3/SCO libnsl_s and protlib_s are under development by Mike
    Jagdis. All the available replacement shared libraries should be
    available from the same place you got the iBCS module. The replacement
    shared libraries are not perfect but largely usable.

    The SVr4 X11 libraries are not part of this package, but precompiled
    libraries for X11 can be obtained from the binary sites for XFree86.

Nothing is said here about Motif libraries.  Is there a way to run a
UnixWare program that uses Motif if you have the Linux shared libraries
for Motif (from MooTif, say)?

>From the HINTS file:

PROBLEM:
	SVr4 binaries cannot locate shared libraries, or fail to start.

REASON:
	The shared libraries are not in the correct location, or the dynamic
	loader cannot be located by the kernel.

SOLUTION:
	Put all SVr4 shared libraries in the directory /usr/i486-sysv4/lib.
	Then create two symbolic links:

	ln -s /usr/i486-sysv4/lib/libc.so.1 /usr/lib/libc.so.1
	ln -s /usr/i486-sysv4/lib/ld.so.1 /usr/lib/ld.so.1

Is it the case that SVR4 programs always look for their shared libraries
in /usr/lib?  Is there some environment variable that affects this?  And
if the problem is that the dynamic loader can't be located by the
kernel, what is the remedy?


PROBLEM:
	UnixWare X binaries don't work.

REASON:
	The UnixWare X libraries directly use STREAMS/TLI, and thus do
	not work with linux.

SOLUTION:
	Use the XFree86 libraries instead (Note: the XFree86 libraries
	are not interchangeable with the Unixware X libraries, but 
	if you can recompile/relink your application, you can use the
	XFree86 libraries instead).

	The XFree86 libraries are socket based, and this type of
	networking is fully supported under Linux.

Does all this imply that if you're using a UnixWare application for
which you don't have the source code, the XFree86 libraries can't be
dynamically linked because they're incompatible?

Perhaps one of the iBCS2 gurus will be able to help.  I hope so.

Paul Abrahams

From: ja...@purplet.demon.co.uk (Mike Jagdis)
Subject: Re: Docs on shared libraries 
Date: 1996/11/14
Message-ID: <10842@purplet.demon.co.uk>#1/1
X-Deja-AN: 196720542
sender: owner-li...@vger.rutgers.edu
x-hdr-sender: ja...@purplet.demon.co.uk 
x-env-sender: owner-linux-i...@vger.rutgers.edu
newsgroups: linux.dev.ibcs2



>     Many programs require shared libraries. You can use the shared libraries
>     from your existing system under Linux, but it is your responsibility to
>     check whether your license allows you to do this whether directly or
>     using NFS.
> 
> Does the reference to "your existing system" mean my Linux system or
> some UnixWare system that I'm presumed to have?  

It means the non-Linux system.

> Nothing is said here about Motif libraries.  Is there a way to run a
> UnixWare program that uses Motif if you have the Linux shared libraries
> for Motif (from MooTif, say)?

In general you cannot use shared libraries from one system on
another regardless of whether or not they share the same binary
format. However, in the case of something that mostly sits "in
between" as it were like Motif you may be able to get away with
enough of the time. But only if you have just the right version
of Motif and it is compiled against the right Xt version and...

> 	ln -s /usr/i486-sysv4/lib/libc.so.1 /usr/lib/libc.so.1
> 	ln -s /usr/i486-sysv4/lib/ld.so.1 /usr/lib/ld.so.1
> 
> Is it the case that SVR4 programs always look for their shared libraries
> in /usr/lib?

No. They specify an "interpreter" in their ELF headers. This is
usually /usr/lib/libc.so.1. The kernel loader loads the program
and the interpreter together. The interpreter is responsible for
mapping in other libraries and resolving references.

  If you use Eric's libc replacement (which, I believe, needs
some work to bring it back in line) the interpreter (which is
actually an older version of the Linux ld.so dynamic linker)
will look in /usr/i486-sysv4/lib. Non-Linux shared libc will
look in /usr/lib. A Linux libc will not work as a substitute.

> REASON:
> 	The UnixWare X libraries directly use STREAMS/TLI, and thus do
> 	not work with linux.

This should actually work now since we have enough of the TLI
over STREAMS stack emulated to handle IP and the STREAMS pipes
used for local X connections.

  In fact I have used DynaText in the past to view the X/Open Single
UNIX Spec CD. I installed the Unixware version and used shared
libraries from an old, abandoned copy of Unixware 1.1 that was
gathering dust on my shelf.

  Sadly the X/Open CD is rather light on DynaText binaries for
x86 platforms other than Unixware. I would be surprised if this
hadn't changed with the growth in Unix clones and the introduction
of free SCO. Have you tried asking EBT (they have the ebt.com
domain) for a Linux version? Or a static any x86 version?

				Mike

-- 
.----------------------------------------------------------------------.
| Mike Jagdis                   | Internet: ja...@purplet.demon.co.uk  |
| 280, Silverdale Road, Earley, | Voice:    +44 1734 266996            |
| Reading RG6 7NU ENGLAND       | Work:     +44 1734 890403            |
`----------------------------------------------------------------------'

From: Paul Abrahams <abrah...@equinox.shaysnet.com>
Subject: Docs on shared libraries - suggestions 
Date: 1996/11/18
Message-ID: <9611182022.AA0099@equinox.shaysnet.com>#1/1
X-Deja-AN: 197270956
sender: owner-linux-ib...@vger.rutgers.edu
x-hdr-sender: abrah...@equinox.shaysnet.com
x-env-sender: owner-linux-ibcs2-outgo...@vger.rutgers.edu
newsgroups: linux.dev.ibcs2



Thanks to Mike Jagdis and Markus Nullmeier, I now have a better
understanding of the issues regarding using shared libraries with ibcs.
I have some suggestions that might help when the documentation is next
revised:

(1) There's a paragraph in the README about shared libraries:

>     Many programs require shared libraries. You can use the shared libraries
>     from your existing system under Linux, but it is your responsibility to
>     check whether your license allows you to do this whether directly or
>     using NFS.

The trouble with this paragraph is that it makes the assumption, not
necessarily true (and not true in my case) that the user has access to a
UnixWare or Solaris system and can somehow utilize its shared
libraries.  The reference to "your existing system" is confusing because
the user certainly has a Linux system but may or may not have any other
system.  The intent, I now know, is to refer to that other system.

Something like this might be better:

Many programs require shared libraries. If you have access to the shared
libraries for the system you're emulating under iBCS2, you can use them
via iBCS2 under Linux.  However, it is your responsibility to
check whether your license allows you to do this whether directly or
using NFS.

(2) Following from that, it would be helpful to distinguish between the
two cases where the user has access to the emulated system and where he
doesn't.  In the former case, it seems possible to deal with the shared
library problem, at least for UnixWare, by picking up the necessary
libraries from the ibcs section at tsx-11 and from the XFree86 section
at sunsite.  (Pointers to specific directories or at least file names
would be helpful).  However, if the emulated program uses the Motif
libraries, you're out of luck, since free versions of these don't exist.

(3) Since Free UnixWare is close at hand (from SCO), if there's any
information available about whether these libraries can be used in an
emulation within the terms of the SCO license, and how to do it, that
would be very valuable.

Paul Abrahams

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/