On Tue, 2010-01-05 at 19:44 -0800, Peter Naulls wrote:
> John-Mark Bell wrote:
> > I've been playing around with cross compiling shared libraries and have
> > concluded that filename handling is completely inconsistent, almost to
> > the point of uselessness.
> >
> > If the library's soname is not in Unix format (i.e. libfoo.so.N), then
> > any binary linked to it fails to find it at load time. This is contrary
> > to what !SharedLibs.docs.!ReadMe says (namely that sonames should be in
> > RISC OS format), though my testing indicates that RISC OS format sonames
> > simply don't work, anyway.
>
> I haven't seen this, but that you have doesn't overly surprise me.
> There is some riscosify logic in there that I added, but it may not
> be comprehensive. I certainly agree that the output of the
> toolchain should be immediately usable on RISC OS.
>
> For the sake of clarity, can you give me some exact examples so
> I can make sure I can repeat this?
Works:
$(LD) -Wl,-soname,libfoo.so.X -o libfoo.so.X.Y.Z
arm-unknown-riscos-ln -f -s libfoo/so/X/Y/Z libfoo.so.X
Does not work (first variant):
$(LD) -Wl,-soname,libfoo/so/X -o libfoo.so.X.Y.Z
arm-unknown-riscos-ln -f -s libfoo/so/X/Y/Z libfoo.so.X
Does not work (second variant):
$(LD) -Wl,-soname,libfoo/so/X -o libfoo.so.X.Y.Z
arm-unknown-riscos-ln -f -s libfoo.so.X.Y.Z libfoo.so.X
Does not work (third variant):
$(LD) -Wl,-soname,libfoo.so.X -o libfoo.so.X.Y.Z
arm-unknown-riscos-ln -f -s libfoo.so.X.Y.Z libfoo.so.X
That is, as I described, the soname must be in Unix format, and the
target of any symlinks must be in RISC OS format. Any other permutation
fails to work.
On reflection, the simplest fix is most likely:
a) Correct the !SharedLibs.docs.!ReadMe to require Unix format sonames
b) Modify arm-unknown-riscos-ln such that, when used in a cross
compilation environment, it does the following:
i) Expects Unix format paths as parameters
ii) Automagically riscosify the link target
iii) Append ",1c8" to the link filename (possibly of dubious utility)
When arm-unknown-riscos-ln is used in a native RISC OS environment,
it should do whatever the rest of the toolchain does wrt paths and
appropriately type the link file. Off-hand, I cannot recall what the
toolchain's path behaviour is.
The latter removes the need for any wrapper script around ln, which is
probably a desirable outcome.
J.
_______________________________________________
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