[erlang-questions] Erlang crypto_drv in R13B02/03 fails to load on amd64-Solaris2.10
Peter-Henry Mander
Does anyone else use the Erlang crypto application on Solaris 10, U8?
We try to compile Erlang to run as a amd64 binary to access the 64Gb
RAM on our servers. I know that crypto will load on Linux amd64, so
the driver is capable of doing what's written on the tin.
The symptom are appended below. R12B-5 can load the crypto_drv, but
R13B0{2,3} cannot.
I'm confident that the openssl-0.9.8i library is fine, we use stunnel
linked to this and it works.
We tried GCC-3.4.3 as supplied by Sun, and tried with GCC-4.4.2,
compiling with the option -mcmodel=medium to see if adjusting the
memory model would help, to no avail. This was prompted by indications
that the relocation error was due to AMD ABI, address register
relative memory access was spanning ranges beyond 2Gb in size, and
would not fit in the 32bit offset.
Help please? Yes, it works on Linux, no I can't consider deploying
that option just yet. If compiling Erlang R13B as a 32bit runtime
still enables access to the full 64Gb of memory, I may consider this
option (I haven't tried yet).
Pete.
> ~/R12B-5/bin/erl
Erlang (BEAM) emulator version 5.6.5 [source] [64-bit] [smp:8]
[async-threads:0] [hipe] [kernel-poll:false]
Eshell V5.6.5 (abort with ^G)
1> application:start(crypto).
ok
> ~/R13B02/bin/erl
Erlang R13B02 (erts-5.7.3) [source] [64-bit] [smp:8:8] [rq:8]
[async-threads:0] [kernel-poll:false]
Eshell V5.7.3 (abort with ^G)
1> PrivDir = code:priv_dir(crypto).
"/Software/R13B02/lib/erlang/lib/crypto-1.6.1/priv"
2> LibDir1 = filename:join([PrivDir, "lib"]).
"/Software/R13B02/lib/erlang/lib/crypto-1.6.1/priv/lib"
3> erl_ddll:load_driver(LibDir1, crypto_drv).
{error,{open_error,-10}}
4> erl_ddll:format_error({open_error,-10}).
"ld.so.1: beam.smp: fatal: relocation error: R_AMD64_PC32: file
/Software/R13B02/lib/erlang/lib/crypto-1.6.1/priv/lib/crypto_drv.so:
symbol main: value 0x28002cb378c does not fit"
> ~/R13B03-2009-11-19/bin/erl
Erlang R13B03 (erts-5.7.4) [source] [64-bit] [smp:8:8] [rq:8]
[async-threads:0] [kernel-poll:false]
Eshell V5.7.4 (abort with ^G)
1> application:start(crypto).
=ERROR REPORT==== 20-Nov-2009::15:24:25 ===
Unable to load crypto_drv. Failed with error:
"ld.so.1: beam.smp: fatal: relocation error: R_AMD64_32: file
/Software/R13B03-2009-11-19/lib/erlang/lib/crypto-1.6.3/priv/lib/crypto_drv.so:
symbol (unknown): value 0xfffffd7ffd514fdf does not fit"
OpenSSL might not be installed on this system.
{error,{shutdown,{crypto_app,start,[normal,[]]}}}
=INFO REPORT==== 20-Nov-2009::15:24:25 ===
application: crypto
exited: {shutdown,{crypto_app,start,[normal,[]]}}
type: temporary
________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org
Björn-Egil Dahlberg
Could you send us the build log please so we can investigate this
problem. We are specifically interested in the log entries regarding
building crypto_drv.so.
Regards,
Björn-Egil
Erlang/OTP
Per Hedeland
>"ld.so.1: beam.smp: fatal: relocation error: R_AMD64_PC32: file
>/Software/R13B02/lib/erlang/lib/crypto-1.6.1/priv/lib/crypto_drv.so:
>symbol main: value 0x28002cb378c does not fit"
From my limited experience of deciphering completely incomprehensible
linker error messages (which seems to be a universal feature across
*nixes), I would guess that you have a 32-bit beam and a 64-bit
crypto_drv.so. What does 'file' say?
>Erlang R13B03 (erts-5.7.4) [source] [64-bit] [smp:8:8] [rq:8]
Of course this is just what the build thought that it built.:-)
--Per Hedeland
Peter-Henry Mander
A useful point, but no. I've been careful to ensure that the build is 64 bit:
> /bin/file ./R13B03-2009-11-19-fix/lib/erlang/erts-5.7.4/bin/beam.smp
./R13B03-2009-11-19-fix/lib/erlang/erts-5.7.4/bin/beam.smp: ELF
64-bit LSB executable AMD64 Version 1, dynamically linked, not
stripped
> /bin/file ./R13B03-2009-11-19-fix/lib/erlang/lib/crypto-1.6.3/priv/lib/crypto_drv.so
./R13B03-2009-11-19-fix/lib/erlang/lib/crypto-1.6.3/priv/lib/crypto_drv.so:
ELF 64-bit LSB dynamic lib AMD64 Version 1, dynamically linked,
not stripped
I'm not saying that nothing slipped the net, I've not checked every
single file, but at least not the runtime nor the crypto driver.
Björn-Egil Dahlberg and Sverker Eriksson suggested that linker flags
"-Wl,-Bsymbolic" applied to crypto_drv.so build might offer respite,
but this was unsuccessful. I may have stuck in the wrong place, mind
you.
Pete.
On Fri, Nov 20, 2009 at 9:00 PM, Per Hedeland <p...@hedeland.org> wrote:
> From my limited experience of deciphering completely incomprehensible
> linker error messages (which seems to be a universal feature across
> *nixes), I would guess that you have a 32-bit beam and a 64-bit
> crypto_drv.so. What does 'file' say?
On Fri, Nov 20, 2009 at 5:18 PM, Sverker Eriksson
<sve...@erix.ericsson.se> wrote:
> On 64-bit Linux we added gcc option "-Wl,-Bsymbolic" to get crypto to link
> in R13B03. Could be worth a try on solaris as well.
Per Hedeland
>
>A useful point, but no. I've been careful to ensure that the build is 64 bit:
OK, it was just a first guess.:-)
>Björn-Egil Dahlberg and Sverker Eriksson suggested that linker flags
>"-Wl,-Bsymbolic" applied to crypto_drv.so build might offer respite,
>but this was unsuccessful. I may have stuck in the wrong place, mind
>you.
Hm, they should of course know more about the Erlang/OTP build than I
do, but the few words that are recognizable from the error message, like
"relocation error" and "does not fit", don't really suggest that it is
an issue with symbol resolution I think.
My next guess would be a -fpic vs -fPIC problem when compiling
crypto_drv - in many cases / architectures you can "get away" with using
-fpic which is supposedly slightly more efficient, but my understanding
is that -fPIC should always work and is sometimes required. Of course if
your build actually used -fPIC (likely), this is moot.
But then I recognized one more word from the message: "main". This kind
of contradicts what I wrote above, but surely there shouldn't be a
"main" symbol in crypto_drv. What does 'nm' say?
--Per
Wallentin Dahlberg
going on today).
However, it seems like similar problems exists on opensolaris + AMD64.
For instance:
http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=a68c8de187c30929fb79755edd017?bug_id=5102797
This would be kind of bad.
I don't have your build log in front of me so I can't see if this is the
case but similar problems has been solved with -fPIC and -shared and not -G
when using gcc on solaris.
LDFLAGS += -shared
CFLAGS += -fPIC
// Björn-Egil
2009/11/20 Per Hedeland <p...@hedeland.org>
Chandru
> Peter-Henry Mander <phma...@googlemail.com> wrote:
> >
> >A useful point, but no. I've been careful to ensure that the build is 64
> bit:
>
> OK, it was just a first guess.:-)
> But then I recognized one more word from the message: "main". This kind
> of contradicts what I wrote above, but surely there shouldn't be a
> "main" symbol in crypto_drv. What does 'nm' say?
>
>
Here is the output of nm on the build Peter is working on.
> nm crypto_drv.so
U AES_cbc_encrypt
U AES_cfb128_encrypt
U AES_set_decrypt_key
U AES_set_encrypt_key
U BF_cfb64_encrypt
U BF_set_key
U BN_CTX_free
U BN_CTX_new
U BN_add
U BN_bin2bn
U BN_bn2bin
U BN_free
U BN_mod_exp
U BN_new
U BN_num_bits
U BN_pseudo_rand_range
U BN_sub
U CRYPTO_cleanup_all_ex_data
U CRYPTO_num_locks
U CRYPTO_set_dynlock_create_callback
U CRYPTO_set_dynlock_destroy_callback
U CRYPTO_set_dynlock_lock_callback
U CRYPTO_set_id_callback
U CRYPTO_set_locking_callback
U CRYPTO_set_mem_functions
U DES_ede3_cbc_encrypt
U DES_ncbc_encrypt
U DES_set_key
U DH_check
U DH_compute_key
U DH_free
U DH_generate_key
U DH_generate_parameters
U DH_new
U DH_size
U DSA_free
U DSA_new
U DSA_sign
U DSA_size
U DSA_verify
U MD4
U MD4_Final
U MD4_Init
U MD4_Update
U MD5
U MD5_Final
U MD5_Init
U MD5_Update
U RAND_pseudo_bytes
U RC2_cbc_encrypt
U RC2_set_key
U RC4
U RC4_set_key
U RSA_free
U RSA_new
U RSA_private_decrypt
U RSA_private_encrypt
U RSA_public_decrypt
U RSA_public_encrypt
U RSA_sign
U RSA_size
U RSA_verify
U SHA1
U SHA1_Final
U SHA1_Init
U SHA1_Update
U SSLeay
U SSLeay_version
0000000000017ff8 D _DYNAMIC
0000000000018318 b _END_
0000000000017cf8 D _GLOBAL_OFFSET_TABLE_
w _Jv_RegisterClasses
00000000000023f8 T _PROCEDURE_LINKAGE_TABLE_
0000000000000000 r _START_
00000000000181c0 d __CTOR_END__
00000000000181b8 d __CTOR_LIST__
00000000000181d0 d __DTOR_END__
00000000000181c8 d __DTOR_LIST__
00000000000001d0 r __EH_FRAME_BEGIN__
00000000000004d0 r __FRAME_END__
00000000000181d8 d __JCR_END__
00000000000181d8 d __JCR_LIST__
00000000000181a0 D ___Argv
w __deregister_frame_info_bases
0000000000007b70 t __do_global_ctors_aux
0000000000002a10 t __do_global_dtors_aux
00000000000181b0 D __dso_handle
U __fpstart
00000000000181a8 D __longdouble_used
w __register_frame_info_bases
00000000000182a8 D _edata
0000000000018318 B _end
0000000000018198 D _environ
0000000000007cf7 R _etext
U _exit
0000000000007bc0 T _fini
0000000000007bb0 T _init
0000000000007bcc R _lib_version
0000000000002a00 T _mcount
0000000000002980 T _start
U atexit
00000000000182c0 b completed.1
0000000000002c9f t control
0000000000018200 d crypto_driver_entry
U driver_alloc
U driver_alloc_binary
U driver_free
0000000000002ab8 T driver_init
U driver_realloc
U driver_realloc_binary
U driver_system_info
0000000000007797 t dyn_create_function
00000000000077d8 t dyn_destroy_function
00000000000077b4 t dyn_lock_function
0000000000018198 V environ
U erl_drv_rwlock_create
U erl_drv_rwlock_destroy
U erl_drv_rwlock_rlock
U erl_drv_rwlock_runlock
U erl_drv_rwlock_rwlock
U erl_drv_rwlock_rwunlock
U erl_drv_thread_self
U exit
0000000000002bfb t finish
0000000000002a60 t frame_dummy
00000000000077f6 t hmac_md5
00000000000079b1 t hmac_sha1
000000000000778c t id_function
0000000000002ac5 t init
0000000000007beb r libname.0
0000000000018310 b lock_vec
0000000000007729 t locking
00000000000076f2 t locking_function
U main
U memcpy
U memset
00000000000182e0 b object.2
00000000000181e0 d p.0
0000000000007683 t return_binary
00000000000075ff t return_binary_shrink
U set_port_control_flags
0000000000002c70 t start
0000000000002c95 t stop
U strlen
cheers,
Chandru
Peter-Henry Mander
concurs with my fuzzy understanding of what is going on. "Will not
fix" since 2004? Kind of bad, indeed.
I tried -mcmodel=medium, which didn't solve the issue, and
-mcmodel=large which broke *all* of the erl_interface C file
compilation.
Aside: The "medium/large memory model" is only available with GCC-4
for shared libraries, not GCC-3, and that led me on to another,
different battle to compile GCC version 4. I succeeded thanks to
Gilles Dauphin: http://www.infres.enst.fr/~dauphin/pkgsrcmywork/
The -fPIC flag is used pretty much everywhere I looked, and flew past
very often as I went cross-eyed gazing at the compilation output,
Matrix style.
The -shared and -G flags, I don't recall seeing. I may try looking for
this on Monday.
Pete.
On Fri, Nov 20, 2009 at 10:25 PM, Wallentin Dahlberg
<wallentin...@gmail.com> wrote:
> We haven't had time to investigate this problem yet. (Lots of release stuff
> going on today).
>
> However, it seems like similar problems exists on opensolaris + AMD64.
> For instance:
> http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=a68c8de187c30929fb79755edd017?bug_id=5102797
>
> This would be kind of bad.
>
> I don't have your build log in front of me so I can't see if this is the
> case but similar problems has been solved with -fPIC and -shared and not -G
> when using gcc on solaris.
>
> LDFLAGS += -shared
> CFLAGS += -fPIC
>
> // Björn-Egil
________________________________________________________________
Per Hedeland
>>
>Here is the output of nm on the build Peter is working on.
>
>> nm crypto_drv.so
> U _exit
> U atexit
> U exit
> U main
The presence of any of those seem seriously broken for a shared object I
think - FWIW, our build of ancient but working R10B-10, 32-bit,
gcc-3.4.3, Solaris 10, has none of them. I believe they're from crt1.o,
which should only be linked into an executable. Our build log (lines
folded):
gcc -c -o ../priv/obj/sparc-sun-solaris2.10/crypto_drv.o -g -O2 \
-I/export/home/lab/build/otp/erts/sparc-sun-solaris2.10 \
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -I/usr/sfw/include \
-I/export/home/lab/build/otp/erts/emulator/beam \
-I/export/home/lab/build/otp/erts/emulator/sys/unix crypto_drv.c
/usr/ucb/install -c -d ../priv/lib/sparc-sun-solaris2.10
ld -G -L/usr/sfw/lib -R/usr/sfw/lib \
-o ../priv/lib/sparc-sun-solaris2.10/crypto_drv.so \
../priv/obj/sparc-sun-solaris2.10/crypto_drv.o -lcrypto
Those are likely *not* correct for current versions or 64-bit though.
And I believe Björn-Egil has a point about -G vs -shared - but -G is a
(Solaris) 'ld' option (and so is -R, though GNU ld may do the right
thing with it if you are lucky), while -shared is a gcc (and GNU ld)
option. I.e. basically 'ld -G -L<path> -R<path>' may need to be
replaced with something like 'gcc -shared -L<path> -Wl,-R,<path>',
assuming that you are using Solaris ld (which I think is the norm for
gcc on Solaris). Certainly switching from ld <mumble> to gcc -shared for
building shared objects has worked well for us on some more modern
*nixes.
--Per
Scott Lystig Fritchie
from this exact problem, but perhaps it's related? At Gemini we build
the VM with "./configure --prefix=/some/weird/place" and then really
install the whole package to /some/other/dir/entirely.
IIRC, we've had to add an "env
LD_LIBRARY_PATH=/some/other/dir/entirely/...openssl/lib" wrapper in our
/etc/init.d/appthingie script's invocation of our daemons.
-Scott
Peter-Henry Mander
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.
Pete.
Robert Raschke
On Mon, Nov 23, 2009 at 11:19 AM, Peter-Henry Mander <
phma...@googlemail.com> 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.
Robby
Peter-Henry Mander
(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
-solaris2.10/crypto_drv.o /Software/openssl-0.9.8i/lib/libcrypto.a
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
configure script.
Pete.
________________________________________________________________
Peter-Henry Mander
LD=/usr/ccs/bin/ld ./configure --without-gnu-ld --with-ld=/usr/ccs/bin/ld
Now I'm going to create a wrapper to gcc to replace the -64 with -m64
and -G with -shared.
Pete.
On Mon, Nov 23, 2009 at 1:59 PM, Peter-Henry Mander
<phma...@googlemail.com> wrote:
> 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
> configure script.
________________________________________________________________
Peter-Henry Mander
substitutes the Solaris 'ld' for any occurances of 'gcc' where these
flags exist:
Original: /Software/Tools-64/gcc \
-64 -G \
-o ../priv/lib/i386-pc-solaris2.10/crypto_drv.so \
../priv/obj/i386-pc-solaris2.10/crypto_drv.o \
/Software/openssl-0.9.8i/lib/libcrypto.a
Modified: /usr/ccs/bin/ld \
-64 -G \
-o ../priv/lib/i386-pc-solaris2.10/crypto_drv.so \
../priv/obj/i386-pc-solaris2.10/crypto_drv.o \
/Software/openssl-0.9.8i/lib/libcrypto.a
The build completes without error, but the original problem remains:
> ~/R13B03/bin/erl
Erlang R13B03 (erts-5.7.4) [source] [64-bit] [smp:8:8] [rq:8]
[async-threads:0] [kernel-poll:false]
Eshell V5.7.4 (abort with ^G)
1> application:start(crypto).
{error,{shutdown,{crypto_app,start,[normal,[]]}}}
=ERROR REPORT==== 23-Nov-2009::15:39:29 ===
Unable to load crypto_drv. Failed with error:
"ld.so.1: beam.smp: fatal: relocation error: R_AMD64_32: file
/Software/R13B03/lib/erlang/lib/crypto-1.6.3/priv/lib/crypto_drv.so:
symbol (unknown): value 0xfffffd7ffd6582d0 does not fit"
OpenSSL might not be installed on this system.
2>
=INFO REPORT==== 23-Nov-2009::15:39:29 ===
application: crypto
exited: {shutdown,{crypto_app,start,[normal,[]]}}
type: temporary
Going through the motions manually:
3> PrivDir = code:priv_dir(crypto).
"/Software/R13B03/lib/erlang/lib/crypto-1.6.3/priv"
4> LibDir1 = filename:join([PrivDir, "lib"]).
"/Software/R13B03/lib/erlang/lib/crypto-1.6.3/priv/lib"
5> erl_ddll:load_driver(LibDir1, crypto_drv).
{error,{open_error,-11}}
6> erl_ddll:format_error({open_error,-11}).
"ld.so.1: beam.smp: fatal: relocation error: R_AMD64_32: file
/Software/R13B03/lib/erlang/lib/crypto-1.6.3/priv/lib/crypto_drv.so:
symbol (unknown): value 0xfffffd7ffd7582d0 does not fit"
677> /bin/file /Software/R13B03/lib/erlang/lib/crypto-1.6.3/priv/lib/crypto_drv.so
/Software/R13B03/lib/erlang/lib/crypto-1.6.3/priv/lib/crypto_drv.so:
ELF 64-bit LSB dynamic lib AMD64 Version 1, dynamically linked, not
stripped
678> /bin/file /Software/R13B03/lib/erlang/erts-5.7.4/bin/beam
/Software/R13B03/lib/erlang/erts-5.7.4/bin/beam: ELF 64-bit LSB
executable AMD64 Version 1, dynamically linked, not stripped
679> /bin/file /Software/R13B03/lib/erlang/erts-5.7.4/bin/beam.smp
/Software/R13B03/lib/erlang/erts-5.7.4/bin/beam.smp: ELF 64-bit LSB
executable AMD64 Version 1, dynamically linked, not stripped
682> /usr/xpg4/bin/nm
/Software/R13B03/lib/erlang/lib/crypto-1.6.3/priv/lib/crypto_drv.so |
sed -n '/UNDEF/p'
( This does not show any references to 'main' nor 'exit' as pointer
out by Per. This time it looks as if the linker did the correct thing.
)
So, I do suspect that the configure script is getting confused by
which linker is suitable to use, but also the "relocation error:
R_AMD64_32 ... symbol (unknown): value 0xfffffd7ffd7582d0 does not
fit" is not strictly to do with the way crypto_drv.so is linked, but
something to do with the point raised by Wallentin Dahlberg on Friday:
The AMD ABI small/medium/large memory model.
Is it at all possible to regress the crypto_drv.so 'C' source back to
the one in R12B? Is the API compatible? It may have bugs that are
mended in R13B, but it didn't seem to suffer from the R_AMD64_32
error. Could this be due to changes in the way pointer arithmetic is
done in crypto_drv.c version 1.5.3 vs. version 1.6.3?
Pete.
On Mon, Nov 23, 2009 at 2:13 PM, Peter-Henry Mander
Per Hedeland
>
>The wrapper script detects the presence of -64 and -G flags, and
>substitutes the Solaris 'ld' for any occurances of 'gcc' where these
>flags exist:
>
>Original: /Software/Tools-64/gcc \
> -64 -G \
> -o ../priv/lib/i386-pc-solaris2.10/crypto_drv.so \
> ../priv/obj/i386-pc-solaris2.10/crypto_drv.o \
> /Software/openssl-0.9.8i/lib/libcrypto.a
>Modified: /usr/ccs/bin/ld \
> -64 -G \
> -o ../priv/lib/i386-pc-solaris2.10/crypto_drv.so \
> ../priv/obj/i386-pc-solaris2.10/crypto_drv.o \
> /Software/openssl-0.9.8i/lib/libcrypto.a
>
>The build completes without error, but the original problem remains:
>> ~/R13B03/bin/erl
>Erlang R13B03 (erts-5.7.4) [source] [64-bit] [smp:8:8] [rq:8]
>[async-threads:0] [kernel-poll:false]
Perhaps you need to take a step back here - what does
file .../priv/obj/i386-pc-solaris2.10/crypto_drv.o
say? From my reading of the Solaris 'ld' man page, -64 shouldn't be
needed - but it might possibly "mask" the mistake of trying to build a
64-bit shared object from a 32-bit "unshared" object.
--Per
Peter-Henry Mander
./lib/crypto/priv/obj/i386-pc-solaris2.10/crypto_drv.o: ELF 64-bit LSB
relocatable AMD64 Version 1
The gcc.wrapper script is a belts-and-braces device to prevent any 32
bit stuff from seeping through. It may be excessive, but it is a
guarantee.
I'm going to experiment with a different machine, a Core2Quad with 4Gb
of RAM. The 4Gb falls within the 32 bit address range, not the 36 bits
required by the 64Gb we have installed in the original machine. I have
a nagging suspicion that the I'm observing a Solaris10 loader bug
(suggested by Wallentin Dahlberg), that will only be triggered when
more than 4Gb RAM is available. I'm betting that the Intel EM64T is
equivalent to AMD64, and that it behaves exactly the same. To prove
the point, I shall try to plug an extra 4Gb RAM (or more, if I can
afford it) to see if the Core2Quad changes behaviour when more than 32
bits addressing range is available.
Pete.
Peter-Henry Mander
environment works for R12B-5, which it does. The crypto_drv.so loads
in R12B-5 on AMD64.
On Mon, Nov 23, 2009 at 8:46 PM, Per Hedeland <p...@hedeland.org> wrote: