Jan-Jaap van der Geer wrote:
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.


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?

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.


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.

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





_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Reply via email to