On 14 June 2012 13:36, Matthew Caron <Matt.Caron@redlion.net> wrote:
> So, we've been toying with using D on embedded systems, and one of the things that struck us as strange is that our emitted binaries don't link against a shared libphobos, and indeed, one does not even seem to be created when building GDC. Was this a conscious design decision? If so, why? Are there any plans to change it to use a shared library?
> --
> Matthew Caron, Build Engineer
> Sixnet, a Red Lion business | www.sixnet.com
> +1 (518) 877-5173 x138 office
>

Hi Matthew,

This is a pet peeve with us at the moment.  Yes, I can produce a shared libphobos for you, but the default runtime implementation does not support it, and the current workaround is specific to Linux systems only - possibly other related POSIX systems too, so long as /proc/self/maps exists on the system.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 06/14/2012 09:08 AM, Iain Buclaw wrote:
> Hi Matthew,
>
> This is a pet peeve with us at the moment.  Yes, I can produce a
> shared libphobos for you, but the default runtime implementation does
> not support it, and the current workaround is specific to Linux
> systems only - possibly other related POSIX systems too, so long as
> /proc/self/maps exists on the system.
>
> Regards

I am not professing to have copious amounts of time, but how might I be able to help, even if it is just to test things?

I have, at my disposal, the standard complement of x86 Linux boxen, as well as a variety of ARM-ish processors (hence my interest in cross compiling D), ranging from ARM9 (armv5t) up to Cortex-A8.

