libc/5017: The real issue with Linux weak==strong dynamic bindings in ld.so

[Bhavesh P. Davda]

 Folks, 
   
 I would like to move to a more reasonable technical and business discussion 
 about this issue, and reduce the impact of personal differences on this issue:
   
 1. I represent Avaya, Inc. in all Linux and many open source forums
 2. We have products that generate over $2 billion in revenue annually, 
that depend on Linux.
 3. Up until January 2003, RedHat Linux used a glibc ld.so which respected 
 the weak binding semantics that have been around in Linux all along.  With 
glibc-2.3.2, the weak binding semantics in the run time loader were changed 
by  Ulrich Drepper and others to be more compliant with other SVR4 Unices,
like Solaris,  SCO and others. We do not object to the change to be more
in sync with the other Unix versions but do have an issue with the effect
on legacy applications.
 4. Avaya's legacy telecommunications application, now called Avaya's  Communications 
Manager (aka MultiVantage, aka Definity) depends heavily  on the old weak 
symbol binding semantics, where in if ld.so finds a  strong symbol and a weak
symbol for resolving references, it picks the  strong symbol over the weak
symbol. The application consists of 92 soft-real-time (SCHED_FIFO) co-operating
processes, 8 of them using libpthread.so, that are also dynamically linked
with 4 other Avaya specific shared objects, some of which provide weak definitions
for symbols overridden by libpthread.so, libc.so and other standard shared
objects.
 5. In order to comply with the pre-2.3.2 semantics, glibc-2.3.2 provides 
 LD_DYNAMIC_WEAK to make ld.so respect the old weak symbol binding  semantics.
This is a local solution to a global scoping change.  Thus, there is no practical
way to ensure that every  process that is created in Linux since boot up,
e.g. daemons spawned by  init, will set this variable in their environment. 
To get around this, I  created a modified 2.4.20 kernel.org kernel which puts
LD_DYNAMIC_WEAK=1  into every process's environment on their stack. However,
ideally, such  decisions belong in user space or on a system wide basis.
 6. Avaya would like to be a good corporate citizen in the open source  and 
Linux communities, and is willing to negotiate a solution that is practical.
   
 7. The ELF ABI left the run time loader semantics for STB_WEAK
symbols   unspecified, and Linux up until Jan 2003 has treated them
as weak symbols which are overridden by strong symbols. During the
existence of Linux up to this point, many applications may have been written
that depend on this behavior. Avaya's Communications Manager happens to be
one of these applications.
   
 To this end, I would like to propose a couple of possibilities for a solution:
   
1. If the default Linux glibc behavior can be reverted back to respect  weak 
bindings like in pre-2.3.2, and a LD_WEAK_IS_STRONG environment  variable 
can determine if the Solaris, SCO, other SVR4 semantics can be  used, we can
ensure that legacy applications don't break. Sometimes  companies tend to
have applications that they don't even have source for  any more, so making 
source changes becomes impossible in these cases.    
2. Another possibility is to negotiate a configurable /proc interface (e.g.
/proc/sys/abi/elf_dynamic_weak) that would help the loader to determine the
default system characteristics to be used.
    
     Please let me know how we can resolve this issue to our mutual satisfaction.
     
 Thanks 
 - Bhavesh
-- 
Bhavesh P. Davda
Distinguished Member of Technical Staff
Avaya Inc
Room B3-B03                     E-mail : address@hidden
1300 West 120th Avenue          Phone  : (303) 538-4438
Westminster, CO 80234           Fax    : (303) 538-3155