On 08/05/15 18:33, alan buckley wrote:
> I'm trying to cross-compile a couple of different applications
> that end up with libcrypto linked against them.
> Unfortunately they fail with the following:
> /home/alanb/gccsdk/env/lib/libcrypto.a(dso_dlfcn.o): In function
> `dlfcn_globallookup':
> dso_dlfcn.c:(.text+0x38): undefined reference to `dlopen'
> dso_dlfcn.c:(.text+0x48): undefined reference to `dlsym'
> dso_dlfcn.c:(.text+0x54): undefined reference to `dlclose'
> /home/alanb/gccsdk/env/lib/libcrypto.a(dso_dlfcn.o): In function
> `dlfcn_bind_func':
> etc...
> This looks like the shared library loading code. I can see two
> problems.
> 1. I can't see a static build of libdl – we would need a RISC OS version
> I guess.
There is a static version of libdl in cross/arm-unknown-riscos/lib. If
you link with -ldl, then these symbols should be resolved. libdl.a is a
dummy library where the functions set errno to ENOSYS and return a
default value where appropriate. See:
gcc4/riscos/soloader/dynamic/ld.so-1.9.9/d-link/libdl/static.c
> 2. As I pass my programs through elf2aif surely the routines wouldn't work
> anyway and may cause a crash.
They wont work, no, but the effect they do have depends on the caller.
If the caller requires libdl functionality to do its job, then it'll
probably exit gracefully with an error, otherwise it may just ignore
them and carry on (just because a program links to libdl doesn't
necessarily mean that it will need to use it). If the latter, then
using elf2aif shouldn't be a problem.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
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
No comments:
Post a Comment