[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

> 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

reply via email to

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