On Fri, 18 Nov 2011, David Berry wrote:

> On 17 November 2011 22:59, Tim Jenness <[log in to unmask]> wrote:
>> On Thu, Nov 17, 2011 at 7:26 AM, Peter W. Draper
>> <[log in to unmask]> wrote:
>>> Seems that Ubuntu and Debian have decided to change the way that ld handles
>>> references to shared libraries. See:
>>>
>>>   https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
>>>
>>> bad news indeed. I've worked around this and got a build to succeed using
>>>
>>>  LDFLAGS="-Wl,--no-as-needed"
>>>
>>> which seems to restore the old behaviour, but it looks like the real
>>> solution is one we've been avoiding for some years now, namely to identify
>>> all the shared libraries that are necessary to resolve the symbols when
>>> linking a shared library, so that each library ends up with links to the
>>> libraries it depends on (this is the reason why the Cygwin build stopped
>>> working).

I may have spoken too soon, seems there is still a problem building VTK 
with this flag set (didn't clean this submodule). Could be down to the 
library ordering this time, but that's a guess I need to follow up.

>> Thanks for the heads up. We have the link scripts so we do know what
>> each library depends on. What causes me pause is how we handle link
>> script options. If I'm linking against AST I may or may not want to
>> provide an error library or grf plugin. Does this mean that we need to
>> install multiple monolithic AST libraries that cover all the link
>> options?

Good point. You can clearly can still build libraries with missing 
symbols, so the question would seem to be how to satisfy those at runtime. 
Usually you dlload, like with Tcl, Perl etc. The alternative would seem to 
be using the correct ld flags in ast_link etc. that force the dependencies 
of the libraries themselves to be checked, as well as the local objects, 
or just the above to grab all libraries that have been given.


> Not sure I'm following this. Isn't the whole point of the link scripts
> to generate a proper list of all the libraries that should be linked,
> leaving no "indirect" linking? And what is the problem with the AST
> link options? Is it that if libA_link and libB_link invoke the AST
> link script with different options, then an application that links
> against libA and libB will be confused?
>
> Since Peter says there is a problem, I'll believe it, but I'm just
> trying to sort out why the current scheme fails.

Because by default symbols in shared libraries are not checked for 
unresolved symbols, so your new (Grf/Err) code may be deemed unnecessary. 
Previously all the libraries given to the linker would be added to the 
dependencies of the program and show up in "ldd", now only those found as 
needed to resolve the dependencies of the local objects will be found by 
"ldd". One corollary: not completely sure how that would pan out if new 
Grr/Err modules are local objects not buried in some shared library, and 
another, this is all quite subtle, so don't take my word as gospel.

Cheers,

Peter.