dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]compiling xsharp - problem with libs (generic)


From: Jakob Praher
Subject: Re: [DotGNU]compiling xsharp - problem with libs (generic)
Date: 30 Sep 2002 22:31:24 +0200

Am Son, 2002-09-29 um 23.05 schrieb Rhys Weatherley: 
> Jakob Praher wrote:
> > 
> > 
> > Is it enough to set LD_LIBRARY_PATH to control assembly resolution, or
> > how is, for instance mscorlib.dll found for linking, like:
> > 
> > cscc -lmscorlib -o superapp myassembly.cs
> 
> If you have "make install"'d pnet, then it should be able to
> find it without any trouble.  It is better to set CSCC_LIB_PATH
> for assembly resolution than LD_LIBRARY_PATH.
ok. I'll try again. 
> 
> > does it behave like cc, or ld in this respect?
> 
> It tries to emulate gcc's behaviour as much as possible.
so are /usr/lib and /usr/local/lib automatically included in the search
path? 

<by-the-way xmlns="uri:category:randomthoughts"> 

according to the lsb shouldn't assemblies go in a share directory? 
I know that from my debian/java expierence - we do all the jar files in
a /usr/share directory and only the jni wrappers in a /usr/lib
directory. 

from my understanding share is used to identify plattform neutral files
that can be shard among different hardware. 

(like docs, images and the like) 

</by-the-way> 
> 
> > if yes - it would be great to implement a pkgconfig database file for
> > dotgnu-pnet - so that we can use the unified 'pkgconfig' to get all the
> > compiler flags...
> 
> The complicated compiler flag stuff in pnetlib, xsharp, etc,
> is an artifact of how I run my system here.  I deliberately
> don't use "make install", to prevent conflicts between my
> work tree and /usr/local.  On a regular system, everything
> is set up in the right place and "cscc" is usually sufficient.
ok. 


> 
> > are you planing on integrating the generics spec from m$ research - how
> > does it play given that cvm is a typed instruction set?
> 
> I plan to do it one of these days when I find the time.
> Or someone else can have a go if they like.  The spec isn't
> 100% concrete yet, so I've been holding off.
that's true - I have read it lately. 
I would like to give it a try, but I firstly would need to get a
thorough understanding of the IL Engine - I plan do publish a docbook
sometimes. 

> 
> I envisage that we'll need to create some kind of "instantiate
> generic" function that takes a generic class definition and a
> set of actual parameters, and then builds an actual IL class on
> the fly.  This can be processed with CVM in the usual manner.
I like the idea. I will think about it. 
I would also like to help with garbage collection - I have a very good
paper about the train algorithm and generational gc - what's the status
of garbage collection right now? (sorry just curious, my job didn't let
me do more research on your very well done source code right now) 


thanks for your information 

bye 
Jakob 

> 
> Cheers,
> 
> Rhys.
> _______________________________________________
> Developers mailing list
> address@hidden
> http://www.dotgnu.org/mailman/listinfo/developers
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]