This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [Lsb-wg] opposition to LSB 2.0 rc1


To address only this specific paragraph:

>   In response, this LSB has advocated the use of dynamic loader
>   tricks to solve this issue. A separate dynamic linker with special,
>   LSB-only properties would purportedly solve the problem. Especially
>   concerning are non-trivial, real-world cases, where applications
>   need more runtime support than the subset of libraries standardized
>   in the LSB specification. These libraries will drag in their own
>   dependencies on the C++ ABI.  The LSB working group has repeatedly
>   been pointed to this problem; the problem has been ignored since
>   there are no dependencies of any other standardized library on
>   libstdc++.  Conforming with the LSB specification just for the sake
>   of passing the LSB test suite while ignoring the compatibility
>   issues lingering in the shadows is not advisable.

1. The "trick" has long standing in the LSB (predates my three-year
involvement so I don't know the specific discussion that took place). 
It's simply that LSB applications be bound to an LSB-specific linker 
name that is different than the system one so that if an implementation
has a need to do something different to accommodate LSB binaries that it
has a hook to be able to do so.  Of course we all hope that this will
not be needed and LSB support will be completely mainstream in
all the libraries, and most runtimes work that way today and just 
make a symlink for this special linker name.  But there is some 
historical practice for this technique having been used to point to
some different libraries, apparently quite successfully.  And the 
"special, LSB-only properties" don't have to be very special, just
an extra directory at the front of the search path. 

2. If there's real-world usage of the LSB extended by using non-LSB
libraries, we're yet to hear much about it - and if it's happening,
we would sure like to, as that would be very useful information. 
I think we're aware of one non-trivial application (a port of the 
program loader portion of Eclipse) which has made an attempt to
bring in significant numbers of non-LSB libraries.   On the contrary,
it seems the feedback we get from developers is that there isn't 
enough covered by the LSB and so they won't even bother to use it,
and of course lack of C++ has been the most common complaint of all.
We are, of course, well aware that the library coverage in the LSB
is smaller than most developers want and are trying to work towards
addressing that need.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]