If adoption of D at my company proceeds, this will become more of a hot-button issue because demand for it will increase. As such, I might be able to actually devote some on the clock engineering time to it, rather than doing it in my spare time. As of right now, it is termed "not for production use", because D and GDC are both fairly new. (Yes, I know both D2 and GDC are both over 5 years old, but we're that conservative.). The crux of the issue is that, when you're trying to cram as much as you can into 16MB of NAND, shared libraries are your best friend.


-- 
Matthew Caron, Build Engineer
Sixnet, a Red Lion business | www.sixnet.com
+1 (518) 877-5173 x138 office

In any case use phobos and druntime as shared library that is possible as Fedora provide both Phobos and Druntime as shared library (build with ldc2 compiler dmdfe 2.059)

On 14 June 2012 14:18, Matthew Caron <Matt.Caron@redlion.net> wrote:
> On 06/14/2012 09:08 AM, Iain Buclaw wrote:
>>
>> Hi Matthew,
>>
>> This is a pet peeve with us at the moment.  Yes, I can produce a shared libphobos for you, but the default runtime implementation does not support it, and the current workaround is specific to Linux systems only - possibly other related POSIX systems too, so long as /proc/self/maps exists on the system.
>>
>> Regards
>
>
> I am not professing to have copious amounts of time, but how might I be able to help, even if it is just to test things?
>
> I have, at my disposal, the standard complement of x86 Linux boxen, as well
> as a variety of ARM-ish processors (hence my interest in cross compiling D),
> ranging from ARM9 (armv5t) up to Cortex-A8.
>
> If adoption of D at my company proceeds, this will become more of a hot-button issue because demand for it will increase. As such, I might be able to actually devote some on the clock engineering time to it, rather than doing it in my spare time. As of right now, it is termed "not for production use", because D and GDC are both fairly new. (Yes, I know both D2 and GDC are both over 5 years old, but we're that conservative.). The crux of the issue is that, when you're trying to cram as much as you can into 16MB of NAND, shared libraries are your best friend.
>
>

If the idea is to cram as much into 16MB of NAND, I would suggest that you avoid building libphobos at all, and just have the libdruntime library.  I will need to add this as a switch to the build for you. If you need any guidance on building as a shared library, I'll be available on IRC from around 7.30pm GMT+0 time.  Either on Freenode or OFTC in #d and #d.gdc.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 2012-06-14 15:08, Iain Buclaw wrote:

> Hi Matthew,
>
> This is a pet peeve with us at the moment.  Yes, I can produce a
> shared libphobos for you, but the default runtime implementation does
> not support it, and the current workaround is specific to Linux
> systems only - possibly other related POSIX systems too, so long as
> /proc/self/maps exists on the system.
>
> Regards

Which it does not on Mac OS X. This is also a problem on Mac OS X:

http://forum.dlang.org/thread/77AFA31F-5018-4AF5-8E27-63C9E7839B53@me.com

Don't know if GDC has that problem but DMD does.

-- 
/Jacob Carlborg

On 06/14/2012 10:28 AM, Iain Buclaw wrote:
> If the idea is to cram as much into 16MB of NAND, I would suggest that
> you avoid building libphobos at all, and just have the libdruntime
> library.

Is there documentation as to what things are in which library? (Apologies if this is a stupid question - I haven't dug into the implementation details of D heavily yet.)

Specifically, in the short term, we're interested in:
std.stdio
std.xml
std.linux
std.socket
std.getopt
std.json

(and, likely more, but those are what occur to me off the top of my head).

> I will need to add this as a switch to the build for you.
> If you need any guidance on building as a shared library, I'll be
> available on IRC from around 7.30pm GMT+0 time.  Either on Freenode or
> OFTC in #d and #d.gdc.

I appreciate the invite, but this is not really a short-term plan. I apologize if my email came off as implying more urgency than we actually have, and I don't want to take up a lot of your time on something that is some months off, if at all.

For a bit of background, my opinion is that D is going to be the next awesome systems programming language, eventually replacing C for most applications. It has all the nice features of Java and C#, while still being (reasonably) light and as fast as C in execution. I'm trying to get my company set up to use this now, so that we build familiarity with it. As such, the first step is to get GDC on ARM (which I have done). The need for shared libraries is something that I see on the horizon (if we do end up utilizing D heavily), but not something that is urgent today.

Of course, we do sell a line of products that are essentially industrially-hardened embedded Linux computers. If customers start asking for D instead of C, the above will become more accelerated.

-- 
Matthew Caron, Build Engineer
Sixnet, a Red Lion business | www.sixnet.com
+1 (518) 877-5173 x138 office

On Thu, 14 Jun 2012 15:28:44 +0100, Iain Buclaw wrote:

> On 14 June 2012 14:18, Matthew Caron <Matt.Caron@redlion.net> wrote:
>> On 06/14/2012 09:08 AM, Iain Buclaw wrote:
>>>
>>> Hi Matthew,
>>>
>>> This is a pet peeve with us at the moment.  Yes, I can produce a shared libphobos for you, but the default runtime implementation does not support it, and the current workaround is specific to Linux systems only - possibly other related POSIX systems too, so long as /proc/self/maps exists on the system.
>>>
>>> Regards
>>
>>
>> I am not professing to have copious amounts of time, but how might I be able to help, even if it is just to test things?
>>
>> I have, at my disposal, the standard complement of x86 Linux boxen, as
>> well as a variety of ARM-ish processors (hence my interest in cross
>> compiling D), ranging from ARM9 (armv5t) up to Cortex-A8.
>>
>> If adoption of D at my company proceeds, this will become more of a hot-button issue because demand for it will increase. As such, I might be able to actually devote some on the clock engineering time to it, rather than doing it in my spare time. As of right now, it is termed "not for production use", because D and GDC are both fairly new. (Yes, I know both D2 and GDC are both over 5 years old, but we're that conservative.). The crux of the issue is that, when you're trying to cram as much as you can into 16MB of NAND, shared libraries are your best friend.
>>
>>
>>
> If the idea is to cram as much into 16MB of NAND, I would suggest that you avoid building libphobos at all, and just have the libdruntime library.  I will need to add this as a switch to the build for you. If you need any guidance on building as a shared library, I'll be available on IRC from around 7.30pm GMT+0 time.  Either on Freenode or OFTC in #d and #d.gdc.
> 
> 
> Regards

I wish I could do that with DMD... DMD has -defaultlib=<name> but if developer leaves <name> to be empty compilation will fail.




-- 
Dejan Lekic
  mailto:dejan.lekic(a)gmail.com
  http://dejan.lekic.org

On 15 June 2012 09:06, Dejan Lekic <dejan.lekic@gmail.com> wrote:
> On Thu, 14 Jun 2012 15:28:44 +0100, Iain Buclaw wrote:
>
>> On 14 June 2012 14:18, Matthew Caron <Matt.Caron@redlion.net> wrote:
>>> On 06/14/2012 09:08 AM, Iain Buclaw wrote:
>>>>
>>>> Hi Matthew,
>>>>
>>>> This is a pet peeve with us at the moment.  Yes, I can produce a shared libphobos for you, but the default runtime implementation does not support it, and the current workaround is specific to Linux systems only - possibly other related POSIX systems too, so long as /proc/self/maps exists on the system.
>>>>
>>>> Regards
>>>
>>>
>>> I am not professing to have copious amounts of time, but how might I be able to help, even if it is just to test things?
>>>
>>> I have, at my disposal, the standard complement of x86 Linux boxen, as
>>> well as a variety of ARM-ish processors (hence my interest in cross
>>> compiling D), ranging from ARM9 (armv5t) up to Cortex-A8.
>>>
>>> If adoption of D at my company proceeds, this will become more of a hot-button issue because demand for it will increase. As such, I might be able to actually devote some on the clock engineering time to it, rather than doing it in my spare time. As of right now, it is termed "not for production use", because D and GDC are both fairly new. (Yes, I know both D2 and GDC are both over 5 years old, but we're that conservative.). The crux of the issue is that, when you're trying to cram as much as you can into 16MB of NAND, shared libraries are your best friend.
>>>
>>>
>>>
>> If the idea is to cram as much into 16MB of NAND, I would suggest that you avoid building libphobos at all, and just have the libdruntime library.  I will need to add this as a switch to the build for you. If you need any guidance on building as a shared library, I'll be available on IRC from around 7.30pm GMT+0 time.  Either on Freenode or OFTC in #d and #d.gdc.
>>
>>
>> Regards
>
> I wish I could do that with DMD... DMD has -defaultlib=<name> but if developer leaves <name> to be empty compilation will fail.
>
>

You mean something like -nodefaultlib or -nophoboslib? (both which are
options in gdc ;)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Fri, 15 Jun 2012 08:06:48 +0000, Dejan Lekic wrote:

> On Thu, 14 Jun 2012 15:28:44 +0100, Iain Buclaw wrote:
> 
>> On 14 June 2012 14:18, Matthew Caron <Matt.Caron@redlion.net> wrote:
>>> On 06/14/2012 09:08 AM, Iain Buclaw wrote:
>>>>
>>>> Hi Matthew,
>>>>
>>>> This is a pet peeve with us at the moment.  Yes, I can produce a shared libphobos for you, but the default runtime implementation does not support it, and the current workaround is specific to Linux systems only - possibly other related POSIX systems too, so long as /proc/self/maps exists on the system.
>>>>
>>>> Regards
>>>
>>>
>>> I am not professing to have copious amounts of time, but how might I be able to help, even if it is just to test things?
>>>
>>> I have, at my disposal, the standard complement of x86 Linux boxen, as
>>> well as a variety of ARM-ish processors (hence my interest in cross
>>> compiling D), ranging from ARM9 (armv5t) up to Cortex-A8.
>>>
>>> If adoption of D at my company proceeds, this will become more of a hot-button issue because demand for it will increase. As such, I might be able to actually devote some on the clock engineering time to it, rather than doing it in my spare time. As of right now, it is termed "not for production use", because D and GDC are both fairly new. (Yes, I know both D2 and GDC are both over 5 years old, but we're that conservative.). The crux of the issue is that, when you're trying to cram as much as you can into 16MB of NAND, shared libraries are your best friend.
>>>
>>>
>>>
>> If the idea is to cram as much into 16MB of NAND, I would suggest that you avoid building libphobos at all, and just have the libdruntime library.  I will need to add this as a switch to the build for you. If you need any guidance on building as a shared library, I'll be available on IRC from around 7.30pm GMT+0 time.  Either on Freenode or OFTC in #d and #d.gdc.
>> 
>> 
>> Regards
> 
> I wish I could do that with DMD... DMD has -defaultlib=<name> but if developer leaves <name> to be empty compilation will fail.

Actually, after some chat on IRC, thanks to Daniel, I've found out that it is possible to do it with -defaultlib=druntime , but then you must have libdruntime.a installed (which is not the case if developer installed packaged dmd because druntime is inside phobos).

-- 
Dejan Lekic
  mailto:dejan.lekic(a)gmail.com
  http://dejan.lekic.org

dmd -shared testlib.d

error:

relocation R_X86_64_32 against '.data' can not be used when making a shared object; recompile with -fPIC

could not read symbols:bad value

so gdc error。。。

my system is ubuntu 64b