[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Always the problem between gplc/gcc
From: |
Timo Karjalainen |
Subject: |
Re: Always the problem between gplc/gcc |
Date: |
Fri, 30 Aug 2002 14:26:37 +0300 (EEST) |
Sorry it's taken me this long to reply. I'm amazed nobody with more Unix
expertise has commented on this thing yet...
On Mon, 26 Aug 2002, bruno patin wrote:
> Timo Karjalainen wrote:
>
> >What kind of code do you expect to be in a header file?
> >
>
> in the gprolog.h file :
>
> extern ObjChain *obj_chain_stop;
> ObjChain obj_chain_start =
> {OBJ_CHAIN_MAGIC_1,OBJ_CHAIN_MAGIC_2,&obj_chain_stop,OBJ_INIT};
> static ObjChain *obj_chain_stop = &obj_chain_start;
This is truly evil stuff to put in a header. First off, it declares
obj_chain_stop as having both external and static linkage. AFAIK that is
not allowed by the C standard, so that code shouldn't even compile.
Second, it is defining and initializing variables in a header file.
That is considered a Bad Thing. Static variables are mostly a style
issue here, but this code also defines non-static global variables.
That header is defining a non-static global variable obj_chain_start that
is initialized to contain the address of a static variable. Given that you
include that header in two compilation units (read: modulea), which static
obj_chain_stop does the single global obj_chain_start contain the address
of? Be it neither, or either one; definitely something doesn't work...
> What I ask is to know if there is a mean to pack all these declarations
> in one file in order not to have these difficult dependancies.
I can't tell, it depends on the GNU Prolog architecture, which I am not
familiar with. As a general principle, I suppose it can be easy, unless
the architecture is hosed. :)
> it's really
> difficult to create an independant module with this constrain of
> positionning obj_begin before the first user module containing a
> reference to gprolog calls.
Well, linking is like that, you have to put the startup code first.
Reflecting on the obj_chain_* stuff you quoted, it seems like there is
some wacky symbol-address scheme. What else are those magic numbers good
for except scanning the binary and forking all user code between the
beginning and the end.
> >Erm, are you saying that to link a program, you have to cook up a library
> >from GNU Prolog objects and some of your own modules, then link the rest
> >of your program against that library? Sounds strange.
>
> yes, the reason is that I have a multilayered application (each layer a
> library) and don't want to have the upper level know the lower level as
> I can replace the prolog engine by another one.
That is good design.
> Usually I would have
> done it with a static archive and that's all but for gnu prolog I have
> this little problem that whatever the reason it doesn't work.
Hmm, I can't really help very much here. Personally, I only use Prolog for
the main program, and have never combined Prolog with C or anything else.
If it doesn't work, you can't do it :) Unless somebody hacks the system
into a different style that enables such things.
> To export with gcc is really easy. gcc -shared, that's all.
Oh. I've never done those things with GCC.
> On windows, ermmm, try to do it.
Isn't it just about declaring the external symbols with "extern"?
> I prefer to let libtool make the work.
And expose all your library-internal symbols as well in the process?
> I read the man pages too fast. I don't really know after reading ld and
> gcc pages if there is a difference. Libraries (static one) are only a
> repository of normal objects files so my interpretation...
Static libraries are not quite the same as throwing objects in by the bag
instead of one-by-one. There's the matter of only including sections from
which at least one symbol is referenced, possibly other effects as well.
> I'm not really a specialist in copiler an d linker but the multi pass
> method do have problems on our case because we have to place the objects
> and libraries in exactly the good order.
The multiple passes do not necessarily change the order. I know at least
some linkers maintain the order, _but_ they still do not include sections
from libraries if there are no references to them. Think of it as all
sections being #ifdef'ed and all references automatically having a #define
of the wrapper macro.
--
Timo Karjalainen "I don't have a life.
I have a program."
- Star Trek: Voyager