[gccsdk] Shared Library confusion

[Jan-Jaap van der Geer]

Peter Naulls <peter at chocky.org> wrote:

> Jan-Jaap van der Geer wrote:

> > /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?

> I think the main problem is that you may simply be the first
> to try this exact thing.  All of my shared library stuff
> has been cross compiled to date.

I see.

> > 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

> That seems ok, if not 100% satisfactory, as you've noted.

As this solution involves copying a symlink, this would mean that
it's OK to check in a change where these symlinks are ready made
during packaging, I suppose?

Alternative, would it be possible to refer to a specific file, for
example a -l which points to libintl/so/8 ? What would be the
syntax for that? I tried some variants, but was not successful.

> > 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".

> If you look at a standard Linux setup, you'll see there are
> generally 3 files for a shared library, two of which are
> symlinks, We have this inside !SharedLibs too.

Indeed.

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

> Well, not really.  Certainly the linker on Linux knows where to
> look for the libraries (/usr/lib) by default, and there's no
> reason we can't do the same for RISC OS.  One complicating factor
> here is our packaging of libraries from the autobuilder as RISC
> OS applications.

This would not be a problem for shared libraries, as these live in
!SharedLibs, as far as I can see. But maybe the same problem exists
for static libraries? That would be a problem, yes.

> Anyway, in conclusion, I don't have a particular solution here,
> but you might be able to come up with one.

Are there good reasons not to put the static libraries in
!SharedLibs as well? It seems the linux /usr/lib also contains
static libraries.

I noticed that some of the symlinks point to /lib as well. I really
need to read a bit about the linux directory structure. Lots of
mysteries for me there.

Thanks,
Jan-Jaap