Re: [Gm2] A bit more informed

[Martin Kalbfuß]

My further studies has shown that -fshared and -shared are the same.
Both have no effect when used together with the -c option. They are only
useful without the -c option and if the object files are already
compiled. This is a different behavior then gcc has. If there are no
object files, gcc creates them out of the sources. gm2 needs the
-fmakeall option to behave like this.

So to create a shared library, the right command line is

################################################
gm2 -fshared -fPIC -fmakeall *.mod -o libname.so
################################################

or

################################
gm2 -c -fPIC *.mod
gm2 -fshared *.mod -o libname.so
################################

And when Each module should be a separate shared object then the way to
create them is

########################################################
for i in *.mod ; do
        do gm2 -fshared -fPIC -fmakeall $i -o ${i%.*}.so
done
########################################################

or

#####################################
gm2 -c -fPIC *.mod
for i in *.mod ; do
        gm2 -fshared $i -o ${i%.*}.so
done
#####################################


I think the result of this is what should be in the SO directories.
Not the relocatables. 

Finally I THINK I understand the process of creating shared libraries.
Hopefully :-)


Am Freitag, den 02.10.2009, 20:46 +0200 schrieb Martin Kalbfuß:
> I tested some command lines and had a look at the results with "file"
> and "ldd". Nice tools.
> 
> I created a shared object out of a relocatable with
> 
> gm2 -fPIC -c Library1.mod
> gm2 -shared Library1.mod -o libtest.so
> 
> file gives me
> 
> Library1.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV),
> not stripped
> 
> for the module and
> 
> libtest.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV),
> dynamically linked, not stripped
> 
> for libtest.so
> 
> So this looks fine.
> 
> Then I compiled the program object file with
> 
> gm2 -c program.mod
> 
> file gives me
> 
> program.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV),
> not stripped
> 
> Looks like this is a relocatable, too. But I didn't used -fPIC?
> 
> Then I linked the program with
> 
> gm2 program.mod -L. -ltest
> 
> file gives me
> 
> a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not
> stripped
> 
> and ldd
> 
> linux-gate.so.1 =>  (0xb805e000)
> libtest.so => /home/martin/opt/projects/mod/libtest.so (0xb8031000)
> libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb800b000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7f19000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7eee000)
> libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7d8f000)
> /lib/ld-linux.so.2 (0xb805f000)
> 
> All looks fine. And the program executes without any errors.
> 
> I'm still confused about the relocatables in the SO directory of pim
> library. How this works? Is the shared object created on the fly? Or can
> I link directly to relocatables?
> 
> What is -fshared good for?
> Why do you used -fPIC -fshared for the creation of the shared object?
> Why to use -fPIC if the object is a relocatable anyway?
> 
> I hope this looks a bit less lazy then the entry before.
> 
> 
> 
> _______________________________________________
> gm2 mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/gm2