[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Always the problem between gplc/gcc
Re: Always the problem between gplc/gcc
Mon, 26 Aug 2002 20:46:32 +0100
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 =
in the gprolog.h file :
extern ObjChain *obj_chain_stop;
ObjChain obj_chain_start =
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.
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.
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.
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
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?
you are right I only don't have the energy to do it for the time being
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
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.
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.
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.
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...
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 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.