www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Library linking

reply Jeremy <Jeremy_member pathlink.com> writes:
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
to do the whole 'VM' C# and Java -- and I really don't like how they force OO
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
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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
parent reply Jeremy <Jeremy_member pathlink.com> writes:
In article <du03ss$2ugm$1 digitaldaemon.com>, Jarrett Billingsley says...
"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.

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... Jeremy
Feb 27 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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
parent reply Jeremy <Jeremy_member pathlink.com> writes:
In article <du0hnt$a5d$1 digitaldaemon.com>, Jarrett Billingsley says...
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:du0hji$a2a$1 digitaldaemon.com...
 import "alleg40.dll";

There is a problem with this.

I was worried somebody would say that :~(
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++ :-D
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. 

Yes yes :) Jeremy
Feb 27 2006
parent reply Brad Anderson <brad dsource.dot.org> writes:
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++ :-D
 
 
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. 

Yes yes :) Jeremy

Have you seen http://trac.dsource.org/projects/ddl ?? BA
Feb 27 2006
parent reply Jeremy <Jeremy_member pathlink.com> writes:
In article <du0lff$dh0$1 digitaldaemon.com>, Brad Anderson says...
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++ :-D
 
 
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. 

Yes yes :) Jeremy

Have you seen http://trac.dsource.org/projects/ddl ?? BA

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? Jeremy
Feb 27 2006
parent Kyle Furlong <kylefurlong gmail.com> writes:
Jeremy wrote:
 In article <du0lff$dh0$1 digitaldaemon.com>, Brad Anderson says...
 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++ :-D


 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. 

Yes yes :) Jeremy

BA

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? Jeremy

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.
Feb 27 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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
parent Jeremy <Jeremy_member pathlink.com> writes:
In article <du5hro$2c10$1 digitaldaemon.com>, Walter Bright says...
"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.

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? Jeremy
Mar 01 2006