Hi,
thank you, Dago.
I made some important discovery, more below. I think a test failing is
the problem.
Dagobert Michelsen wrote:
I committed an adjusted PATH during configure in r24719. However, the
compilation
still fails with
>libtool: link:/opt/csw/bin/gcc-4.9 -shared -fPIC -DPIC -Wl,-z -Wl,text -Wl,-h
-Wl,libffi.so.6 -o .libs/libffi.so.6.0.4 src/.libs/prep_cif.o src/.libs/types.o
src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o
src/x86/.libs/ffi64.o src/x86/.libs/unix64.o src/x86/.libs/ffi.o
src/x86/.libs/sysv.o -L/opt/csw/lib/64 -O2 -m64 -march=opteron -m64
-march=opteron -m64 -march=opteron
>ld: fatal: file src/x86/.libs/unix64.o: section [5].eh_frame: section type is
SHT_PROGBITS: expected SHT_AMD64_UNWIND
>collect2: error: ld returned 1 exit status
Probably you need to dive deeper in ELF and linking.
I think the problem is that the test:
checking toolchain supports unwind section type... no
returns no and not yes.
In fact, we have this in the code:
#ifdef __GNUC__
/* Only emit DWARF unwind info when building with the GNU toolchain. */
#ifdef HAVE_AS_X86_64_UNWIND_SECTION_TYPE
.section .eh_frame,"a",@unwind
#else
.section .eh_frame,"a",@progbits
#endif
(only for GNUC, this is why this wasn't happening with previous suncc, I
don't know why it does work on 32bit though).
I manually defined in i386-pc-solaris2.10/fficonfig.h
HAVE_AS_X86_64_UNWIND_SECTION_TYPE to 1
An now build completes. Which makes sense: it is exactly the warning our
linker is spitting out.
The question is now: why does the check fail? I did some search and
found this:
https://github.com/atgreen/libffi/issues/42 "Ensure the whole toolchain
supports unwind section type"
For your convenience, a quick link to the patch:
https://hg.mozilla.org/mozilla-central/diff/94dc6f0b5f8b/js/src/ctypes/libffi/configure.ac
The goal would be that both compiler and linker support the type. We
should have this patch (our message says "toolchain")
Why does it fail? the check should return "yes", the test explicitly
says linker. Could it be that a different linker is used? That our
environment is not set up correctly? Linking is done with $CC, so it
should be fine, shouldn't it?
Riccardo
