[linux-cifs-client] Re: [PATCH] Fix build error where nscd_flush_cache() is available

[Q (Igor Mammedov)]

On Sun, Aug 17, 2008 at 12:00 AM, simo <idra at samba.org> wrote:
> On Sat, 2008-08-16 at 23:40 +0400, Q (Igor Mammedov) wrote:
>> I agree, we'd better use dynamic linking or give up on reusing samba code
>> and revive some code from the first implementation without libsmbclient
>> dependecy + static linking to krb5 libs. so we could end up with deps
>> /lib located libraries only.
>
> Unless you plan to use cifs.upcall at boot or to mount /usr I do not see
> why you would do that.
>
> Static liking is also bad for many reasons, especially for security
> sensitive software. You do not want to get into the business of
> releasing a new cifs.upcall binary if a security problem is found in the
> kerberos libraries.
>
> Simo.
>

Dynamic linking cons:
Somebody here pointed out that dependency on /usr fs for this program is not
a good thing.
Dependency on libsmbclient is not a good for embedded systems. By the way
it's even better do not depend on libsmbclient  to reduce total size
of OS image.

Static linking cons you already pointed out.

As for me, I'd be more comfortable with dynamic linking.

PS:
But making cifs.spnego code independent of libsmbclient may simplify porting of
it to small systems.
(and less depend on bugs in libsmbclient  like this:
https://bugzilla.samba.org/show_bug.cgi?id=5614#c28)
It would be ideal to isolate spnego/kerberos code in quiet independent library,
and use it in the way people would like.