require gnu ld for public shared libs?

David Collier-Brown davec-b at
Thu Jun 28 07:26:51 MDT 2012

On 06/28/2012 04:46 AM, Andrew Bartlett wrote:
> On Thu, 2012-06-28 at 10:35 +0200, Jelmer Vernooij wrote:
>> On Thu, Jun 28, 2012 at 06:14:44PM +1000, Andrew Bartlett wrote:
>>> On Thu, 2012-06-28 at 09:53 +0200, Jelmer Vernooij wrote:
>>>> On Sat, Jun 23, 2012 at 09:07:21AM +0930, Rusty Russell wrote:
>>>>> On Thu, 21 Jun 2012 14:22:37 +0200, Jelmer Vernooij <jelmer at> wrote:
>>>>>> On Mon, Jun 18, 2012 at 11:04:48AM +0930, Rusty Russell wrote:
>>>>>>> On Sat, 16 Jun 2012 10:28:46 +0200, Jelmer Vernooij <jelmer at> wrote:
>>>>>>>> Hi Rusty!
>>>>>>> Hi Jelmer!
>>>>>>>>> Because you'd have to maintain an ABI.  And that would stop us from
>>>>>>>>> fixing bugs or removing functions; you really don't want a bag of utils
>>>>>>>>> to be a shared library!
>>>>>>>>> Or we could keep changing the ABI, making it useless for anyone outside
>>>>>>>>> Samba anyway.
>>>>>>>> The problem is that in its current form, we already rely on the ccan
>>>>>>>> ABI not changing.
>>>>>>>> If you have an older version of tdb installed on your system which includes a
>>>>>>>> copy of ccan and you build a newer version of Samba, then you end up
>>>>>>>> with ABI incompatibilities.
>>>>>>> ?????!! WTF?
>>>>>>> No, this is *completely* wrong!
>>>>>>> Why do you think this?  How would that work?
>>>>>> ntdb ships a copy of ccan, which gets built as a shared library.
>>>>> Argh, yes the *top-level* build does that.  configure and build inside
>>>>> lib/ntdb, and waf gets it right and doesn't try to make ccan a shared
>>>>> library or any such stupidity.  Fix below.
>>>>> (I wrote an analsyis of -ffunction-sections and --gc-sections here,
>>>>> which is perfect for CCAN, but unfortunately that causes ld to segfault
>>>>> if we use it for a top-level build!).
>>>>> Subject: ccan: we're a subsystem, not a library.
>>>>> Don't expose a libccan; it would produce clashes if someone else does the
>>>>> same thing.  Just build in the bits we need.
>>>> Wouldn't this just cause the same issues? You're still ending up with
>>>> two different copies of the ccan symbols on systems that don't have
>>>> symbol versioning. Are we actively trying to hide symbols from
>>>> subsystems yet?
>>> This is what I was trying to discuss with Simo.  I would really like to
>>> get this right, given the explosion of libraries we are about to
>>> unleash, as well as changes like this. 
>> Same here.
>>> I'm not entirely sure where the _PUBLIC_ decorators fit into this, but
>>> it seems to me that the only thing we use and support in this area is
>>> gnu ld version scripts, and then we have full versions and (as I
>>> understand it) a restricted set of exported symbol (based on the regex
>>> in the wscript file). 
>> Being able to rely on always hiding private symbols would be great.
>> Unfortunately we can't do this on all the platforms we want to
>> support.
>> Another option is to require that we can make symbols private if the
>> user wants to use system installations of e.g. tdb and talloc. This
>> is a bit of a compromise seems like the most reasonable solution to me.
> This is what I would like to do for 4.0.  That is, we only produce
> public shared libs when we can hide symbols.  Currently that would mean
> gnu ld. 
> Andrew Bartlett

I used to maintain a Solaris-compatible (porting) library on systems
without built-in linker features for symbol control, and did it with an
awk script and a yacc grammar.

The basic idea was to allow anything we'd now consider _PUBLIC_ to be a
regular function, and any function that wasn't marked as such to be
demoted to static.

If you had a rule that a function must always be either _PUBLIC_ or
_PRIVATE_ then you could do it all with an awk script, and diagnose any
functions that didn't have an annotation.

On Multics we called this a "binder", which see.

David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at           |                      -- Mark Twain
(416) 223-8968

More information about the samba-technical mailing list