www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Question: Library linking and usage

reply "Yannick Welsch" <yannick.welsch gmx.net> writes:
This is an easy question (as I saw some people around here creating library
files but never saw how using them).

Suppose I have two files:
apple.d  and  banana.d
I compile apple.d and insert the apple.obj into a library (called apple.lib
here)
Now I want to ship my "apple" code (but don't want to ship the source).
If anyone wants to use my apple.lib now how should he access the functions
in apple.lib? (syntax?)
I tried by just using the functions from the library and linking the library
in but that didn't seem to do the deal.

How do I have to declare the functions/classes in apple.d so they can be
accessible in apple.lib later on(public?)?

Thanks,

Yannick Welsch
Dec 08 2004
parent reply John Reimer <brk_6502 yahoo.com> writes:
Yannick Welsch wrote:

 This is an easy question (as I saw some people around here creating library
 files but never saw how using them).
 
 Suppose I have two files:
 apple.d  and  banana.d
 I compile apple.d and insert the apple.obj into a library (called apple.lib
 here)
 Now I want to ship my "apple" code (but don't want to ship the source).
 If anyone wants to use my apple.lib now how should he access the functions
 in apple.lib? (syntax?)
 I tried by just using the functions from the library and linking the library
 in but that didn't seem to do the deal.
 
 How do I have to declare the functions/classes in apple.d so they can be
 accessible in apple.lib later on(public?)?
 
 Thanks,
 
 Yannick Welsch
 
 


Remember that the original module name must be referenced to access 
those funtions in order for the compiler to know how to lookup the names.

So typically you must first declare an "interface" module with the 
/same/ name as the module that is in the library:

// File: a.d

module a;

int functionA();
int funcitonB();

class A {
int methodA();
int methodB();
}

Import that name in, but don't compile that file.  Link with your 
original lib instead.  You should now be able to make calls to all a's 
methods and functions.

What you are probably trying to do is declare the external 
functions/classes inside your program module.  It won't work because it 
lacks a fully qualified name that directs the compiler to the right spot.

I hope that helps.

- John
Dec 08 2004
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:


 Now I want to ship my "apple" code (but don't want to ship the source).
 If anyone wants to use my apple.lib now how should he access the 
 functions
 in apple.lib? (syntax?)

 How do I have to declare the functions/classes in apple.d so they can be
 accessible in apple.lib later on(public?)?


 Remember that the original module name must be referenced to access 
 those funtions in order for the compiler to know how to lookup the names.
 
 So typically you must first declare an "interface" module with the 
 /same/ name as the module that is in the library:


That sounds a whole lot like a header file to me ?
So, one must maintain a "stripped" file for each ?
And then keep those in sync, when it is updated...

The libraries in D that I have seen so far has been
a) open source b) without "make install", so I was
also wondering how to accomplish the same thing...

Was comparing to C (easy, ship the header file and lib)
and with Java (easy, dynamic linkage and "javap" tool)
D seems to be somewhere inbetween them, just as usual ?

I guess the moral is that we should all do Open Source :-)

--anders
Dec 08 2004
parent reply John Reimer <brk_6502 yahoo.com> writes:
Anders F Björklund wrote:


 
 That sounds a whole lot like a header file to me ?
 So, one must maintain a "stripped" file for each ?
 And then keep those in sync, when it is updated...


Yeah, I guess it does.  A header file is pretty much what it is, 
although I find d import modules much easier on the eyes than C headers. 
  And yes, I guess you would have to keep the file in sync if you added 
functions or methods that you wanted to be public to the package.  With 
the proper build tool, though, keeping things in sync would not be much 
of an issue.  It would just be a matter of the make process updating the 
stripped file after every make.


 The libraries in D that I have seen so far has been
 a) open source b) without "make install", so I was
 also wondering how to accomplish the same thing...


Yep, the open source way has been the most popular method of 
distribution up til this point.  The "interface" method is much less 
talked about for some reason, although the steps have been in place 
almost since the compilers inception (phobos uses this method in one or 
two places).  A tutorial really needs to be made to advertise the 
possibility of an "interface" module for those that find open-sourcing 
their code undesirable.  We also need a standard build tool that works 
these wonders automatically, especially since gdc is here and 
crossplatform coding is now a real possibility.


 Was comparing to C (easy, ship the header file and lib)
 and with Java (easy, dynamic linkage and "javap" tool)
 D seems to be somewhere inbetween them, just as usual ?


