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.

If libfoo.so.N is actually a symlink pointing to libfoo.so.X.Y.Z, say,
then, if the symlink target is not in RISC OS format (i.e.
libfoo/so/X/Y/Z), then any binary using the library fails to find it at
load time.

This inconsistency is causing me serious pain when cross compiling: I
absolutely do not want to special case in my buildsystem the export of
libraries ready for installation on a RO machine. That is, I expect
installation into a cross compilation environment and export for target
install to be identical, as far as my buildsystem is concerned. The only
difference should be an environmental override of LN, such that RISC OS
format symlinks are produced.

As it stands, I have a hacky wrapper script[1] around
arm-unknown-riscos-ln, that massages the parameters into something
approximating usefulness. My buildsystem already generated Unix format
sonames, so as far as I am concerned, nothing needs to change there.


J.

1. ro-ln:

#!/bin/bash -e

# ln wrapper for RISC OS

export GCCSDK_INSTALL_CROSSBIN=/home/riscos/cross/bin

command=${GCCSDK_INSTALL_CROSSBIN}/arm-unknown-riscos-ln

params=
target=
dest=

for param in $@ ; do
  if [ -n "$target" ]; then
    params="$params $target"
  fi
  target=$dest
  dest=$param
done

# Convert target to RISC OS format 
# (assumes it was a Unix format leafname)
# Surely this conversion should be performed by ln itself?
target=$(sed -e s#\\.#/#g <<< $target)

# Run command, appending RISC OS filetype to link filename
exec $command $params $target "$dest,1c8"



_______________________________________________
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

Reply via email to