Hi Bruno,
* Bruno Haible wrote on Mon, Dec 05, 2005 at 08:38:43PM CET:
> > > Object code libraries are files with suffix ".dll". They are installed
> > > under $prefix/lib.
> >
> > Is it reasonable to assume that programs will link against these
> > libraries, which are
> > - not built in the same package as the dll
>
> Yes. Making code available for use by other programs is one of the main
> purposes of object code libraries.
:)
> You certainly want to know about library versioning :-)
:)
> Every library and every executable has a version attached. It can be
> set through a particular kind of statement inside a C# source file,
> like this:
> [assembly: AssemblyVersion("1.0.0")]
> So, every object code library and every executable is assigned a so-called
> "strong name". The strong names of the dependencies are stored by the
> linker inside every library or executable.
Interesting. Is there an API/command line tool to extract this version?
> > - which do not contain C# code, and are not built or run with one of the
> > tools below?
>
> No. Such a use of C# libraries is certainly not mainstream.
So no need to bring libtool into play here, good. :)
> > > sed_quote_subst='s/\([|&;<>()$`"'"'"'*?[#~=% \\]\)/\\\1/g'
> >
> > If you encounter options with backslashes frequently (even on non-w32
> > hosts), you may want to parameterize use of echo.
>
> The problem was not 'echo'; I wanted to be able to define this sed
> expression outside of backslashes.
Hmm. I don't understand your statement -- maybe we both misunderstood
each other. What I meant was:
Later in this script, you often use
foo="$foo"`echo "$arg" | sed "$sed_quote_subst"`
^^^^
Problem is, this echo may kill strings of the form `\t' in $arg.
To prevent this, you could parameterize it.
It may very well be the case that you'll only likely encounter arguments
containing `\t' (and the like) on w32 systems. AFAIK there all commonly
used shells have been adjusted so that their builtin `echo' does not
interpret backslashes. So in that case you could leave things as they
are.
> > 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. 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?
Are inter-library dependencies specified? (This is the question I'm
really interested in. If yes, I see little chance to create above in
very few lines of code. Depends on the dependency model though.)
Cheers,
Ralf
