[gccsdk] Shared library soname and symlink target inconsistency

[John-Mark Bell]

On Thu, 2010-01-07 at 09:08 -0800, Peter Naulls wrote:

> Just some observations as a follow on from IRC discussion:
> 
> Any symlinks probably need to be entirely in RISC OS format.  This
> is because other non-UnixLib components (such as various modules
> or even RISC OS itself) might try to use them in future.  Such
> an enforcement might require some assumption changes in UnixLib.

That should be fine, providing that arm-unknown-riscos-ln performs the
appropriate path munging when invoked on a unix host. I really don't
want to have to add even more special casing for RISC OS in my
buildsystem.

> Cross compiled libraries will almost always have Unix format
> sonames and symlinks, since they'll come out of existing
> build systems for Unix.  But we might occasionally see RO
> format sonames, for whatever reason - e.g, native Makefiles.

Given that sonames are essentially just a string, it probably makes life
simpler all round if we just specify that they should be unix format. As
I've already said, RO format sonames simply don't work at all right now.

> symlinks via SunFish are just viewed as the file itself.  This is
> mostly of consequence in development rather than deployment.

Well, that'd be an issue for SunFish, surely, and thus mostly orthogonal
to the issue of generating RO symlinks on a Unix host. 

Note that, if I'm installing into a cross-compilation environment, I'd
expect native symlinks to be generated. With my buildsystem, this is
achieved by it using the native ln by default. If I'm actually
generating a package to be installed on RO, I simply override LN in the
environment. I'm pretty sure the exact same thing can be achieved for
most autoconf-based buildsystems.

> We can put extra logic in the package generation and library
> packaging easily enough to properly ensure RO style symlinks
> and RO format filenames in the symlinks should that be required.
> 'zip' itself has some unhelpful behaviour here, so any checking
> we do would be good.

I'm not sure that I see a problem with zip in this case: on a unix host,
RO-style symlinks, as generated by arm-unknown-riscos-ln, are just
normal files. Thus, zip shouldn't ever have a problem with them.

> For the sake of clarity to anyone who is not familiar, the
> RISC OS symlink setup is more akin to the Windows ".lnk" file
> than the Unix symlink file, and so a RISC OS symlink generated
> under Unix will be an explicit file, ideally with a ,1c8
> extension.

Well, that's another thing for arm-unknown-riscos-ln to be doing :)

Upon reflection, I'm pretty sure that all of the problems I had can be
solved by making ln more intelligent wrt paths.


J.