[gccsdk] Shared Library confusion

[Jan-Jaap van der Geer]

Hello,

I locally have added a package to the autobuilder: "libgee".
To test, I tried compiling an example program. I thought I'd do
that with shared libraries.

This is the example:

http://live.gnome.org/Vala/GeeSamples

I compiled with

*valac --pkg gee-1.0 gee-list.vala --vapidir=<ValaVapi$Dir> -C

So far so good.

I did the same on linux (native compiler), where I could use this
to compile:

gcc gee-list.c -o gee-list \
-I/usr/include/gee-1.0 -I/usr/include/glib-2.0 \
-I/usr/lib/glib-2.0/include  -lgee -lgobject-2.0 -lglib-2.0

The equivalent for RISC OS would be, I supposed:

gcc gee-list.c -o gee-list \
-ILibGee: -I/LibGLib2:glib-2.0 \
-lgee -lgobject-2.0 -lglib-2.0

However, this resulted in:

/ADFS::HardDisc4.$/Projects/Vala/gcc-shared/!GCC/bin/ld: cannot
find -lgee collect2: ld returned 1 exit status

There seemed not to be a libgee/so file in !SharedLibs.lib, but
libgee/so/1 and libgee/so/1/0 were present. I resolved this by
copying one of those files and naming it libgee/so.

Question: Is this an error in my LibGee package?

After that, I got this error:

/ADFS::HardDisc4.$/Projects/Vala/gcc-shared/!GCC/bin/ld: warning:
libintl.so.8, needed by /GCCSOLib:/libgee.so, not found (try using
-rpath or -rpath-link)
/ADFS::HardDisc4.$/Projects/Vala/gcc-shared/!GCC/bin/ld: warning:
libpcre.so.3, needed by /GCCSOLib:/libgee.so, not found (try using
-rpath or -rpath-link)
/ADFS::HardDisc4.$/Projects/Vala/gcc-shared/!GCC/bin/ld: warning:
libdl.so.1, ne eded by /GCCSOLib:/libgee.so, not found (try using
-rpath or -rpath-link)

In this case, libintl/so/8, libpcre/so/3 ande libdl/so/1 did exist.
I resolved these by also copying some of these files to a
lib<name>/so version where they did not exist, and adding -lintl
-lpcre -lbd.

The result was fine:

*gcc gee-list.c -o gee-list -ILibGee: -I/LibGLib2:glib-2.0 -lgee \
-lgobject-2.0 - lglib-2.0 -lintl -lpcre -ldl

*gee-list
1
2
3
4
10

Question: Is it correct that I need to supply these libraries? I
suppose that the way I do it now only works if the lib<name>/so
version is the exact correct version that is needed. If not, I
would need to update the lib<name>/so file which seems "not
optimal".

I find it also peculiar that it apparently is not needed on the
linux version of GCC.

Cheers,
Jan-Jaap