require gnu ld for public shared libs?

[David Collier-Brown]

On 06/28/2012 06:09 PM, Andrew Bartlett wrote:
> On Thu, 2012-06-28 at 09:26 -0400, David Collier-Brown wrote:
>> 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 samba.org> 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 samba.org> 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.
> 
> That would require that they all be in the same compilation unit.  Samba
> has multiple (hundred) C files in these libraries, of which some
> functions we do not wish to expose to callers. 
> 
> Andrew Bartlett

Good point: you need the kind of generality that the gnu and Solaris
linkers provide, then. A binder might, but probably would not, help.

Bother! Another wonderful theory killed by a lowly fact (:-))

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