[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: |
Mon, 26 Aug 2002 08:21:43 +0300 (EEST) |
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?
> 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. 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.
> 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.
Hmm, interesting.
> 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.
--
Timo Karjalainen "I don't have a life.
I have a program."
- Star Trek: Voyager
- Always the problem between gplc/gcc, bruno patin, 2002/08/20
- Re: Always the problem between gplc/gcc, bruno patin, 2002/08/23
- Re: Always the problem between gplc/gcc,
Timo Karjalainen <=
- Re: Always the problem between gplc/gcc, bruno patin, 2002/08/26
- Re: Always the problem between gplc/gcc, Timo Karjalainen, 2002/08/30
- Re: Always the problem between gplc/gcc--obj_chain and initialization, spratt, 2002/08/30
- Re: Always the problem between gplc/gcc--obj_chain and initialization, Timo Karjalainen, 2002/08/30
- Re: Always the problem between gplc/gcc--obj_chain and initialization, spratt, 2002/08/30