Re: Always the problem between gplc/gcc

[bruno patin]

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