[C++-sig] dynamic linking in Linux

Niall Douglas s_sourceforge at nedprod.com
Fri Jul 23 20:37:50 CEST 2010


On 23 Jul 2010 at 9:49, Stefan Seefeld wrote:

>   On 07/23/2010 09:35 AM, Niall Douglas wrote:
> > I would even go so far as to say that RTLD_LOCAL
> > needs deprecating in GNU libc.
> 
> That would open the door for all sorts of ABI issues (symbol collisions 
> resulting in the wrong objects being looked up, etc.).
> I don't think making symbols visible globally will solve anything.

No, all that's happening with RTLD_LOCAL is that symbol collisions 
are being HIDDEN from view when a properly maintained ABI ought to 
explicitly hide all symbols not absolutely necessary from an external 
use perspective. Failure to correctly do this is programmer laziness 
as I said.

It took Microsoft well over a decade of MSVCRT instance conflicts 
before someone forced the default to be the DLL rather than static 
link in MSVC7.1 - countless millions of dollars of wasted 
productivity happened in the intervening time while people made 
statements like the one you just made. I am not criticising you 
personally Stefen, this response is extremely common in the 
Unix/POSIX community. Unfortunately it's just plain wrong.

As I said back in 2005, and many, many times since, programmers need 
to be forced to get off their lazy arses and fix the plain out broken 
and lazy ABI management endemic in the GCC-based ecosystem. The tools 
(-fvisibility and __attribute__(visibility())) have been there since 
GCC 4.0. Unless major projects such as Python simply force the issue 
nothing is going to happen.

I for one was extremely disappointed to see Python 3.x baulk yet 
again on the default for dlopenflags. But I'm tired of ranting about 
it. Maybe we might have more success in getting GCC to make the 
default -fvisibility=hidden, then we might get some traction at last.

Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.





More information about the Cplusplus-sig mailing list