It's only in between because no ones agressively promoted or developed 
tools that do the same thing for D (which isn't that hard to do).  Once 
again, I believe the we're nearing the time when such tools need to 
surface to make D development go more smoothly and be more attractive to 
people.  We also need a well-designed GUI and an IDE, too.  :-)  It 
seems work is already in progress in these areas, though.


 I guess the moral is that we should all do Open Source :-)
 
 --anders


Opensource is what started the ball rolling.  :-)

Later,

John
Dec 08 2004
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:


 Was comparing to C (easy, ship the header file and lib)
 and with Java (easy, dynamic linkage and "javap" tool)
 D seems to be somewhere inbetween them, just as usual ?


 
 It's only in between because no ones agressively promoted or developed 
 tools that do the same thing for D (which isn't that hard to do).


Not only that, but D is also designed to be in-between... ?

So it's not really all that surprising, just that it has
the same issue as C++ does with striking a balance between
the two "extremes", also when it comes to compiling/linking.
(and I find it to be a very nice complement to the other two)

--anders
Dec 08 2004
parent John Reimer <brk_6502 yahoo.com> writes:
Anders F Björklund wrote:

 John Reimer wrote:
 

 Was comparing to C (easy, ship the header file and lib)
 and with Java (easy, dynamic linkage and "javap" tool)
 D seems to be somewhere inbetween them, just as usual ?



 It's only in between because no ones agressively promoted or developed 
 tools that do the same thing for D (which isn't that hard to do).


 
 
 Not only that, but D is also designed to be in-between... ?
 
 So it's not really all that surprising, just that it has
 the same issue as C++ does with striking a balance between
 the two "extremes", also when it comes to compiling/linking.
 (and I find it to be a very nice complement to the other two)
 
 --anders



Ah, yes, I see.  Good point.
Dec 08 2004
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:


 I believe the we're nearing the time when such tools need to 
 surface to make D development go more smoothly and be more attractive to 
 people.  We also need a well-designed GUI and an IDE, too.  :-)  It 
 seems work is already in progress in these areas, though.


Another thing that is needed is a documentation generator,
but Doxygen kinda works and Ant is working on a new D tool.
Otherwise one ends up with out-of-date documentation like
http://www.digitalmars.com/d/phobos.html (sorry, Walter)

Javadoc sets an example for such API documentation, IMHO.
http://java.sun.com/j2se/javadoc/ (but Doxygen is not bad)


 I guess the moral is that we should all do Open Source :-)


 
 Opensource is what started the ball rolling.  :-)


At least for me, since none of the Digital Mars compilers
works on the platforms that I am using (Mac OS X, Linux PPC)

--anders
Dec 08 2004
next sibling parent Tyro <Tyro_member pathlink.com> writes:
In article <cp75n8$28ps$2 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

John Reimer wrote:


 I believe the we're nearing the time when such tools need to 
 surface to make D development go more smoothly and be more attractive to 
 people.  We also need a well-designed GUI and an IDE, too.  :-)  It 
 seems work is already in progress in these areas, though.


Another thing that is needed is a documentation generator,
but Doxygen kinda works and Ant is working on a new D tool.
Otherwise one ends up with out-of-date documentation like
http://www.digitalmars.com/d/phobos.html (sorry, Walter)


Ant has taken on that project and has provided preview here:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/13302


Javadoc sets an example for such API documentation, IMHO.
http://java.sun.com/j2se/javadoc/ (but Doxygen is not bad)


 I guess the moral is that we should all do Open Source :-)


 
 Opensource is what started the ball rolling.  :-)


At least for me, since none of the Digital Mars compilers
works on the platforms that I am using (Mac OS X, Linux PPC)

--anders
Dec 08 2004
prev sibling parent John Reimer <brk_6502 yahoo.com> writes:
Anders F Björklund wrote:

 John Reimer wrote:
 

 I believe the we're nearing the time when such tools need to surface 
 to make D development go more smoothly and be more attractive to 
 people.  We also need a well-designed GUI and an IDE, too.  :-)  It 
 seems work is already in progress in these areas, though.


 
 
 Another thing that is needed is a documentation generator,
 but Doxygen kinda works and Ant is working on a new D tool.
 Otherwise one ends up with out-of-date documentation like
 http://www.digitalmars.com/d/phobos.html (sorry, Walter)
 
 Javadoc sets an example for such API documentation, IMHO.
 http://java.sun.com/j2se/javadoc/ (but Doxygen is not bad)


