[gccsdk] Shared library soname and symlink target inconsistency

Peter Naulls peter at chocky.org
Thu Jan 7 09:08:34 PST 2010


John-Mark Bell wrote:
> On Wed, 2010-01-06 at 12:42 -0800, Peter Naulls wrote:
>> John-Mark Bell wrote:
>>>
>>>    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.
>> I think this is the main problem.  The rest of the toolchain is UnixLib,
>> and makes use of riscosify around all file operations.  
> 
> Right, so that implies Unix paths everywhere, no?
> 
> In which case, item 1 in my suggested solution certainly needs to
> happen.

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.

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.

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

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.

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.





More information about the gcc mailing list