[gccsdk] Shared Library confusion

alan buckley alan_baa at hotmail.com
Wed Sep 9 01:15:26 PDT 2009

> On Mon, 7 Sep 2009 23:54:01 +0200 Jan-Jaap van der Geer wrote:
> 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.

I had looked at SharedLibraries for packaging for a while

and it seems to me that for a SharedLibrary you need to

create the full version library (e.g. libY/so/1/2) then create

symlinks libY/so/1 and libY/so. These should all be installed

to !SharedLibs.


I believe static libraries for RISC OS should be installed

in the standard RISC OS way. i.e. An application directory

that sets the location of them.


Unfortunately I can't remember the linux convension

or how GCC works. I think you always link to libY/so

and the runtime will then use the libY/so/1 to resolve

it at run time or have I missed something or got that

the wrong way round?


Anyway I think it lead to a static link line with flags:


 -LLibY: -ly


and a shared link line something like:


-L/SharedLibs:lib/ -ly


But I too would like clarification on this.


The packages created by the autobuilder would be

a package for the shared libraries (runtime) called

liby and the developer package liby-dev.


liby would just install the shared libraries into the

!SharedLibs directory and have a dependency on

the SharedLibs package (or SharedLibs-c/c++

packages) which set up the !SharedLibs directory.


The create-riscpkg script creates these packages

from the standard packages.


liby-dev just installs the static libraries in a !LibY



Please correct any misunderstanding I have.





Access your other email accounts and manage all your email from one place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.riscos.info/pipermail/gcc/attachments/20090909/056adb9e/attachment.html>

More information about the gcc mailing list