Comment #0 by boucher.travis — 2009-11-19T18:41:32Z
Created attachment 503
FreeBSD quick fix (should compile, may not work properly)
This is a preliminary patch, mostly trivial, and not fully tested yet (but it
compiles, so that is 1 step in the right direction).
Some notes:
- posix.mak implies posix which also implies unix line termination. This patch
doesn't have it corrected. A simple perl -pi -e 's/\r\n/\n/g' filename will
convert from winderz to unix line termination. Note a biggy, just something I
trip over sometimes when making patches.
- dmd2 changed freebsd to FreeBSD for version statements. Maybe version
statements should case insensitive?
- For the most part I just copied the linux definitions of stuff that was
missing. This may or may not work, I don't have everything ready to run a good
test yet.
- make is only gnu make on linux machines. I'd like to make the whole build
structure a little more standard make-wise. The dmd source is pretty good for
this. I am not sure what druntime needs that is so gnu specific.
Future direction:
Cleanup the whole runtime and group Posix vs. Linux/FreeBSD definitions
properly. Stuff that is defined in the Posix spec should be in a version(
Posix ) rather then a version( linux ) with duplicates for version( FreeBSD ),
version( Solaris ), version( each other os).
I'd prefer to see something like this:
version (Posix) {
struct OSStructure {
version(linux) int foo;
version(FreeBSD) long foo;
int bar;
}
}
for trivial differences between implementations rather then a completely
different block. This is even more important for things like standard posix
APIs. Another example is when one implementation uses a macro and another uses
a function.
version (FreeBSD) {
void MacroImplementation(...) { ... }
alias MacroImplementaion DImplementaion
}
version (linux) {
extern (C) void LibraryImplementation(...) { ... }
alias LibraryImplementaion DImplementation
}
(I think some of the pthread stuff is like this, but I have to read through
both source trees to find out for sure).
Comment #1 by bugzilla — 2009-11-22T03:47:29Z
I started with the fine grained versioning for OS differences, but abandoned it after it got hopelessly tangled. The problem is updating support for one OS that trashes another. All OS specific API's should be in separate modules. Then maintenance is a lot easier.
Also, please compile & test patches before submitting them. If it's inserted without testing, then it may silently fail, yet will be assumed to work some arbitrary time later.
For sure, just copying linux stuff is fraught with peril. Linux and Freebsd are substantially different, and every declaration needs to be manually and carefully checked against the Freebsd C header files. Getting things like bit masks, magic values, argument types, number of arguments, struct layouts, etc., wrong is a potential disastrous problem.
Comment #2 by sean — 2009-11-22T07:11:20Z
The OS-specic blocks in the Posix headers are there to ease maintenance. As Walter has said, the alternative would be to have separate headers for each OS, but I personally find it easier to work with them as-is. I don't want to put common stuff in a shared Posix version because it could cause problems later. Add support for another OS that doesn't define things that way and you either have to separate it all again or add finer-grained versioning, which would be a nightmare.
Comment #3 by boucher.travis — 2009-11-22T08:44:41Z
(In reply to comment #2)
> The OS-specic blocks in the Posix headers are there to ease maintenance. As
> Walter has said, the alternative would be to have separate headers for each OS,
> but I personally find it easier to work with them as-is. I don't want to put
> common stuff in a shared Posix version because it could cause problems later.
> Add support for another OS that doesn't define things that way and you either
> have to separate it all again or add finer-grained versioning, which would be a
> nightmare.
The problem I am having now is that the FreeBSD stuff isn't being maintained. I am also trying to figure out the specific interactions between dmd, druntime and phobos. This will become even more of a nightmare if more platforms becomes supported. Maybe dropping freebsd support all together in dmd is an answer, and then my focus could be on gdc and making sure phobos/tango has the support I require. (of course druntime is still required at some level).
Comment #4 by sean — 2009-11-22T11:22:00Z
OS support beyond Linux and OSX is by submission, since I don't have an install of other OSes to check. Tango is the same way though, unless something has changed recently. What issue do you have with Druntime/Phobos interaction? I'm not sure I understand.
Comment #5 by sean — 2009-11-22T11:26:29Z
Regarding your commends, eol-style should be set for all files in SVN, so if you're working from SVN all that should be handled for you. And please please don't copy definitions from one OS without checking them. If something doesn't compile now it indicates where work needs to be done to fill out the headers properly. Throwing in potentially invalid definitions just papers over the problem and is likely to produce subtly broken code.
Comment #6 by boucher.travis — 2009-11-22T13:05:49Z
(In reply to comment #4)
> OS support beyond Linux and OSX is by submission, since I don't have an install
> of other OSes to check. Tango is the same way though, unless something has
> changed recently. What issue do you have with Druntime/Phobos interaction?
> I'm not sure I understand.
No issues with druntime/phobos interaction, just trying to learn/figure out what is defined where. Most of what I am doing is to learn the internals a little more so I can use it for targets other then x86/winderz/linux. I am especially interested in embedded targets (which is why understanding what all druntime provides is important to me).
Comment #7 by boucher.travis — 2009-11-22T13:09:03Z
(In reply to comment #5)
> Regarding your commends, eol-style should be set for all files in SVN, so if
> you're working from SVN all that should be handled for you. And please please
> don't copy definitions from one OS without checking them. If something doesn't
> compile now it indicates where work needs to be done to fill out the headers
> properly. Throwing in potentially invalid definitions just papers over the
> problem and is likely to produce subtly broken code.
Understood, I'll be sure to test things properly before submitting anything else. I think one of the biggest frustrations in making D more cross platform is the inability to look at system C headers to create the proper definitions automatically. (not a fault in D's design, just an annoyance for integration)
Comment #8 by afb — 2009-11-22T13:23:49Z
(In reply to comment #7)
> I think one of the biggest frustrations in making D more cross platform
> is the inability to look at system C headers to create the proper definitions
> automatically. (not a fault in D's design, just an annoyance for integration)
GDC looks at the system C headers.
http://dgcc.svn.sourceforge.net/viewvc/dgcc/trunk/d/phobos/config/
Comment #9 by rsinfu — 2010-05-17T00:26:58Z
Created attachment 634
New patch for svn r296
This is a new patch for druntime trunk r296.
I tested the patch with the Phobos (r1513) unit tests -- it successfully passed on FreeBSD 8-STABLE (compiler patches bug 4191 and bug 4198 were required).
Comment #10 by rsinfu — 2010-08-03T22:15:29Z
Created attachment 702
Patch against svn r352
Updated the patch for svn trunk r352.
Comment #11 by rsinfu — 2010-08-03T22:44:52Z
Created attachment 703
Patch against svn r352
Oops, forgot to eliminate backtrace stuffs that FreeBSD libc does'nt have.