> 1. Making shared libraries under Linux work would be a big improvement.
I think you meant "Making shared libraries, written in D, under Linux work would be a big improvement.", because everything else works fine (i tested it) using core.sys.posix.dlfn; Since druntime needs some serious initialization, core.sys.windows.dll was invented to hide away all this and, if I'm not mistaken, this is precisely what it means to "support DLLs". since .so files don't have any auto-called functions, like DllMain, some additional shenanigans are required to get it to work as in Windows. There will still be helper functions that would be put inside some "main" function in .so functions, that should be called explicitly when loaded (probably inside a standard library loader). DllMain also has thread/process attach/detach routine callbacks, which are, AFAIK, are not necessary to simulate in .so files (otherwise, it'll go inside that pseudo-main function). Regarding the above information, all I have to do to make "shared libraries work under linux" is to make linux analogs for the dll helper functions, define the pseudo-main function requirement in D docs and make a specialization of LoadLibrary routine in druntime to call that function. I have a question regarding the general approach to shared libraries in D: Should we really use obsolete C library formats and jump through lots of hoops to work around the limitations? AFAIK, currently "DLL support" is purely an optional druntime feature, that allows one to quickly initialize druntime from DllMain by using the functions for attaching/detaching a thread/process. I understand, the GC, some handlers (like exception handler) as well as any other things i don't know about should be properly initialized. The problem is, that .so files in ELF format don't have anything similar. In order to make the two consistent some common logic should be developed on how does D treat On Mon, Nov 7, 2011 at 1:51 PM, Walter Bright <[email protected]> wrote: > On 11/7/2011 1:19 AM, Gor Gyolchanyan wrote: >> >> I'm not quite familiar with DMD's internals, so the best answer would >> be "whatever is more important to do". > > I take it you want to work on DMD itself, then! > > 1. Making shared libraries under Linux work would be a big improvement. > > 2. Another would be to investigate the Dwarf symbolic debug outfit and make > dmd's output work well in gdb. > > 3. Run the dmd test suite under Linux with gcc's coverage analyzer turned > on. Add test cases to cover dmd source code that is not tested. > > 4. There are many static analyzers on the market. Try compiling dmd with one > or more of them, and propose fixes. > > 5. Go through the Bugzilla unresolved issues, pick what interests you, and > propose patches to fix them. > > 6. Investigate popular benchmarks (such as the "shootout"). Compare the > native code generated by dmd with that of C or C++, and identify inefficient > code sequences. > > 7. Install NetBSD or OpenBSD, and port dmd to them. >
