[gccsdk] Shared Library confusion
Jan-Jaap van der Geer
jjvdgeer at inbox.com
Mon Sep 7 14:54:01 PDT 2009
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.
> > 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.
> > 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
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.
More information about the gcc