[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Always the problem between gplc/gcc

From: bruno patin
Subject: Re: Always the problem between gplc/gcc
Date: Mon, 26 Aug 2002 20:46:32 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530

Timo Karjalainen wrote:

On Fri, 23 Aug 2002, bruno patin wrote:

In fact, the little code snippet that is in
obj_begin.c only initialise a list. I don't really understand why it
can't be done in th gprolog.h code but ... that's a fact.

What kind of code do you expect to be in a header file?

you have in obj_begin.c the code :

extern ObjChain *obj_chain_end;
ObjChain obj_chain_begin = {OBJ_CHAIN_MAGIC_1,OBJ_CHAIN_MAGIC_2,&obj_chain_end,NULL};

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;

and in the obj_end.c file :

extern ObjChain *obj_chain_begin;
ObjChain obj_chain_end = &obj_chain_begin;

the two files obj_xxx contains only the code precise (there is an ifdef on _MSC_VER but I don't think we are in this case) 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 think it's not so easy because Daniel Diaz would have done it but 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.

problem 1 :
I have to create a shared library for each prog use I make. I can't use
say one code of mine that use gnu-prolog calls and link it with the
library already created. I have to use directly the objects of  gnu
prolog and place my code correctly then recreate a new shared library.

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. 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.

For the time being, I use the solution you helped me to work... thanks
I think Daniel Diaz will be able to help me as soon as returned from holidays.

I can imagine a
perverted architecture requiring such a sandwich link, but I doubt it's
necessary. On the other hand, I don't know anything about GNU Prolog
foreign code linking. Somebody?

to create these shared libraries I rely upon automake/autoconf and their
use of libtool. But the gnu-prolog objects were not created with this
utility and so can't be put into a shared library by libtool.

I suppose the source for these objects is available, GNU Prolog being,
um, GNU software. :) So you should be able to make a libtools-version of

you are right I only don't have the energy to do it for the time being (someone ??).

On unix you can bypass the problem
as gcc use directly the objects (a "little" modification in the libtool
script shell) but to create dll on windows you have to export symbols

Don't you also have to export symbols from a Unix library? Exporting
really only means "listing as available from the outside". If you didn't
export your function entry points from a library, you'd end up with a
library that has lots of internal stuff but nothing you can link any
external program to.

To export with gcc is really easy. gcc -shared, that's all. On windows, ermmm, try to do it. I prefer to let libtool make the work.

first command : gcc ... obj_begin.o my_module.o "other modules"
second : gcc ... obj_begin.o libmy_module.a "other modules"

You could try putting the library .a after the other modules.
Libraries are usually mentioned last in a link list.

I am obliged to think that libraries are not treated by gcc on the same
status that objects.

Well no, libraries aren't the same as object files. Again, I'm not an
expert in GCC or Unix, but I would suppose they are treated differently.
If the same stuff gets included in the executable program, then it must
be some code section thing, like the startup.

Not what is indicated in the man page.

Hmm, interesting.

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...

Question :
the obj_begin initializes a list with symbols defined later in a static
way and there is no references to the _start function (as you stated
yourself). So I repeat my first question, how the linker can resolve all
the symbols if obj_begin is placed after the first gnu-prolog use ?

The linker makes as many passes as required over the objects and libraries
to resolve all symbols that are needed. You can reference a symbol both
backwards and forwards (in the object-list sense). As you said, the
symbols in question a static; the linker has them all in its hands at
the same time.

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.

reply via email to

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