On Wed, 29 Jul 2009 03:51:24 +0400, Sergey Gromov wrote:
> Tue, 28 Jul 2009 21:01:33 + (UTC), BCS wrote:
>
>> Reply to teo,
>>
>>> On Mon, 27 Jul 2009 20:34:44 +, BCS wrote:
>>>
Reply to teo,
> I did some tests and here are the results: D cannot be used in
> Shared Ob
On Tue, 28 Jul 2009 21:01:33 +, BCS wrote:
> Reply to teo,
>
>> On Mon, 27 Jul 2009 20:34:44 +, BCS wrote:
>>
>>> Reply to teo,
>>>
I did some tests and here are the results: D cannot be used in Shared
Objects. The only case that works is when no classes are exported and
Tue, 28 Jul 2009 21:01:33 + (UTC), BCS wrote:
> Reply to teo,
>
>> On Mon, 27 Jul 2009 20:34:44 +, BCS wrote:
>>
>>> Reply to teo,
>>>
I did some tests and here are the results: D cannot be used in
Shared Objects. The only case that works is when no classes are
exported a
Reply to teo,
On Mon, 27 Jul 2009 20:34:44 +, BCS wrote:
Reply to teo,
I did some tests and here are the results: D cannot be used in
Shared Objects. The only case that works is when no classes are
exported and when there are no references to Phobos within the
library.
this works:
it
Jérôme M. Berger wrote:
Or just use the -I command line argument to point to the folder in
which test.d is stored.
Jerome
PS: Just as in C/C++, really
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signat
Daniel Keep wrote:
teo wrote:
On Mon, 27 Jul 2009 20:34:44 +, BCS wrote:
Reply to teo,
I did some tests and here are the results: D cannot be used in Shared
Objects. The only case that works is when no classes are exported and
when there are no references to Phobos within the library.
On Tue, 28 Jul 2009 17:02:31 +1000, Daniel Keep wrote:
> teo wrote:
>> On Mon, 27 Jul 2009 20:34:44 +, BCS wrote:
>>
>>> Reply to teo,
>>>
I did some tests and here are the results: D cannot be used in Shared
Objects. The only case that works is when no classes are exported and
On Mon, 27 Jul 2009 20:34:44 +, BCS wrote:
> Reply to teo,
>
>> I did some tests and here are the results: D cannot be used in Shared
>> Objects. The only case that works is when no classes are exported and
>> when there are no references to Phobos within the library.
>
>
> this works:
>
i
Reply to Daniel,
Well of course it can't compile: YOU MOVED test.d! What do you expect
when you tell it to import a file that no longer exists? The compiler
is not psychic.
If you really, absolutely have to have the two parts in different
directories, just generate a header file.
dmd -H -c -
teo wrote:
> On Mon, 27 Jul 2009 20:34:44 +, BCS wrote:
>
>> Reply to teo,
>>
>>> I did some tests and here are the results: D cannot be used in Shared
>>> Objects. The only case that works is when no classes are exported and
>>> when there are no references to Phobos within the library.
>>
On Mon, 27 Jul 2009 20:34:44 +, BCS wrote:
> Reply to teo,
>
>> I did some tests and here are the results: D cannot be used in Shared
>> Objects. The only case that works is when no classes are exported and
>> when there are no references to Phobos within the library.
>
>
> this works:
>
n
Reply to teo,
I did some tests and here are the results: D cannot be used in Shared
Objects. The only case that works is when no classes are exported and
when there are no references to Phobos within the library.
this works:
module test;
int test1() { return 0; }
char[] test2() { return "hel
Reply to teo,
On Mon, 27 Jul 2009 17:17:35 +, BCS wrote:
Reply to teo,
I did some tests and here are the results: D cannot be used in
Shared Objects. The only case that works is when no classes are
exported and when there are no references to Phobos within the
library.
two of your fail
On Mon, 27 Jul 2009 17:17:35 +, BCS wrote:
> Reply to teo,
>
>> I did some tests and here are the results: D cannot be used in Shared
>> Objects. The only case that works is when no classes are exported and
>> when there are no references to Phobos within the library.
>>
>>
> two of your fa
Reply to teo,
I did some tests and here are the results: D cannot be used in Shared
Objects. The only case that works is when no classes are exported and
when there are no references to Phobos within the library.
two of your fail cases have non SO realted errors:
==
DOESN'T WORK wit
On Fri, 17 Jul 2009 06:15:18 +, Jesse Phillips wrote:
> On Fri, 17 Jul 2009 01:35:37 -0400, teo wrote:
>
>> Hmm, you say it is working. Can you show me how to do that on 32-bit
>> Linux with dmd? How would you compile Phobos as an external library?
>> Please let me know, if you are aware of a
"Benji Smith" wrote in message
news:h3vmi3$ro...@digitalmars.com...
> Nick Sabalausky wrote:
>> "BCS" wrote in message
>> news:78ccfa2d4382d8cbd4ffb8875...@news.digitalmars.com...
>>> Reply to teo,
>>>
Well, to some extent this will do the job, but at some point you would
need to extr
Nick Sabalausky wrote:
"BCS" wrote in message
news:78ccfa2d4382d8cbd4ffb8875...@news.digitalmars.com...
Reply to teo,
Well, to some extent this will do the job, but at some point you would
need to extract some stuff and put it in libraries, so that it can be
reused by other applications. Thin
Nick Sabalausky wrote:
"Benji Smith" wrote in message
news:h3qus2$1an...@digitalmars.com...
For custom loading into D applications, why even bother using a DLL as a
container? Why not design a file format (maybe even DDL as it currently
exists) and use that as the primary dynamic loading & lin
"BCS" wrote in message
news:78ccfa2d4382d8cbd4ffb8875...@news.digitalmars.com...
> Reply to teo,
>
>> Well, to some extent this will do the job, but at some point you would
>> need to extract some stuff and put it in libraries, so that it can be
>> reused by other applications. Think about an app
"Benji Smith" wrote in message
news:h3qus2$1an...@digitalmars.com...
>
> For custom loading into D applications, why even bother using a DLL as a
> container? Why not design a file format (maybe even DDL as it currently
> exists) and use that as the primary dynamic loading & linking machanism,
Daniel Keep wrote:
If we have, for example, a C app that is using D code as plugins, each
plugin will ask the system for "dmdrt.dll" using its minimal embedded
DDL stub. But since they're system calls, we should only get one copy.
I'm not sure exactly how the system will share that library, tho
Reply to teo,
BCS Wrote:
Unless I has some some compelling reasons not to, yes, I would prefer
to. Aside from reasons like needing to be able to modularly update
the app or huge (like GBs) amounts of executable code or some kind of
plug-ins via DLLs approach, (all of those are exceptions, not
BCS Wrote:
> Reply to teo,
>
> > Jarrett Billingsley Wrote:
> >
> >> On Thu, Jul 16, 2009 at 2:12 AM, teo wrote:
> >>
> >>> One major problem is the D's inability to create dynamic libraries.
> >>> D is a great language, but without that ability it can only be used
> >>> for small programs, too
Hello Daniel,
Although, in that case, it probably wouldn't hurt
anything (aside from memory usage)
if that's a problem, you have bigger problems. :)
to simply statically link the
runtime and standard library in; if the host app is C/C++, then the
plugins probably won't be able to stomp all
Jarrett Billingsley wrote:
> On Thu, Jul 16, 2009 at 9:30 PM, grauzone wrote:
>> I know a simple counter measure: use DLLs as a container for the DDL
>> specific format. AFAIK C# does exactly the same.
>
> Hmm!
You know, this is so obvious in retrospect.
?cookie grauzone
What we really need i
On Fri, 17 Jul 2009 01:35:37 -0400, teo wrote:
> Hmm, you say it is working. Can you show me how to do that on 32-bit
> Linux with dmd? How would you compile Phobos as an external library?
> Please let me know, if you are aware of an article describing that.
> Thank you in advance.
My guess is th
Jarrett Billingsley Wrote:
> ON EVERY OTHER OPERATING SYSTEM (Linux, Unix, OSX, *whatever*), shared
> libraries CAN have unresolved externals, so Phobos *does not* have to
> be included in the shared libraries. Shared libraries ALREADY work
> the way you expect them to on every OS besides Windows
Benji Smith Wrote:
> Jarrett Billingsley wrote:
> > On Thu, Jul 16, 2009 at 4:44 PM, teo wrote:
> >
> >>> For two, there is *no problem*
> >>> with creating D libraries on any platform other than Windows, and it
> >>> is entirely through Windows' fault that it has the problems it does
> >>> with
On Fri, Jul 17, 2009 at 12:43 AM, novice2 wrote:
> sorry, i don't understand: how D differ from C or C++ in all related to DLL
> in Windows? imho, only difference from MS VC is: VC have runtime in DLL form,
> but D have no.
>
C++ does not have mounds of runtime type information. D does. D uses
sorry, i don't understand: how D differ from C or C++ in all related to DLL in
Windows? imho, only difference from MS VC is: VC have runtime in DLL form, but
D have no.
On Thu, Jul 16, 2009 at 9:30 PM, grauzone wrote:
> I know a simple counter measure: use DLLs as a container for the DDL
> specific format. AFAIK C# does exactly the same.
Hmm!
> By the way, can't you simply put the runtime into a DLL, and load that by
> the host program? D DLL would also depend f
Jussi Jumppanen wrote:
BCS Wrote:
If I'm understanding the situation correctly, what you just
described is ONLY a problem on Windows and only because
of a design flaw in the way DLL's work.
That might be well be the case.
But to basically then say that “when developing with D on Windows
i
BCS Wrote:
> If I'm understanding the situation correctly, what you just
> described is ONLY a problem on Windows and only because
> of a design flaw in the way DLL's work.
That might be well be the case.
But to basically then say that when developing with D on Windows
it is highly recommen
Jarrett Billingsley wrote:
On Thu, Jul 16, 2009 at 4:44 PM, teo wrote:
For two, there is *no problem*
with creating D libraries on any platform other than Windows, and it
is entirely through Windows' fault that it has the problems it does
with DLLs.
Well, let us assume that you can create dy
Reply to Jarrett,
It's *possible*, but very tedious. It seems almost pointless when you
consider the existence of DDL.
Nothing is to tedious in programming. If a task is tedious, it's almost a
given that it's automatable.
On Thu, Jul 16, 2009 at 7:13 PM, Rainer Deyke wrote:
> Jarrett Billingsley wrote:
>> ON WINDOWS, DLLs are not allowed to have unresolved externals. So if
>> you create a DLL in D, yes, Phobos will be linked in. THERE IS
>> NOTHING THAT CAN BE DONE ABOUT THAT. It's a limitation on the way
>> DLLs
Reply to Rainer,
Jarrett Billingsley wrote:
ON WINDOWS, DLLs are not allowed to have unresolved externals. So if
you create a DLL in D, yes, Phobos will be linked in. THERE IS
NOTHING THAT CAN BE DONE ABOUT THAT. It's a limitation on the way
DLLs work.
In theory, wouldn't it also be possi
Jarrett Billingsley wrote:
> ON WINDOWS, DLLs are not allowed to have unresolved externals. So if
> you create a DLL in D, yes, Phobos will be linked in. THERE IS
> NOTHING THAT CAN BE DONE ABOUT THAT. It's a limitation on the way
> DLLs work.
In theory, wouldn't it also be possible to solve th
On Thu, Jul 16, 2009 at 4:44 PM, teo wrote:
>> For two, there is *no problem*
>> with creating D libraries on any platform other than Windows, and it
>> is entirely through Windows' fault that it has the problems it does
>> with DLLs.
>>
> Well, let us assume that you can create dynamic libraries
Trass3r schrieb:
Go use DDL, you may also try h3r3tic's enhanced fork with a new linker:
http://team0xf.com:1024/ext/file/70b9addb42d5/ddl/
http://team0xf.com:1024/linker/
Here's a more detailed explanation:
http://h3.team0xf.com/devlog/?p=12
teo schrieb:
You're missing something :) DDL doesn't require you to have a D
runtime in the shared library because unlike DLLs, DDLs can have
unresolved externals. That's the main issue: DLLs must have performed
all their symbol resolution at link-time, and cannot automatically
load symbols out
Reply to teo,
Jarrett Billingsley Wrote:
On Thu, Jul 16, 2009 at 2:12 AM, teo wrote:
One major problem is the D's inability to create dynamic libraries.
D is a great language, but without that ability it can only be used
for small programs, tools, etc. and never in production.
For one, I q
Jarrett Billingsley Wrote:
> On Thu, Jul 16, 2009 at 2:12 AM, teo wrote:
> > One major problem is the D's inability to create dynamic libraries. D is a
> > great language, but without that ability it can only be used for small
> > programs, tools, etc. and never in production.
>
> For one, I qu
On Thu, Jul 16, 2009 at 10:44 AM, Jarrett
Billingsley wrote:
> On Thu, Jul 16, 2009 at 2:12 AM, teo wrote:
>> One major problem is the D's inability to create dynamic libraries. D is a
>> great language, but without that ability it can only be used for small
>> programs, tools, etc. and never in
On Thu, Jul 16, 2009 at 2:12 AM, teo wrote:
> One major problem is the D's inability to create dynamic libraries. D is a
> great language, but without that ability it can only be used for small
> programs, tools, etc. and never in production.
For one, I question your logic that without dynamic l
46 matches
Mail list logo
