Sean Kelly wrote:
> BCS wrote:
> 
>>
>> You would need a special Phobos to do it.
> 
> 
> Well, that's basically what Ares is :-)  Though it would be easy enough for Walter to add to Phobos if he thought it was a good idea.
> 

Maybe, but I was thinking more along the lines of an alternate build of Phobos, not a rewriting. I guess the same could be able to be done with most stdlib's.

[...]
> 
>> I guess what you'd have is a complete duplication of the D runtime. One set (what is there now) for static linking and one set (with the above hacks, and more I assume) for dynamic linking.
> 
> 
> Dynamic linking is a pain, which is why I've avoided the issue thus far.  DDL is another option that I think is far preferable in instances where it can be used.  I'll admit I'm not at all keen on trying to turn the compiler runtime code into a DLL, what will all the exports likely required and such.
> 
> 
> Sean

I'm thinking of a same-code-link-with-both kind of thing, just pick the lib you want and go.

Sean Kelly wrote:
> Dave wrote:
> 
>> Sean Kelly wrote:
>>
>>> Kirk McDonald wrote:
>>>
>>>> Walter Bright wrote:
>>>>
>>>>> Kirk McDonald wrote:
>>>>>
>>>>>> Here's something that has been annoying me, and this week-old thread is as good a place as any to bring it up: Shared library support on Linux. I could not take D seriously if it did a "1.0" release without this. I do hate to cram more on your plate, Walter, but I consider this a more serious issue than even this import thing that has gripped the newsgroup for the past week.
>>>>>
>>>>>
>>>>>
>>>>> I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done.
>>>>>
>>>>> Will the shared libraries work with GDC?
>>>>
>>>>
>>>> Ha! Well, at least this simple case does:
>>>>
>>>> [myso2.d]
>>>> import std.stdio;
>>>>
>>>> export extern(C)
>>>> void mysoprint() { writefln("Hello 'so' world!"); }
>>>>
>>>> [myso.d]
>>>> export extern(C) void mysoprint();
>>>>
>>>> [test.d]
>>>> import myso;
>>>>
>>>> void main() {
>>>>     mysoprint();
>>>> }
>>>>
>>>> $ gdc -shared -Wl,-soname,libmyso.so -o libmyso.so myso2.o -lc
>>>> /usr/bin/ld: warning: creating a DT_TEXTREL in object.
>>>>
>>>> (Not sure what that means...)
>>>>
>>>> $ sudo cp libmyso.so /usr/lib
>>>> $ gdc -c test.d
>>>> $ gdc test.o -Wl,-lmyso -o test
>>>> $ ./test
>>>> Hello 'so' world!
>>>>
>>>> Sweet. However, I am a little concerned. When making DLLs on Windows, there is some boilerplate code needed to initialize and shut down the GC and do some other routine things. Is something like that needed here?
>>>
>>>
>>> I think it is.  Perhaps the best approach would be to expose two extern (C) functions: one for startup and one for shutdown.  By default, these would be called automatically by internal/dmain2, but the user could opt to call them in DllInit or whatever if he knows that function will not be the entry point for his program.  In Ares, I'd probably call these "cr_init" and "cr_term" where "cr" means "compiler runtime."
>>>
>>
>> Could these be exposed to be the same on both platforms? If so that would be great.
> 
> 
> Yup.  It would be a trivial change to internal/dmain2.  I'll probably do it in Ares in the next few days, just to have it as an option.

This not being my specialty, I have to ask the dumb question:

does all this mean that

 - helloworld could be only a few kB

 - on a machine where D programs are run almost continuously, the startup time of a D app would be vastly quicker

 - total memory consumption of the D programs would be much reduced

And on the other hand, (almost) every time a new DMD comes out, one would have to recompile the .so files? And therefore the apps too?

Sean Kelly wrote:
> Kirk McDonald wrote:
>> Walter Bright wrote:
>>> Kirk McDonald wrote:
>>>
>>>> Here's something that has been annoying me, and this week-old thread is as good a place as any to bring it up: Shared library support on Linux. I could not take D seriously if it did a "1.0" release without this. I do hate to cram more on your plate, Walter, but I consider this a more serious issue than even this import thing that has gripped the newsgroup for the past week.
>>>
>>>
>>> I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done.
>>>
>>> Will the shared libraries work with GDC?
>>
>> Ha! Well, at least this simple case does:
>>
>> [myso2.d]
>> import std.stdio;
>>
>> export extern(C)
>> void mysoprint() { writefln("Hello 'so' world!"); }
>>
>> [myso.d]
>> export extern(C) void mysoprint();
>>
>> [test.d]
>> import myso;
>>
>> void main() {
>>     mysoprint();
>> }
>>
>> $ gdc -shared -Wl,-soname,libmyso.so -o libmyso.so myso2.o -lc
>> /usr/bin/ld: warning: creating a DT_TEXTREL in object.
>>
>> (Not sure what that means...)
>>
>> $ sudo cp libmyso.so /usr/lib
>> $ gdc -c test.d
>> $ gdc test.o -Wl,-lmyso -o test
>> $ ./test
>> Hello 'so' world!
>>
>> Sweet. However, I am a little concerned. When making DLLs on Windows, there is some boilerplate code needed to initialize and shut down the GC and do some other routine things. Is something like that needed here?
> 
> I think it is.  Perhaps the best approach would be to expose two extern (C) functions: one for startup and one for shutdown.  By default, these would be called automatically by internal/dmain2, but the user could opt to call them in DllInit or whatever if he knows that function will not be the entry point for his program.  In Ares, I'd probably call these "cr_init" and "cr_term" where "cr" means "compiler runtime."
> 
> 
> Sean

Shouldn't it be "language runtime" or "D runtime"? The runtime is *made* by the compiler, but it is the runtime *of* D, not the runtime of the compiler. Compare: JRE = Java Runtime Environment. :P
(Yes I'm way picky with names... X-p )

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> 
> Shouldn't it be "language runtime" or "D runtime"? The runtime is *made* by the compiler, but it is the runtime *of* D, not the runtime of the compiler.

Probably.  I just use the term "compiler runtime" to indicate which portion of the code it represents, as Ares splits it out into three segments: the portion of the runtime that is compiler-specific, the garbage collector, and any user-visible code that is required to complete the package (which involves some thread code for use by the GC, at the very least).  I would consider the combination of these three components to be the "language runtime," as they are all required for a D program to run.


Sean

Georg Wrede wrote:
> Sean Kelly wrote:
>>
>> Yup.  It would be a trivial change to internal/dmain2.  I'll probably do it in Ares in the next few days, just to have it as an option.
> 
> This not being my specialty, I have to ask the dumb question:
> 
> does all this mean that
> 
>  - helloworld could be only a few kB

Probably.  Though dealing with DLLs is deceptive because the application would consume far more memory than just the few KB indicated by the EXE size.

>  - on a machine where D programs are run almost continuously, the startup time of a D app would be vastly quicker

I don't think so, because (I believe) there would still be a separate GC instance per app.

>  - total memory consumption of the D programs would be much reduced

Assuming a single shared GC, yes.


Sean