[gccsdk] Shared library soname and symlink target inconsistency

[Peter Naulls]

John-Mark Bell wrote:
> 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.

You shouldn't have to have any at all - no argument there.  Although
there's always a couple of packages that do builds in a "special"
way - especially over the 250 odd we have - and need hand holding.

> 
>> 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. 

Well, it's significant to me, since this is how I presently access such
files for testing.  Right now, I certainly don't have a good way
way for this to happen - via a zip file or otherwise. Ideally, I would
perhaps have some kind of local development RiscPkg repository.

> 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.

You don't want to override 'LN', the meaning is too varied at
different times to hope for consistency.  To get the result you
want (almost all the time anyway) is to override it in the path as
is done for 'cp' during package generation.

> 
> 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.

No, but a check that we didn't really generate unix-style links
would be prudent.