Peter Naulls <[email protected]> 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 _______________________________________________ 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
