digitalmars.D - Library linking
- Jeremy (21/21) Feb 27 2006 Hi all!
- Jarrett Billingsley (12/17) Feb 27 2006 Well, it's not _quite_ what you want, but it's better than nothing:
- Jeremy (27/45) Feb 27 2006 I really hope "auto-loading" gets into the standard. It seems like there...
- Jarrett Billingsley (7/26) Feb 27 2006 That would be great. Although, why not just keep import?
- Jarrett Billingsley (12/13) Feb 27 2006 There is a problem with this.
- Jeremy (17/30) Feb 27 2006 Hrm.. so how are those libraries referenced? I assume these are the case...
- Brad Anderson (3/15) Feb 27 2006 Have you seen http://trac.dsource.org/projects/ddl ??
- Jeremy (7/22) Feb 27 2006 Interesting... is this the answer to all my questions? :-D Many of the p...
- Kyle Furlong (2/26) Feb 27 2006 DDL is a *relatively* new project, so it is still in beta, plus I'm sure...
- Walter Bright (5/21) Mar 01 2006 The problem with referencing dll's is that you could only reference
- Jeremy (15/37) Mar 01 2006 OK, fair enough. But what you can reference, should be this easy. It see...
Hi all! I've been lurking this forum for a little while -- and I'm really interested in D. I love C/C++, but I want something a little more modern -- but I don't want for everything... Anyway, the thing that usually gets me with new languages etc. is linking in all the extra tools I want to use (DLL's, .a's, .lib's etc.) Can there be something as simple as 'importlib (<type>) "<filename>"' in the code? Say: importlib (dll) "alleg40.dll"; importlib (a) "libusb.a"; I know the "extern (C) <function>" already exists.. but you have to do this for every function in the library... I wish I could just have an 'importlib' that would grab all the function names and parameters (and a nice IDE could pick it up for code completion) :) Maybe this is a pipe dream, or maybe it already is implemented and I haven't found it yet... but I loved how in VB you could just 'check a box' and magically you could use the library in your code, and it would link on compile. (Maybe this would be a job of a nice IDE?) Anyway, I'm watching the D project very closely! Keep up the good work! - Jeremy
Feb 27 2006
"Jeremy" <Jeremy_member pathlink.com> wrote in message news:du03ir$2u1d$1 digitaldaemon.com...Can there be something as simple as 'importlib (<type>) "<filename>"' in the code? Say: importlib (dll) "alleg40.dll"; importlib (a) "libusb.a";Well, it's not _quite_ what you want, but it's better than nothing: pragma(lib, "libusb.a"); This will tell the linker to link in the library, but you'll still have to define all the function signatures yourself. And with DLLs, you can use implib to generate a .def file which can be passed on the command line to tell the linker where to find the functions, but again, you have to define all the function signatures. Some people have been working on "auto-loading" symbols from static / dynamic libraries, but it's not part of the language yet. I think a D object / library standard that had auto-loading of symbols would be great.
Feb 27 2006
In article <du03ss$2ugm$1 digitaldaemon.com>, Jarrett Billingsley says..."Jeremy" <Jeremy_member pathlink.com> wrote in message news:du03ir$2u1d$1 digitaldaemon.com...I really hope "auto-loading" gets into the standard. It seems like there is alot of "fluff" when including/importing libraries... there are many steps/programs to do essentially one thing -- reference external (pre-compiled) code. We have 'implib', 'linkdef', 'pragma', 'extern' (for *every* function you want to use),'import'... and you still have to add the library filenames to the command line during compilation (unless you use pragma as Jarrett pointed out...). Merge all that functionality into one keyword -- for example, you shouldn't have to tell the compiler anything more than 'I want to use this external source'. One line would tell the compiler you want to link/import a file, and that all symbols are to be loaded from that library that are referenced in the program. You might want to deprecate the current 'import', 'extern' and 'pragma' (pragma probably has other uses?) for an all-in-one 'reference' keyword that would work something like: reference "alleg40.dll" reference "gameclasses.d" reference "libusb.a" reference "phobos.lib" The library type could be extracted by the file extension. That just looks awesome :) You have to agree... :) It must be possible -- and I think that would put D far ahead of the competition... imagine getting a new library -- want to install it? Copy hotstuff.xxx to the directory and say 'reference "hotstuff.xxx"' in your Game.d and that's it. Want to compile it? Just say 'dmd Game.d', that's it (assuming the libraries are in the same directory... -I otherwise etc etc.) -- If it isn't a recognizable library, throw a compiler error... JeremyCan there be something as simple as 'importlib (<type>) "<filename>"' in the code? Say: importlib (dll) "alleg40.dll"; importlib (a) "libusb.a";Well, it's not _quite_ what you want, but it's better than nothing: pragma(lib, "libusb.a"); This will tell the linker to link in the library, but you'll still have to define all the function signatures yourself. And with DLLs, you can use implib to generate a .def file which can be passed on the command line to tell the linker where to find the functions, but again, you have to define all the function signatures. Some people have been working on "auto-loading" symbols from static / dynamic libraries, but it's not part of the language yet. I think a D object / library standard that had auto-loading of symbols would be great.
Feb 27 2006
"Jeremy" <Jeremy_member pathlink.com> wrote in message news:du0gvn$98o$1 digitaldaemon.com...Merge all that functionality into one keyword -- for example, you shouldn't have to tell the compiler anything more than 'I want to use this external source'. One line would tell the compiler you want to link/import a file, and that all symbols are to be loaded from that library that are referenced in the program. You might want to deprecate the current 'import', 'extern' and 'pragma' (pragma probably has other uses?) for an all-in-one 'reference' keyword that would work something like: reference "alleg40.dll" reference "gameclasses.d" reference "libusb.a" reference "phobos.lib" The library type could be extracted by the file extension. That just looks awesome :) You have to agree... :)That would be great. Although, why not just keep import? import std.string; import "alleg40.dll"; And yes, pragma does have other uses (it's a general-purpose compiler directive statement).
Feb 27 2006
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message news:du0hji$a2a$1 digitaldaemon.com...import "alleg40.dll";There is a problem with this. Unless the library (static or dynamic) uses some kind of known name mangling, D won't be able to deduce the function signatures. For example, I know a lot of C-compatible libraries use C name mangling, which is just name 8 Or something, where 8 is the number of bytes passed into the function. No indication of return type, param types, etc. It could only really be done with D libraries, and by then, you might as well create your own D library format. Which would still be cool.
Feb 27 2006
In article <du0hnt$a5d$1 digitaldaemon.com>, Jarrett Billingsley says..."Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message news:du0hji$a2a$1 digitaldaemon.com...I was worried somebody would say that :~(import "alleg40.dll";There is a problem with this.Unless the library (static or dynamic) uses some kind of known name mangling, D won't be able to deduce the function signatures. For example, I know a lot of C-compatible libraries use C name mangling, which is just name 8 Or something, where 8 is the number of bytes passed into the function. No indication of return type, param types, etc.Hrm.. so how are those libraries referenced? I assume these are the cases where the library comes with a .h file that has the correct symbol names? Hrm.. maybe that 'reference' keyword would work something like: reference <library file> [, symbol defintion file] if the second argument is missing ('symbol definition file') -- the compiler will try to automatically extract symbol information and compile -- complaining if there are undefined references (maybe the compiler can pick up symbol names by these undefined references like "linkdef" does?) if the second argument exists, then it will use that to grab more information about the library (like a .h file would for C libraries -- isn't this what current .def's do?) I would like to help program this functionality if it would become part of the standard :) I don't know where to begin, but I'm pretty good with C/C++ :-DIt could only really be done with D libraries, and by then, you might as well create your own D library format. Which would still be cool.Yes yes :) Jeremy
Feb 27 2006
Jeremy wrote:I would like to help program this functionality if it would become part of the standard :) I don't know where to begin, but I'm pretty good with C/C++ :-DHave you seen http://trac.dsource.org/projects/ddl ?? BAIt could only really be done with D libraries, and by then, you might as well create your own D library format. Which would still be cool.Yes yes :) Jeremy
Feb 27 2006
In article <du0lff$dh0$1 digitaldaemon.com>, Brad Anderson says...Jeremy wrote:Interesting... is this the answer to all my questions? :-D Many of the pages explaining more about DDL are not complete :( But if I assume correctly... this tool will take in almost any library .DLL, .o, .a, .lib and make a .DDL out of it? I'll have to look more into this when its not 12:30am :) Why isn't slick stuff like this packaged with the compiler? JeremyI would like to help program this functionality if it would become part of the standard :) I don't know where to begin, but I'm pretty good with C/C++ :-DHave you seen http://trac.dsource.org/projects/ddl ?? BAIt could only really be done with D libraries, and by then, you might as well create your own D library format. Which would still be cool.Yes yes :) Jeremy
Feb 27 2006
Jeremy wrote:In article <du0lff$dh0$1 digitaldaemon.com>, Brad Anderson says...DDL is a *relatively* new project, so it is still in beta, plus I'm sure Walter has not had time to grok what Eric is doing with it.Jeremy wrote:Interesting... is this the answer to all my questions? :-D Many of the pages explaining more about DDL are not complete :( But if I assume correctly... this tool will take in almost any library .DLL, .o, .a, .lib and make a .DDL out of it? I'll have to look more into this when its not 12:30am :) Why isn't slick stuff like this packaged with the compiler? JeremyI would like to help program this functionality if it would become part of the standard :) I don't know where to begin, but I'm pretty good with C/C++ :-DHave you seen http://trac.dsource.org/projects/ddl ?? BAIt could only really be done with D libraries, and by then, you might as well create your own D library format. Which would still be cool.Yes yes :) Jeremy
Feb 27 2006
"Jeremy" <Jeremy_member pathlink.com> wrote in message news:du0gvn$98o$1 digitaldaemon.com...reference "alleg40.dll" reference "gameclasses.d" reference "libusb.a" reference "phobos.lib" The library type could be extracted by the file extension. That just looks awesome :) You have to agree... :) It must be possible -- and I think that would put D far ahead of the competition... imagine getting a new library -- want to install it? Copy hotstuff.xxx to the directory and say 'reference "hotstuff.xxx"' in your Game.d and that's it. Want to compile it? Just say 'dmd Game.d', that's it (assuming the libraries are in the same directory... -I otherwise etc etc.) -- If it isn't a recognizable library, throw a compiler error...The problem with referencing dll's is that you could only reference functions that accepted and returned basic types. No classes, no enums, no structs, no typedefs.
Mar 01 2006
In article <du5hro$2c10$1 digitaldaemon.com>, Walter Bright says..."Jeremy" <Jeremy_member pathlink.com> wrote in message news:du0gvn$98o$1 digitaldaemon.com...OK, fair enough. But what you can reference, should be this easy. It seems so intuitive to just tell the compiler in one place what file you want to reference. To get around strange library hurdles, you should work with the DDL guys. Anyway, what Kyle Furlong said in the Bugs forum -- the D language is some really good stuff... but the framework is lacking (libraries, IDEs, tools etc.) -- If it was this easy to "plug" in external sources, more people would plug into it :) On a somewhat related note -- if I wanted to reference SAPI.DLL to make a speech-enabled program using Microsoft's SAPI interface, which uses some classes TGrammar and whatever -- would I simply just not be able to do this (aside from writing an entire C wrapper library)? Could DDL potentially save me much trouble? Jeremyreference "alleg40.dll" reference "gameclasses.d" reference "libusb.a" reference "phobos.lib" The library type could be extracted by the file extension. That just looks awesome :) You have to agree... :) It must be possible -- and I think that would put D far ahead of the competition... imagine getting a new library -- want to install it? Copy hotstuff.xxx to the directory and say 'reference "hotstuff.xxx"' in your Game.d and that's it. Want to compile it? Just say 'dmd Game.d', that's it (assuming the libraries are in the same directory... -I otherwise etc etc.) -- If it isn't a recognizable library, throw a compiler error...The problem with referencing dll's is that you could only reference functions that accepted and returned basic types. No classes, no enums, no structs, no typedefs.
Mar 01 2006