| View previous topic :: View next topic |
| Author |
Message |
larsivi
Site Admin
Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway
|
 Posted: Wed Aug 04, 2004 1:07 am Post subject: Compile error in SVN code |
 |
|
I've updated from SVN and try to compile mango. (I'm actually trying to get my aap-recipe up to date so you can include it). Anyway, an error occurs when compiling ClusterCache. The message is:
mango\io\Timer.d(46): module thread is in multiple packages std.thread
I don't really get it (Timer isn't imported from ClusterCache and thus I can't be bothered to sift through the layers of imports), as it seems that all imports are private and shouldn't cause any problems.
PS: It's on Windows. |
|
| Back to top |
|
 |
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Wed Aug 04, 2004 3:06 am Post subject: Re: Compile error in SVN code |
|
|
| larsivi wrote: | I've updated from SVN and try to compile mango. (I'm actually trying to get my aap-recipe up to date so you can include it). Anyway, an error occurs when compiling ClusterCache. The message is:
mango\io\Timer.d(46): module thread is in multiple packages std.thread
I don't really get it (Timer isn't imported from ClusterCache and thus I can't be bothered to sift through the layers of imports), as it seems that all imports are private and shouldn't cause any problems.
PS: It's on Windows. |
Thanks!
What's on SVN is in flux right now, since Beta 9.2 is just about to be released (B9.1 is still on the download page). Regardless, I don't get this error when I build everything. Will rework it anyway to get rid of the std.thread import. Which version of the compiler are you using Larsivi? I'm using v0.97 ...
(unfortunately, imports are still a PITA). |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Wed Aug 04, 2004 3:45 am Post subject: |
|
|
Rearranged a couple of things that may help ... perhaps it'll compile now?
(p.s. SVN all up-to-date) |
|
| Back to top |
|
|
larsivi
Site Admin
Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway
|
| Posted: Wed Aug 04, 2004 3:55 am Post subject: |
|
|
That's better!  |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Wed Aug 04, 2004 4:07 am Post subject: |
|
|
| larsivi wrote: | | That's better! |
Sometimes one has to "tease" a set of imports to make them work ... if it were animated/alive, this would be akin to tickling it  |
|
| Back to top |
|
|
larsivi
Site Admin
Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway
|
| Posted: Thu Aug 05, 2004 12:40 pm Post subject: |
|
|
Just FYI: larsivi => lars iv i => Lars Ivar Igesund
Then over to another error, or rather linking problem. It's probably my fault, anyway since I don't use your makefile. 
Well, the problem is the wsock32 stuff. What I do/have done is this:
Compile the mango source and create mango.lib (with lib.exe). No problems so far.
Then I compile one of the test programs but it can't find the wsock32 stuff! I used implib to create wsock32.lib from C:\Windows\System32\wsock32.dll and put it in C:\dm\lib. This lead to link.exe finding wsock32.lib, but it still couldn't link. One possibility I will try, is putting wsock32.lib together with wsock32.dll, but I kinda find the solution non-optimal. I have a feeling that my system don't search for the dll as it should. Any tips? For setting up my dev-environment, or detecting it automatically (which A-A-P is capable of), or something else? Are you perhaps planning to load it dynamically (your post in the DSP forum suggest that you might)? |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Thu Aug 05, 2004 2:46 pm Post subject: |
|
|
Is it a link-time or run-time error? I guess it's link-time since you don't mention the "can't find x.dll" message that Win32 will give you when trying to execute your program. If that's the case then its a problem with the wsock32.lib ... perhaps the symbols somehow got mangled during the implib process?
Of course, that assumes you have specified the wsock32.lib to the linker along with mango.lib? You still have to do that part manually (which you appear to have done ~ forgive me for stating the obvious <g>). I can send you the wsock32.lib I link with if you can't resolve the issue. I understand it acts as a bridge to some other DLL ...
Would really, really like to convert Mango to a full-blown DLL ... the truth is that D expects to be statically linked at this stage, so there appears to be a lot of necessary work with stubs, factories, and so on. Unless you can direct me otherwise Lars!
Reasons for loading Mango dynamically are many: the current goal is to reduce the size of the DLLs representing LAN-executable modules. Right now, they have to be statically linked with everything, and then loaded up. As you might imagine, there's a "significant" amount of baggage involved 
D sorely needs to mature in this particular (dynamic loading) arena. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Fri Aug 06, 2004 2:44 am Post subject: |
|
|
| Did you have any luck with that one, Lars? |
|
| Back to top |
|
|
larsivi
Site Admin
Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway
|
| Posted: Fri Aug 06, 2004 7:17 am Post subject: |
|
|
| Sorry, met an A-A-P bug that needs to fixed first. I'll answer some of your points at a later time. |
|
| Back to top |
|
|
larsivi
Site Admin
Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway
|
| Posted: Sun Aug 08, 2004 12:39 pm Post subject: |
|
|
| kris wrote: | Would really, really like to convert Mango to a full-blown DLL ... the truth is that D expects to be statically linked at this stage, so there appears to be a lot of necessary work with stubs, factories, and so on. Unless you can direct me otherwise Lars!
|
I have fixed my local copy of A-A-P now, but haven't tried linking more of mango yet. Anyway, it is not a problem to create dll's with D, actually A-A-P creates both the DllMain and the .def file for you (unless you've provided it in your project), and it works for the one-function-test-dll. There are two problems with D dll's. One is the GC and the location of allocated memory. The other is supposedly with OO-libs. The issue has to do with dll's not exporting classes, I believe, and thus making it difficult to new them as usual. (I haven't investigated why factories help.) What's up with stubs and 'so on'? |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Sun Aug 08, 2004 1:18 pm Post subject: |
|
|
| larsivi wrote: | | There are two problems with D dll's. One is the GC and the location of allocated memory. The other is supposedly with OO-libs. The issue has to do with dll's not exporting classes, I believe, and thus making it difficult to new them as usual. (I haven't investigated why factories help.) What's up with stubs and 'so on'? |
Going the factory route, the client would explicitly bind a single static method (per class) from the DLL, and use that to return an instance of the Object itself (or something like that). Unfortunately, that Object is allocated by the GC belonging to the library, which doesn' t see a reference held by a client. There's also the issue of throwing exceptions across DLL boundaries. Haven't tried either myself, but understand neither is properly supported. The GC issue might potentially be resolved via a "new" overload within the DLL which invokes a client-provided delegate to actually perform the allocation.
The 'stub' approach could be used for 'functional' programming (a la Phobos) where a static library shadows all the DLL functions and redispatches when invoked; saving the client from the hassle of explicitly mapping said functions. One might combine this with the factory approach for OO programming. I don't care much for any of these.
All told, I've clearly avoided even attempting the DLL route; figured I'd wait until that matures a bit further and, besides, there's far too many other things to get working first
Would much appreciate hearing your experience in this arena, Lars. |
|
| Back to top |
|
|
larsivi
Site Admin
Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway
|
| Posted: Sun Aug 08, 2004 2:30 pm Post subject: |
|
|
| kris wrote: |
Going the factory route, the client would explicitly bind a single static method (per class) from the DLL, and use that to return an instance of the Object itself (or something like that). Unfortunately, that Object is allocated by the GC belonging to the library, which doesn' t see a reference held by a client. There's also the issue of throwing exceptions across DLL boundaries. Haven't tried either myself, but understand neither is properly supported. The GC issue might potentially be resolved via a "new" overload within the DLL which invokes a client-provided delegate to actually perform the allocation.
The 'stub' approach could be used for 'functional' programming (a la Phobos) where a static library shadows all the DLL functions and redispatches when invoked; saving the client from the hassle of explicitly mapping said functions. One might combine this with the factory approach for OO programming. I don't care much for any of these.
All told, I've clearly avoided even attempting the DLL route; figured I'd wait until that matures a bit further and, besides, there's far too many other things to get working first
Would much appreciate hearing your experience in this arena, Lars. |
My experience isn't much to hear about. I've made simple dll's that work, but they don't need allocated memory to be transferred over any boundaries.
I've always heard that dll's are THE way to go in a multitasking-sharing-loving environment, but the difficulties seems to defeat the profit margins (especially when you need static libraries to use the dynamic one).
I had one crazy idea recently. Could a solution to at least some of the problems be to have the GC as a central server/service? I suppose it is possible that unless this is part of the OS, it won't have enough access to do what's necessary. So we're back to ref-counting and explicit delete's.
I suppose a discussion in the newsgroup would be useful, but I suspect that whatever is needed isn't part of the 1.0 roadmap. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Sun Aug 08, 2004 7:27 pm Post subject: |
|
|
| larsivi wrote: | | I suppose a discussion in the newsgroup would be useful, but I suspect that whatever is needed isn't part of the 1.0 roadmap. |
There's one that just opened ... let's see where it leads. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
