[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 =
> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]