fix for resolution of transitive dependencies between "Lumiera modules"
This is a somewhat intricate problem. As long as we linked with --no-as-needed, these problems could not manifest themselves, since all dependencies are spotted correctly by SCons and thus added as direct children of the executable. But when we switch to --as-needed linking, the linker will omit some of the dependencies given from the build system, when the code to be linked doesn't call directly into these dependencies. But of course dynamic modules may depend on each other, and indeed, the Lumiera libs do so. Thus the linker may omit the dependency to liblumierasupport, and just add a dependency to, say liblumierabackend. But the backend in turn depends on the support library. Now the problem is, that when resolving several steps deep into such a dependency chain, our special relative path resolution scheme fails. The fix is to give each lumiera module itself another relative path resolution spec, which overrides at that point the root spec given for the executable. Thus, we define - for the executable: "search at $ORIGIN/modules" - for the modules: "search at $ORIGIN/../modules" This accounts for the fact, that a module, which is the Origin for a transitive resolution step, already sits in a subdirectory below the executable; thus step one level up and devle down into the hard wired modules directory. Alternatively, we could also use just "search at $ORIGIN" (i.e. in the same directory). But assuming that in future we'll roll several core plugins, which also count as "Lumiera modules", the scheme defined here is more flexible, since it allows to place those core plugins into sibling directories.
This commit is contained in:
parent
4e5b1901a1
commit
c14bb61e6a
1 changed files with 4 additions and 1 deletions
|
|
@ -284,10 +284,13 @@ class LumieraModuleBuilder(WrappedStandardExeBuilder):
|
|||
|
||||
def getCustomEnvironment(self, lumiEnv, target, **kw):
|
||||
""" augments the built-in SharedLibrary() builder to add some tweaks missing in SCons 1.0,
|
||||
like setting a SONAME proper instead of just passing the relative pathname to the linker
|
||||
like setting a SONAME proper instead of just passing the relative pathname to the linker.
|
||||
Besides, we override the library search path to allow for transitive dependencies between
|
||||
Lumiera modules; modules are assumed to reside in a subdirectory below the executable.
|
||||
"""
|
||||
custEnv = lumiEnv.Clone()
|
||||
custEnv.Append(LINKFLAGS = "-Wl,-soname="+self.defineSoname(target,**kw))
|
||||
custEnv.Append( LINKFLAGS = "-Wl,-rpath=\\$$ORIGIN/../modules,--enable-new-dtags" )
|
||||
if 'addLibs' in kw:
|
||||
custEnv.Append(LIBS = kw['addLibs'])
|
||||
return custEnv
|
||||
|
|
|
|||
Loading…
Reference in a new issue