libsmbclient for Samba4: initial design issues
jelmer at vernstok.nl
Tue Oct 31 23:51:43 GMT 2006
Hi Tridge, Derrell,
On Sat, 2005-08-13 at 11:58 +1000, tridge at samba.org wrote:
> yes, I understand what you're trying to achieve, you want all symbols
> in any Samba supplied libs to hide behind a single part of the
> namespace. My objection is that it adds another level of prefix to
> every single function, which I think makes the code less readable.
> Perhaps we could look at a different technical solution? I believe
> that gcc and the GNU binutils has a way of marking functions as being
> public when the code is in a library, thus allowing C code to specify
> a 3 level scoping of "public", "internal" and "file", instead of the
> usual 2 level scoping of "public" and "file" given by
> This wouldn't help us on non-GNU platforms, but it would solve the
> namespace problem on the majority of our users platforms, and the
> other platforms can just live with the (very small!) chance of a name
> collision with the small range of prefixes we have now.
> To do this we'd need something like:
> #ifdef __GNUC__
> # define PUBLIC __attribute__(_some_magic_attribute_)
> # define PUBLIC
> then you would add PUBLIC in front of the functions you want to expose
> in libsmbclient.
We already have this (and use it), though it's currently called _PUBLIC_
rather than PUBLIC. That macro allows us to (on most common platforms),
have a shared library only export the symbols marked _PUBLIC_ and hide
the other ones so that they don't pollute the namespace.
This relies on the 'visibility' attribute in gcc.
I agree that prefixing function names is not the right way to do
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20061101/6bc8c600/attachment.bin
More information about the samba-technical