* Bruno Haible wrote on Mon, Dec 05, 2005 at 10:56:04PM CET: > Ralf Wildenhues wrote: > > > > > How does the installed program find its libraries? > > > > How the uninstalled? > > > > > > In both cases: through the -L option passed to csharpexec.sh. Inside > > > csharpexec.sh, for some C# engines, the -L option translates into > > > options; for others, it translates into the setting of an environment > > > variable. > > > > Hmm, so somebody still has to play the 'gimme the uninstalled paths'. > > At least I don't see that it is done automatically. > > Yes. I think only the strong names of dependencies are hardcoded into > .dlls and .exes, not the paths where to find them.
So people rely on installed paths being default-findable by the engine? > > In the case > > proggie_exe_LDADD = -L ../libs -lfoobar > > > > so maybe you want the Makefile to create (uninstalled!) proggie with > > > > exec $top_builddir/csharpexec.sh -L ../libs -lfoobar proggie.exe > > > > in it? > > I agree, something like this (without the -lfoobar, just the -L option) > should be done in the Makefile. OK. > > Are inter-library dependencies specified? > > As far as I know, inter-library dependencies are handled automatically. > In other words, you link against A.dll and you don't care whether A.dll > depends on B.dll or C.dll or both. You thus never have to compute the > transitive closure of the needed DLLs. But you _do_ have to specify > the complete list of directories where to find DLLs. Hmm. This sounds like pretty much the same requirements as for Debian's libtool (with link_all_deplibs=no) and hardcode_direct=no hardcode_automatic=no hardcode_minus_L=no hardcode_shlibpath_var=unsupported (?) I say sounds, because I still don't like the idea of bringing the comparatively huge machinery that is libtool into play just for this task. OTOH, for a project that already uses libtool, adding a tag for CS would (in CVS libtool) mean only negligible overhead. Cheers, Ralf
