[lsb-discuss] LSB conference call agenda (Tuesday, September 5, 11am ET)

[Wichmann, Mats D]

>> You "escape" a library by adding it to LSBCC_SHAREDLIBS -
>> any library in that environment variable will not be
>> bracketed by the "static" stuff. 

>This will not work for us. We have a relatively large number of shared
>libraries. As we link each library and executable the list of
>dependencies changes. This means we'd have to reset the environment for
>every link based on the precomputed dependencies. Setting all the
>libraries all the time appears overkill.

I'm happy to file a bug on this; the idea has always been
to evolve lsbcc in response to demand.

What we want to preserve is lsbcc's behavior to not
accidentally drag in libraries that aren't part of the LSB.
The behavior described in my earlier summary is what makes 
lsbcc work for GNU-style configure scripts - if a suitable
static library is available, the configure test can proceed;
if not, the configure script will give up with an unsatisfied
dependency. 

lsbcc was not designed with the expectation of large
numbers of "application-provided" shared libraries.

Any thoughts on a design that would work to accommodate that?