Ron wrote:
In message <[email protected]> you wrote:
Ron wrote:
The !SharedLibs ReadMe is very helpful for a newcomer to understand
it's purpose.
That's good to know :-)
However I found the paragraph explaining how to use the -soname=
option completely wrong.
If "/" is used, the lib will not load for either use by gcc at
linking, or for the executable that is linked to it.
You must use, -soname=libefg.so [.so.1.2] syntax.
I think this is a case of the documentation lagging behind development.
When I first wrote the !ReadMe, the name translation for the dynamic
loader was very basic. At some point it was upgraded to use the
riscosify code to make using libraries created with the autobuilder easier.
Hi, 'completely wrong' is a bit strong, and I dont have all the answers.
I can't explain why the executable has ld-riscos/so/1 near the SOF
and yet that is also a sharedlib. I imagine it is getting written
that way by gcc.
gcc has a .suffix in and /suffix out general pattern.
The dynamic loader, ld-riscos/so/1, is a special case of a shared
library. It is responsible for loading all other shared libraries
required and linking them together at runtime, but of course it can't
load itself, the Shared Object Manager (SOM) has to do that. As a
module, SOM doesn't have access (or at least it didn't at the time) to
UnixLib code like the riscosify filename translation so I used RISC OS
format when specifying it as the program interpreter so that SOM could
use it directly. You can see ld-riscos/so/1 embedded in the executable
near the start of the image because that's where the name of the program
interpreter is stored. SOM will use whatever program is named here as
the dynamic loader (AKA program interpreter).
For linking you can just use -lefg, and avoid the need to
get around gcc treating libefg/so as a directory.
Well, -lefg is the preferred way of doing it.
Actually simply renaming to libefg for -I would work, but it is
simpler to just use SharedLib: and avoid the translations
altogether.
I'm not sure what you mean here, -I is used for include directories.
Sorry, working from memory, might be -L .
Yes, -L specifies library paths for the linker.
I think it works in the gcc command with no switch, if it is in the CSD.
GCC searches GCCSOLib: for shared libraries. When !SharedLibs is run, it
adds itself (i.e. 'SharedLibs:lib.') to this path so that GCC can find
the libraries. When you build a library, you have to copy it to
SharedLibs:lib so that the compiler can find it at build time and the
dynamic loader can find it at runtime.
The next step will be to write the shared object (libefg/so)
and any links directly to SharedLib:lib/ instead of producing
it in the CSD. (untried)
Usually, your makefile would arrange for the shared libraries to be
placed in a build directory which would be made known to GCC using the
-L switch. You then refer to them like -lefg which makes it easy to
switch between static and dynamic linking, assuming you have static and
shared versions of your library. Then your makefile install target would
copy the libraries and symlinks from your build directory to
SharedLibs:lib. This is basically how a Linux build system works.
I guess for building/testing you could add your build directory to
GCCSOLib: (build time) and LD_LIBRARY_PATH (runtime), but that sounds a
bit messy.
Perhaps it's time I looked at writing or porting some version of
ldconfig to generate the symlink files automatically.
The output has to be SharedLibs:/lib/libefg.so
For the makefile, I guess you could use LIB = SharedLibs:/lib/
Makefiles that I have so far, seem to use the ln command
for making the links, I was going to look at doing the same,
as we have a ln binary.
Yes, ln was written to have the same syntax as the Linux version,
although obviously filename formats cloud the issue a bit.
Anyway, I'll fix the documentation so that it recommends the use of Unix
style names.
Well, nobody has spoken up with the contrary yet.
The internal sonames of the supplied libgcc_s/so/1 and others
are in '.' form, so I think it is safe to say.
I think a few of the details above could do with being added too.
Thanks,
Lee.
_______________________________________________
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
