[Samba] [ANNOUNCE] Samba 3.2.2 Available for Download

[James Kosin]

-----Original Message-----
From: Daniel Eischen [mailto:eischen at vigrid.com] 
Sent: Friday, August 22, 2008 11:44 AM
To: Brian H. Nelson
Cc: James Kosin; samba at lists.samba.org
Subject: Re: [Samba] [ANNOUNCE] Samba 3.2.2 Available for Download

>On Fri, 22 Aug 2008, Brian H. Nelson wrote:
>
>> James Kosin wrote:
>>> Tim,
>>> You still may have to move the libraries to their normal spot or
make an 
>>> entry in /etc/ld.so.conf to point to the directory where the
libraries are 
>>> kept for samba.
>>> 
>>> James
>>> 
>>
>> On Solaris, one uses the crle command to achieve the same result.
>>
>> Aside from that, I believe that the general practice for packages
that 
>> include their own libraries is to hard-code the libpath into any
applicable 
>> binaries using '-rpath $prefix/lib' in the linking step (or '-R
$prefix/lib' 
>> with Solaris ld).
>>
>> If you install samba into its own area (say /usr/local/samba) and the

>> libraries are installed in a non-system location (perhaps 
>> /usr/local/samba/lib), messing with the runtime linker config to make
samba 
>> work should NOT be required.
>
>Exactly!  I had the same problem, I believe with 3.0.31.  I
>think I solved it by editing the Makefile (after configuring
>samba) to add '-R $prefix/lib' as described above.
>
>On Solaris, the configure step _should_ generate a Makefile
>with the -R (or -rpath) option above, but it does not.
>
>-- 
>DE

Maybe, we should have an option.  Packagers don't really want or need to
modify their 'ld' settings with the '-R' option.  Or really install in
the same path as the destination system for packaging.

Is the ld -R option only temporary; or does this add an entry in the
ld.so.cache for future reference?  Sorry, I'm a bit ignorant and have
been out of touch.

The bigger issue may be having the libraries actually being installed in
a shared area known by ld on the destination system, as oppose to HARD
CODING or RE-CONFIGURING ld to accept a new location....  hmmm....

The '-rpath' option would cause issues if a third party developed tools
that linked to libnetapi.so in the normal way of using '-lnetapi'...
causing confusion when porting to another platform where the libraries
may/could be located elsewhere.
The -R option looks harmless enough; but, packagers (RPM, etc) might
take notice of ld not operating correctly after building a package for
release.

James