W3C home > Mailing lists > Public > www-lib@w3.org > October to December 2004

RE: share libraries on UNIX

From: Samuel Soliz <samuel.soliz@quest.com>
Date: Tue, 9 Nov 2004 08:49:24 -0600
Message-ID: <3F6DD81755D3C1469D08E8A2F2981170E93FD9@is~houmbxw01.quest.com>
To: <heitkamp@ameritech.net>
Cc: <www-lib@w3.org>

Your correct, a permanent fix is preferred; however, it depends on how
much time you spend looking for the flag.  This is a common problem.
Take a look at any UNIX box's /usr/lib directory and you will see
similar symbolic link fixes. One reason for the symbolic links is to
handle library revisions.
Yes, it's a temporary fix, but its fast and the script/links are only
created once.  It's a 5 minute fix, allowing you to concentrate on your
application, unless your task is to find this special flag.


-----Original Message-----
From: F. Heitkamp [mailto:heitkamp@ameritech.net] 
Sent: Tuesday, November 09, 2004 5:27 AM
To: Samuel Soliz
Cc: www-lib@w3.org
Subject: RE: share libraries on UNIX

On Mon, 8 Nov 2004, Samuel Soliz wrote:

> Fred,
> Create a script with symbolic links from the .so to the actual
> libraries.  For example:
> ln -s libwwwapp.0.1.0 libwwwapp.so
> ln -s libwwwapp.0.1.0 libwwwapp.so.0
> ln -s libwwwcache.0.1.0 libwwwcache.so
> ln -s libwwwcache.0.1.0 libwwwcache.so.0
> .

That's a temporary fix, but why not fix the aclocal/automake/libtool
that cause the problem in the first place?  I have been looking into
and found a message or two on google describing similar problems with 
other packages.  The fix in that case was to run "autoreconf -i -f".
worked with another program, but does not work with libwww.  So far I
been unable to find the section in the autotools that actually creates 
the ".so" part of the library name.

Received on Tuesday, 9 November 2004 14:49:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:56 UTC