That and proper debugging on linux.  Hunting down errors on linux, 
whether threading or phobos related, can be a real pain.  As the 
compiler matures, perhaps the need will not be as great.



 I guess the moral is that we should all do Open Source :-)



 Opensource is what started the ball rolling.  :-)


 
 
 At least for me, since none of the Digital Mars compilers
 works on the platforms that I am using (Mac OS X, Linux PPC)
 
 --anders



Ouch! Well, I love macs, but don't have one.  I hope gdc gets working 
smoothly on the powerpc soon.

Later,

John
Dec 08 2004
prev sibling next sibling parent reply "Yannick Welsch" <yannick.welsch gmx.net> writes:
Exactly the answer I needed ;)

 So typically you must first declare an "interface" module with the
 /same/ name as the module that is in the library:


Can't this be done automatically?
In Java there is no need to define such an "interface" module.
It would be nice if the compiler could give out such an "interface" module
in addition to the object file (As it has the capability to).

Many thanks,

Yannick Welsch


"John Reimer" <brk_6502 yahoo.com> wrote in message
news:cp6u9v$1ski$1 digitaldaemon.com...

 Yannick Welsch wrote:

 This is an easy question (as I saw some people around here creating




library

 files but never saw how using them).

 Suppose I have two files:
 apple.d  and  banana.d
 I compile apple.d and insert the apple.obj into a library (called




apple.lib

 here)
 Now I want to ship my "apple" code (but don't want to ship the source).
 If anyone wants to use my apple.lib now how should he access the




functions

 in apple.lib? (syntax?)
 I tried by just using the functions from the library and linking the




library

 in but that didn't seem to do the deal.

 How do I have to declare the functions/classes in apple.d so they can be
 accessible in apple.lib later on(public?)?

 Thanks,

 Yannick Welsch


 Remember that the original module name must be referenced to access
 those funtions in order for the compiler to know how to lookup the names.

 So typically you must first declare an "interface" module with the
 /same/ name as the module that is in the library:

 // File: a.d

 module a;

 int functionA();
 int funcitonB();

 class A {
 int methodA();
 int methodB();
 }

 Import that name in, but don't compile that file.  Link with your
 original lib instead.  You should now be able to make calls to all a's
 methods and functions.

 What you are probably trying to do is declare the external
 functions/classes inside your program module.  It won't work because it
 lacks a fully qualified name that directs the compiler to the right spot.

 I hope that helps.

 - John
Dec 08 2004
parent reply John Reimer <brk_6502 yahoo.com> writes:
Yannick Welsch wrote:

 Exactly the answer I needed ;)
 

So typically you must first declare an "interface" module with the
/same/ name as the module that is in the library:


 
 Can't this be done automatically?
 In Java there is no need to define such an "interface" module.
 It would be nice if the compiler could give out such an "interface" module
 in addition to the object file (As it has the capability to).
 
 Many thanks,
 
 Yannick Welsch
 
 


This has been brought up before.  Automation of the task is as simple as 
creating a tool that does the stripping for you.  In fact I believe the 
library creation tool "digc" by Burton Radons has been able to do this 
for couple of years.  While it may be nice to have such a feature as 
part of the compiler, it's been argued that such a task is not strictly 
within the problem domain of the compiler.

I agree in one respect: such a tool should at least be made part of the 
compiler package.

Later,

John
Dec 08 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:


 This has been brought up before.  Automation of the task is as simple as 
 creating a tool that does the stripping for you.  In fact I believe the 
 library creation tool "digc" by Burton Radons has been able to do this 
 for couple of years.  While it may be nice to have such a feature as 
 part of the compiler, it's been argued that such a task is not strictly 
 within the problem domain of the compiler.


A demangler would be nice too, i.e. something that could convert
"_D5hello5helloFAaZv" into "module hello; void hello(char[] _a);"

Wonder if something like that has already been done for debugging ?

