[erlang-questions] Erlang crypto_drv in R13B02/03 fails to load on amd64-Solaris2.10
Mon Nov 23 14:59:30 CET 2009
(Long time no speak. How've you been?)
No, I carefully tried to manually run the commands to load the driver
as they are in crypto_server.erl, and checked the paths used. So I'm
confident that the correct crypto_drv.so is being loaded.
I have another piece of the puzzle:
gcc -64 -G -o ../priv/lib/i386-pc-solaris2.10/crypto_drv.so ../priv/obj/i386-pc
gcc: unrecognized option '-64'
This is the same link command issued by the Makefile, regardless of
whether the linker is GNU ld or Solaris ld. The configure script seems
to assume that one size fits all.
I'm going to try ./configure --without-gnu-ld
--with-ld=/usr/ccs/bin/ld just to see if this hint is picked up by the
On Mon, Nov 23, 2009 at 1:08 PM, Robert Raschke <> wrote:
> Hi Pete,
> On Mon, Nov 23, 2009 at 11:19 AM, Peter-Henry Mander
> <> wrote:
>> Hi Scott,
>> No, I don't think that the issue is to do with paths. The loader
>> _does_ find the crypto_drv.so file, and fails to load it because
>> "symbol (unknown): value 0xfffffd7ffd514fdf does not fit." I began to
>> think that it was an AMD ABI "memory model" issue, where a 64 bit
>> offset could not fit into a 32 bit value of an address register
>> relative memory access instruction.
>> Per pointed out that there are symbols in the crypto_drv.so file which
>> suggest that the linker is being invoked with the wrong options,
>> resulting in what smells like a stand-alone executable file with a
>> main() function, not a shared library object.
>> I'm going to continue hacking the Makefiles to see if adding the
>> suggested -shared option to the crypto_drv linker command makes a
>> positive difference.
> And you are sure the right crypto_drv.so is getting picked, yes? You don't
> by any chance have another one on your system, which might be getting in the
> way? Potentially stupid question, I know, but worth asking nonetheless.
More information about the erlang-questions