[C++-sig] dynamic linking in Linux
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.
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no:
More information about the Cplusplus-sig