--anders
Dec 08 2004
next sibling parent John Reimer <brk_6502 yahoo.com> writes:
Anders F Björklund wrote:

 John Reimer wrote:
 

 This has been brought up before.  Automation of the task is as simple 
 as creating a tool that does the stripping for you.  In fact I believe 
 the library creation tool "digc" by Burton Radons has been able to do 
 this for couple of years.  While it may be nice to have such a feature 
 as part of the compiler, it's been argued that such a task is not 
 strictly within the problem domain of the compiler.


 
 
 A demangler would be nice too, i.e. something that could convert
 "_D5hello5helloFAaZv" into "module hello; void hello(char[] _a);"
 
 Wonder if something like that has already been done for debugging ?
 
 --anders


Not that I'm aware of.  I agree that such a feature would be useful.
Dec 08 2004
prev sibling parent Daniel Keep <daniel.keep dummy.gmail.com> writes:
Thanks for the idea :P

I've just been playing around with D name mangling, and I reckon it 
would be possible to build a library --> d interface generator.

The catch?  So far, I only know how to get it working under Linux :P

Anyway, I'll give it a shot over the next few days, and see what I can 
come up with.  Should be interesting.

	-- Daniel

Anders F Björklund wrote:

 John Reimer wrote:
 

 This has been brought up before.  Automation of the task is as simple 
 as creating a tool that does the stripping for you.  In fact I believe 
 the library creation tool "digc" by Burton Radons has been able to do 
 this for couple of years.  While it may be nice to have such a feature 
 as part of the compiler, it's been argued that such a task is not 
 strictly within the problem domain of the compiler.


 
 
 A demangler would be nice too, i.e. something that could convert
 "_D5hello5helloFAaZv" into "module hello; void hello(char[] _a);"
 
 Wonder if something like that has already been done for debugging ?
 
 --anders
Dec 08 2004
prev sibling parent Yigal Chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu Wrote:

 There are a few principles at work here that I consider universal, plus 
 some others that I consider a matter of preference. One principle that I 
 consider universal is that a language should minimize the number of 
 syntactic constructs that are semantically and/or pragmatically 
 meaningless. Another that I also consider universal is that the more 
 frequently-used constructs should be given syntactic priority over the 
 less-used constructs, particularly when the latter are also at risk of 
 breaking the first principle.
 
 C's handling of function names royally breaks both of these principles. 
 It makes
 
 func;
 
 a valid syntactic construct with inoperant semantics and consequently 
 useless pragmatics. Moreover,
 
 a = func;
 gunc(func);
 
 both have valid syntax and semantics, but the pragmatics are the 
 infrequently-used manipulations of function addresses in higher-order 
 programming, something C is not quite adept at to start with. (So that 
 makes the state of affairs all the more ironic.)
 
 C++ builds on that irony by making
 
 obj.func;
 b = obj.func;
 gunc(obj.func);
 
 still syntactically valid but one order of magnitude less useful because 
 they traffic in references to member functions, a contraption that is 
 defined sufficiently bad and inefficient to be useless in practice, and 
 also of a type with a syntax I'd be glad to remove from my memory. (How 
 many here _do_ know that type's syntax and have the scars to prove it?)
 
 So thinking of function call syntax has quite a few deep underpinnings. 
 We shouldn't confuse habit acquired from C and C++ with some fundamental 
 truth or just a matter of preference that can't be decided on an 
 objective basis.
 
 One issue with today's function call syntax in D is that people can 
 write code that is of dubious expressiveness:
 
 writeln = 3;
 
 Properties would solve this problem by confining assignment syntax to 
 themselves only.
 
 
 Andrei


I didn't mean to suggest we need to have pointer-to-member-function as in c++.
I totally agree about all the problems you point out in C/C++ and I don't want
to
import all of those problems to D. 
you talk about how C is not quite adept at infrequently-used manipulations of 
function addresses in higher-order programming but this is I think not relevant
to D
since D has better facilities (delegates) and the use of those will be more
frequent 
since D tries to incorporate more FP (pure functions, etc)
also, there is the problem you stated above with allowing "writeln = 3;"

what would you think about the following scheme:

1. requiring parens to represent function invocation
2. using explicit property syntax similar to my previous post
3. the function name would be consistent with other identifiers and functions
could be
    treated just like any other object.
    -  func.something; // refers to a property of the function itself.
    -  func();  // calling func
    -  func.something(); // calling method of func. 
4.  function names represent delegates instead of function pointers, 
     just like D arrays are "fat" structs and not pointers. 
5. plain old C function pointers can be implicitly cast to delegates. 
6. func.ptr will return the C style function pointer (just like with arrays).
Sep 26 2008