View previous topic :: View next topic |
Author |
Message |
teqdruid
Joined: 11 May 2004 Posts: 390 Location: UMD
|
Posted: Thu Aug 19, 2004 12:00 pm Post subject: SVN HEAD Fails to compile under Linux |
|
|
The SVN HEAD code won't compile under linux with the latest DMD (0.9. I had to make the following changes to get it to compile:
Code: |
Index: mango/log/Event.d
===================================================================
--- mango/log/Event.d (revision 690)
+++ mango/log/Event.d (working copy)
@@ -55,6 +55,10 @@
extern(Windows) int QueryPerformanceFrequency(ulong *frequency);
}
+version (linux)
+{
+ private import std.c.linux.linux;
+}
/*******************************************************************************
Contains all information about a logging event, and is passed around
Index: mango/io/System.d
===================================================================
--- mango/io/System.d (revision 690)
+++ mango/io/System.d (working copy)
@@ -37,8 +37,10 @@
private import std.c.time;
-private import std.thread;
+private import std.thread;
+private import std.string;
+
/*******************************************************************************
Stuff for sysError(), kindly provided by Regan Heath.
@@ -87,6 +89,7 @@
version (linux)
{
extern (C) char *strerror (int);
+ private import std.c.linux.linux;
}
/*******************************************************************************
|
|
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Thu Aug 19, 2004 1:38 pm Post subject: |
|
|
Thanks;
Just had a major battle with the compiler, over conflicting strlen() names. Phobos std.string truly sucks (it pollutes the namespace terribly). The only Mango module still using std.string is mango.io.Socket, and that will eventually be retrofitted also.
The std.c.linux.linux thing is related to the time_t changes that took place recently. I screwed up, thinking that gettimeofday() was also moved to std.c.time
Appreciate your help! |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Sun Aug 29, 2004 8:10 am Post subject: |
|
|
Kris,
I was just playing around with the Linux build again. Looks like the most recent svn trunk is missing mango/io/Printf.d. It's present in the zip files, though. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Sun Aug 29, 2004 8:56 am Post subject: |
|
|
Yet another problem with linux compilation:
getError() is no longer present in std.c.linux.linux, so make stops at a number of places with undefined symbol error (FileConduit.d, FileProxy.d, and Socket.d).
adding,
extern (C) int getError();
at the same locations as the import std.c.linux.linux fixes the problem. Why is getError no longer there? Walter must have changed phobos again.
There are several wierd issues going on with FileBucket.d and functions "read" and "close" not matching argument types. Is this the same problem that was happening before?
I'm using DMD 0.100.
Later,
John |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Mon Aug 30, 2004 11:28 am Post subject: |
|
|
JJR wrote: | Kris,
I was just playing around with the Linux build again. Looks like the most recent svn trunk is missing mango/io/Printf.d. It's present in the zip files, though. |
Hey there John;
SVN head is usually in a state of flux until immediately before the next release. The zip files are really the only place to get a frozen picture (but I sometimes mess those up also ...)
Thanks for the heads' up on Walter's changes. I've now moved all getErrno() dependencies into System.d, to isolate that kind of thing a bit better.
Can you give me some more info on the FileBucket issue? It sounds a bit suspicious, but could be due to SVN being out of synch rather than anything nastier. I'll start to get SVN synched today or tomorrow.
BTW, I have a couple of ideas for fixing the everlasting Multicast issue on linux ~ if there's any chance you could try them on your linux box, I'd be indebted ...
- Kris |
|
Back to top |
|
|
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Mon Aug 30, 2004 11:40 am Post subject: |
|
|
kris wrote: | SVN head is usually in a state of flux until immediately before the next release. The zip files are really the only place to get a frozen picture (but I sometimes mess those up also ...)
|
I feel it's common decency to make sure every commit compile. Not that I suggest you're indecent, or something |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Mon Aug 30, 2004 11:54 am Post subject: |
|
|
larsivi wrote: | kris wrote: | SVN head is usually in a state of flux until immediately before the next release. The zip files are really the only place to get a frozen picture (but I sometimes mess those up also ...)
|
I feel it's common decency to make sure every commit compile. Not that I suggest you're indecent, or something |
Oh, you're closer to the truth than I care to admit
Do you have some general ideas on how to make that strategy work effectively? |
|
Back to top |
|
|
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Mon Aug 30, 2004 11:58 am Post subject: |
|
|
kris wrote: | Do you have some general ideas on how to make that strategy work effectively? |
Didn't know it was difficult My opionion probably stems from the fact that a couple of other projects I've followed, often suggest using CVS/SVN and then it HAS to compile at all times. Just don't commit before it compiles for you? |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Mon Aug 30, 2004 12:06 pm Post subject: |
|
|
kris wrote: | SVN head is usually in a state of flux until immediately before the next release. The zip files are really the only place to get a frozen picture (but I sometimes mess those up also ...) |
Ugh... sorry, I fogot about that. You've mentioned that before.
kris wrote: | Thanks for the heads' up on Walter's changes. I've now moved all getErrno() dependencies into System.d, to isolate that kind of thing a bit better. |
Oops... yes, I meant getErrno() of course (not getError()). Nice to hear about the move to System.d. That will work nicely.
kris wrote: | Can you give me some more info on the FileBucket issue? It sounds a bit suspicious, but could be due to SVN being out of synch rather than anything nastier. I'll start to get SVN synched today or tomorrow. |
I'll give you more details once I try the zipped download instead of the SVN source. You are right that it could have been merely an issue a package sync issue.
kris wrote: | BTW, I have a couple of ideas for fixing the everlasting Multicast issue on linux ~ if there's any chance you could try them on your linux box, I'd be indebted ... |
Yep, no problem. I've been doing a little researching on socket and thread theories to boost my golden screwdriver abilities a bit too. Armed with a little more knowledge, we'll see what kind of havoc I can create. |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Mon Aug 30, 2004 12:16 pm Post subject: |
|
|
larsivi wrote: | kris wrote: | Do you have some general ideas on how to make that strategy work effectively? |
Didn't know it was difficult My opionion probably stems from the fact that a couple of other projects I've followed, often suggest using CVS/SVN and then it HAS to compile at all times. Just don't commit before it compiles for you? |
Right! There are a few little gotcha's I've noticed while using SVN. This particular one has to do with the renaming of a file (Printf.d): if you rename the module locally, SVN doesn't know the change happened so it won't do a delete/add during a commit. Instead, you have to rename using an SVN client (such as tortoise, or the cmd line) but that causes the SVN name to change also -- now HEAD is out of synch with, say, the build file. I may have screwed this one up somewhere along the way .... wouldn't be the first time! |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Mon Aug 30, 2004 12:17 pm Post subject: |
|
|
JJR wrote: | kris wrote: | SVN head is usually in a state of flux until immediately before the next release. The zip files are really the only place to get a frozen picture (but I sometimes mess those up also ...) |
Ugh... sorry, I fogot about that. You've mentioned that before.
kris wrote: | Thanks for the heads' up on Walter's changes. I've now moved all getErrno() dependencies into System.d, to isolate that kind of thing a bit better. |
Oops... yes, I meant getErrno() of course (not getError()). Nice to hear about the move to System.d. That will work nicely.
kris wrote: | Can you give me some more info on the FileBucket issue? It sounds a bit suspicious, but could be due to SVN being out of synch rather than anything nastier. I'll start to get SVN synched today or tomorrow. |
I'll give you more details once I try the zipped download instead of the SVN source. You are right that it could have been merely an issue a package sync issue.
kris wrote: | BTW, I have a couple of ideas for fixing the everlasting Multicast issue on linux ~ if there's any chance you could try them on your linux box, I'd be indebted ... |
Yep, no problem. I've been doing a little researching on socket and thread theories to boost my golden screwdriver abilities a bit too. Armed with a little more knowledge, we'll see what kind of havoc I can create. |
Thanks John!
Once I get all these updates checked-in, I'll run a couple of ideas by you ... |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Mon Aug 30, 2004 3:08 pm Post subject: |
|
|
JJR wrote: | Yet another problem with linux compilation:
getError() is no longer present in std.c.linux.linux, so make stops at a number of places with undefined symbol error (FileConduit.d, FileProxy.d, and Socket.d).
adding,
extern (C) int getError();
at the same locations as the import std.c.linux.linux fixes the problem. Why is getError no longer there? Walter must have changed phobos again.
There are several wierd issues going on with FileBucket.d and functions "read" and "close" not matching argument types. Is this the same problem that was happening before?
I'm using DMD 0.100.
Later,
John |
SVN is now all up-to-date. If those linux issues are fixed, I'll release a Beta 9.3 ... |
|
Back to top |
|
|
teqdruid
Joined: 11 May 2004 Posts: 390 Location: UMD
|
Posted: Mon Aug 30, 2004 4:58 pm Post subject: Compile error |
|
|
Quote: | SVN is now all up-to-date. If those linux issues are fixed, I'll release a Beta 9.3 ... |
Might want to hold off... from the SVN HEAD running make -f linux.make:
mango/base/System.d(246): undefined identifier period
make: *** [libmango.a] Error 1 |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Mon Aug 30, 2004 5:57 pm Post subject: Re: Compile error |
|
|
demmegod wrote: | Quote: | SVN is now all up-to-date. If those linux issues are fixed, I'll release a Beta 9.3 ... |
Might want to hold off... from the SVN HEAD running make -f linux.make:
mango/base/System.d(246): undefined identifier period
make: *** [libmango.a] Error 1 |
I'll check it out right now ... ... okay ~ fixed. Thanks! |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Mon Aug 30, 2004 6:21 pm Post subject: |
|
|
Kris,
As suspected, it appears syncing with svn doesn't clean up my local mango properly. I would do better to delete it all each time. So instead I tried building the 0.9.2 zip package. The wierd FileProxy errors are gone, but a whole wack of smaller symbol problems appear. They look like they are pretty minor. Mostly more getErrno() and missing imports of std.c.linux.linux. |
|
Back to top |
|
|
|