- From: Samuel Soliz <samuel.soliz@quest.com>
- Date: Tue, 9 Nov 2004 08:49:24 -0600
- 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. Sam -----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 bits that cause the problem in the first place? I have been looking into that 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". That worked with another program, but does not work with libwww. So far I have been unable to find the section in the autotools that actually creates the ".so" part of the library name. Fred
Received on Tuesday, 9 November 2004 14:49:32 UTC