Bruno Haible wrote:
> Guido Draheim wrote:
>> create a .NET wrappers for the linux dvb kernel api. It does
>> work - getting libtool to compile a native shared library
>> being called from a managed dll that imports symbols from it.
>
> Which are the command lines that you use for doing this? I'
Ouch, just saw that You wrote the original csharpcomp.sh. Well,
just consider it as an update from a current project ;-)
Guido Draheim wrote:
>
> Bruno Haible wrote:
>> Guido Draheim wrote:
>>> create a .NET wrappers for the linux dvb kernel api. It does
>>> work - getting libtool to compile a na
Guido Draheim wrote:
> create a .NET wrappers for the linux dvb kernel api. It does
> work - getting libtool to compile a native shared library
> being called from a managed dll that imports symbols from it.
Which are the command lines that you use for doing this? I'd like to
understand which tool
by the way,
I have recently used a combination of mono and automake to
create a .NET wrappers for the linux dvb kernel api. It does
work - getting libtool to compile a native shared library
being called from a managed dll that imports symbols from it.
You will find an autoconf macro AX_PROG_CSC a
> > 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 ne
Ralf Wildenhues wrote:
> > 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?
Yes. People install all libraries into $prefix/lib.
> Hmm. This soun
* 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,
Ralf Wildenhues wrote:
> > 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?
Bruno Haible wrote:
>>> - Target "install" should install foobar.dll into $(libdir), using
>>>$(INSTALL_DATA).
>>
>>May any post-install action be necessary for the library (on some hosts)?
>
> None that I'm aware of.
Well on windows hosts (and possibly hosts with sscli), there is the
possib
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
Hi Ralf,
> > 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
Hi Bruno,
Just a few quick remarks from a glance.
* Bruno Haible wrote on Mon, Dec 05, 2005 at 01:02:10PM CET:
>
> The object code generated from C# source code is platform-dependent.
> Although most (or all?) of the file format of C# libraries and executables
> is platform-independent, C# sourc
Bruno Haible <[EMAIL PROTECTED]> writes:
> Hi,
>
> At least two GNU packages (gettext and libidn) now have parts of their
> source code written in C#. Simon Josefsson, author of libidn, suggests
> that C# support be added to automake. Let me here present the basic facts
> about C# compilation, and
Bruno Haible wrote:
> Simon Josefsson wrote:
>
>>> - Target "clean" should remove foobar.dll.
>>
>>Adding '-g' make the Mono compiler create files called foo.dll.mdb.
>>So the "clean" target should probably remove them too.
>
>
> I agree. Target "clean" should remove foobar.dll and foobar.dll.m
Bruno Haible wrote:
>Implementation | Compiler
>---+-
>pnet | cscc
>mono | mcs
>sscli | csc
On Windows, it's the .NET SDK, and csc is the compiler.
If you're going to add support for C#, you should include its main
source platfor
Simon Josefsson wrote:
> It may be useful to discuss DLL naming. I noted that gettext call the
> generated DLL 'GNU.Gettext.dll'. Should we encourage a 'GNU.'
> prefix? Should we encourage mixed upper/lower case?
This is unrelated to automake. Let's discuss it elsewhere.
> > - Target "clean"
Hi,
At least two GNU packages (gettext and libidn) now have parts of their
source code written in C#. Simon Josefsson, author of libidn, suggests
that C# support be added to automake. Let me here present the basic facts
about C# compilation, and a few macros and scripts that are in use in
GNU gett
17 matches
Mail list logo
