Re: Always the problem between gplc/gcc

[Timo Karjalainen]

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