Re: Always the problem between gplc/gcc

[bruno patin]

> >    
>
> Not just before the main. Near the very beginning of the object list.
> Before any of your own object modules.
>
> I suppose the object list then looks like
>
> <C_compiler_startup>.o obj_begin.o your_module.o your_mod2.o ...
> library.lib lib2.lib ... libN.lib
>
> Am I correct? Is the above what you successfully linked your program with?

You're totally right and after my today experimentations I can say we 
can produce shared library that works (gcc -shared -o libtoto.so 
obj_begin.o modue1 ...). 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.

The problems that arises and the question :

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.
problem 2 :
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 want to 
use it as it permits me to port the development on the cygwin platform 
easily and create the necessary dll. 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 
and do other cryptic operations I don't want to understand so ... I've 
cross half the river.

Strange fact :
In my test I've created a library containing only one file, that is my 
module and use this library to replace my module object.

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

if you pass the nm command, no differences at all on the symbols defined 
(as I wait for), only the header for the library.
the first exec works and not the second. I am obliged to think that 
libraries are not treated by gcc on the same status that objects. Not 
what is indicated in the man page.

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 ?

What I also don't nderstand is why this little initialisation can't be 
done by the gnuprolog.h file.

that's all for tonight and thank you  for your help

ps : your previous mail is attached in order to make it accessible to 
the gnu list
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: Always the problem between gplc/gcc
>
>
>
>
> Date: 
>
> Fri, 23 Aug 2002 10:13:15 +0300 (EEST)
>
>
>
>
> Hi,
>
> > >It could be that the initialization code is written as code to go into
> > >startup. There's no call to it anywhere. Linking it later in the program
> > >than startup means that it won't be run. You can link without problems
> > >because all data symbols are present, only nobody will call the code and
> > >so you end up with uninitialized variables runtime.
> >
> > I have not make test but does it mean that if I want to create an exec I
> > always have to place obj_begin.o before the object containing the main
> > symbol ?
>
> Not just before the main. Near the very beginning of the object list.
> Before any of your own object modules.
>
> I suppose the object list then looks like
>
> <C_compiler_startup>.o obj_begin.o your_module.o your_mod2.o ...
> library.lib lib2.lib ... libN.lib
>
> Am I correct? Is the above what you successfully linked your program with?
>
> > And if it is right how can we produce complete dynamic or
> > static libraries ? This would permit to create totally independant
> > components.
>
> Libraries don't have startup code AFAIK. I'm no expert on Unix libraries,
> but my understanding is that Unix libs are handled almost the same way as
> linking your own object files together. There's the option of doing the
> linking either compile- or load-time (static vs dynamic) and, when linking
> libs instead of your own objects, only symbols that are referenced from
> code that is already "in" will be included. So if you link statically with
> a library that has 100 routines and your program uses 10 of them, only
> those 10 (plus any others those 10 use) will end up in your program.
>
> There might be a linker magic trick that would allow placing startup code
> in a library, but that would only work on static linking, I suppose.
> Dynamic libraries are only loaded once in a Unix system for any number of
> programs using them. The startup code would be run once, when the first
> program is loaded. That's not want you want when the startup code is
> supposed to initialize an environment for each program.
>
> -- 
> Timo Karjalainen             "I don't have a life.
>                               I have a program."
>                                    - Star Trek: Voyager
>
>
>
>
> --- End Message ---