[JJR]

Thanks Sean!

Your efforts are much appreciated. I'm looking forward to making use of Ares on Linux exclusively.

-JJR

[sean]

Sure thing Posix header changes will be filtering in over the next few days.

Finished (theoretically):

inttypes
pthread
sched
semaphore
unistd

In progress:

signal
time
sys/types

[sean]

By the way. If anyone wants to submit C header patches, please use the "c_long" alias from std.c.config for any "long" or "long int" types, and "c_ulong" for any "unsigned long" or "unsigned long int" types. This should (hopefully) allow for 64-bit OS compatibility without header changes.

[sean]

Okay, I think the POSIX headers are complete for Linux builds. If anyone notices a problem, please let me know.

I need to double-check the diffs Kashia sent me to make sure everything is in for darwin, so if anyone feels inclined to test that in the meantime please let me know if there are any problems (I'd been editing the files so much that an automated merge didn't work so I did it manually).

The last step will be to finish std.thread which should take another day or two. If anyone is incredibly eager to get all this working, it should be sufficient to do whatever is necessary to get std.thread to build and then simply avoid multithreaded programming for now.

[larsivi]

doing make -f linux.mak here (Kubuntu Breezy) on revision 301, I get

[jcomellas]

[sean]

Thanks.

[sean]

Okay, Ares should now build on Linux using DMD. Build each of the three libraries individually, then assemble them all into one library via something like this:

[JJR]

Excellent work!

It builds now. Thanks again, Sean.

I'll have to start testing it soon.

-JJR

[sean]

Okay, quick update on how to make Ares on Linux. Build each of the libraries as normal, then go up one directory to ares/trunk/src and issue this command:

[sean]

One last update. I've improved the 'linux.mak' that lives in trunk/src, so you should now be able to build and install Ares just by using that. Just do:

[sean]

The scripts lightoze supplied have me able to successfully link against Ares on Linux. Here's a quick rundown of the current process (from the top of the Ares SVN tree)):

> cd trunk/src
> ./fix_dfiles.sh
> make clean -flinux.mak
> make -flinux.mak
> make install -flinux.mak
> sudo cp libphobos.a /usr/lib/.

Then copy the Ares source to your include directory.

The makefile for the Ares project itself actually includes a commented-out line which will generate D include (.di) files, but since these include version blocks just as the source files do, there's no substantial advantage to use them. This also means that you need to compile your D apps with "-version=Posix" set for everything to work correctly.

So far, I haven't been able to get a D app to generate any output on Linux. I haven't had a chance to sort out the cause however, so it may be a link order issue, something in dmain2, etc. lightoze doesn't seem to have this problem so I suspect it may be related to link order, though I'm really hoping it isn't. If anyone figured this out before I do, please post here

By the way, the scripts and such mentioned above are checked into SVN but aren't in the latest Ares release, so you'll have to download them via a SVN client. Also, if you want to re-synch with SVN later you'll need to do this (from the top of the Ares SVN tree):

> svn revert -R *
> svn update

Then re-run the script above, re-build, etc.

[JJR]

So I guess the linux version still isn't working properly? I still get lots of errors. I also noted that there are std.c.* files that shouldn't be compiled into libphobos.a (see Walter's phobos to see what I mean).

I tried changing that and it didn't fix any of the problems. This is becoming a really difficult problem to fix for Ares on linux.

Any progress with anybody else?

I also note that the included scripts just seem to add a unittest {} to the end of all the D files for some reason. Was this the workaround?

One other thing: ares is currently compiled with -release -O -inline flags... some potentially hazardous flags: aren't -inline and -O buggy?

-JJR

[JJR]

Before I forget, there's a couple problems with the current build:

- intrinsic.d imports config.d which doesn't exist. I had to comment that line out.

- std/c/posix/ucontext.d imports tries to import std.c.signal. It should be std.c.posix.signal.

The library builds once these are fixed (but naturally still isn't linking).

-JJR

[sean]

Oops, thanks. The files are now fixed.

As for linking... that should be possible using my instructions. The latest zipfile release contains a linkable library created with this method.