Re: Problems compiling LuaJIT on Solaris.

[Will Metcalf <william.metcalf@...>]

Mike,

Thank you for the reply!  I have checked out a fresh version of HEAD
from the git-repo and unfortunately I'm still have the same issue.

#git log
commit bcc196eed385f6935dedc45a08f7deac2cb062a5
Author: Mike Pall <mike>
Date:   Mon Jun 13 03:22:10 2011 +0200

    Fix dumping of already stripped functions with debug info.


#make
.....
DYNLINK   libluajit.so
ld: fatal: file /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/crtbegin.o;
section [7].eh_frame and file lj_vm_dyn.o; section [9].eh_frame have
incompatibile attributes and cannot be merged into a single output
section
collect2: ld returned 1 exit status
make[1]: *** [libluajit.so] Error 1
make[1]: Leaving directory `/root/luajit-2.0/src'
make: *** [default] Error 2

uname -a
SunOS solaris-11-express 5.11 snv_151a i86pc i386 i86pc Solaris

cc -v
Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs
Configured with:
/builds2/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld
--enable-languages=c,c++,f77,objc --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-20050802)

/usr/ccs/bin/ld -V
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1726

It appears as if I don't have a define for __solaris__ but do for
__sun__ and __srv4__. If I change the checks to look for these as
well(patch attached), I get further but not it seems there is some
sort of PIC error during linking.

 touch foo.c && gcc -c -E -dM foo.c | grep -P "(solaris|sun|svr4)"
#define __sun 1
#define sun 1
#define __sun__ 1
#define __svr4__ 1

make
...
BUILDVM   ../lib/vmdef.lua
DYNLINK   libluajit.so
Text relocation remains                         referenced
    against symbol                  offset      in file
lj_tab_len                          0x4aa       lj_vm_dyn.o
lj_tab_len                          0x2ab2      lj_vm_dyn.o
lj_meta_cat                         0x7bc       lj_vm_dyn.o
lj_gc_barrieruv                     0x916       lj_vm_dyn.o
lj_gc_barrieruv                     0x964       lj_vm_dyn.o
lj_func_closeuv                     0x9c6       lj_vm_dyn.o
lj_func_newL_gc                     0x9fd       lj_vm_dyn.o
lj_tab_new                          0xa5a       lj_vm_dyn.o
lj_gc_step_fixtop                   0xa8b       lj_vm_dyn.o
lj_gc_step_fixtop                   0xae0       lj_vm_dyn.o
lj_tab_dup                          0xab6       lj_vm_dyn.o
lj_tab_newkey                       0xdf5       lj_vm_dyn.o
lj_tab_reasize                      0xf09       lj_vm_dyn.o
lj_state_growstack                  0x11ba      lj_vm_dyn.o
lj_state_growstack                  0x1795      lj_vm_dyn.o
lj_state_growstack                  0x1813      lj_vm_dyn.o
lj_state_growstack                  0x21e7      lj_vm_dyn.o
lj_state_growstack                  0x22ef      lj_vm_dyn.o
lj_state_growstack                  0x2e28      lj_vm_dyn.o
lj_meta_tget                        0x1a39      lj_vm_dyn.o
lj_meta_tset                        0x1ae1      lj_vm_dyn.o
lj_meta_comp                        0x1b5b      lj_vm_dyn.o
lj_meta_equal                       0x1bbb      lj_vm_dyn.o
lj_meta_equal_cd                    0x1bd5      lj_vm_dyn.o
lj_meta_arith                       0x1c1c      lj_vm_dyn.o
lj_meta_len                         0x1c50      lj_vm_dyn.o
lj_meta_call                        0x1c82      lj_vm_dyn.o
lj_meta_for                         0x1cc5      lj_vm_dyn.o
lj_tab_get                          0x1e69      lj_vm_dyn.o
lj_str_fromnum                      0x1ef7      lj_vm_dyn.o
lj_tab_next                         0x1f37      lj_vm_dyn.o
lj_tab_getinth                      0x2010      lj_vm_dyn.o
lj_ffh_coroutine_wrap_err           0x22e0      lj_vm_dyn.o
lj_vm_sinh                          0x2503      lj_vm_dyn.o
lj_vm_cosh                          0x2529      lj_vm_dyn.o
lj_vm_tanh                          0x254f      lj_vm_dyn.o
lj_str_new                          0x2817      lj_vm_dyn.o
lj_gc_step                          0x2e4d      lj_vm_dyn.o
lj_dispatch_ins                     0x2eb4      lj_vm_dyn.o
lj_trace_hot                        0x2f04      lj_vm_dyn.o
lj_dispatch_call                    0x2f2a      lj_vm_dyn.o
lj_trace_exit                       0x2fdc      lj_vm_dyn.o
lj_err_throw                        0x3037      lj_vm_dyn.o
ld: fatal: relocations remain against allocatable but non-writable sections
collect2: ld returned 1 exit status
make[1]: *** [libluajit.so] Error 1
make[1]: Leaving directory `/root/luajit-2.0/src'
make: *** [default] Error 2

Any ideas?  Thanks again for your help!

Regards,

Will


On Sat, Jun 11, 2011 at 9:20 AM, Mike Pall <mikelu-1106@mike.de> wrote:
> Will Metcalf wrote:
>> Has anybody out there had luck compiling LuaJIT on Solaris 11? Any
>> help would be greatly appreciated.  If I use the default make file and
>> the Solaris linker I get the following error:
>>
>> [...]
>> ld: fatal: file /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/crtbegin.o;
>> section [7].eh_frame and file lj_vm_dyn.o; section [9].eh_frame have
>> incompatibile attributes and cannot be merged into a single output
>> section
>> collect2: ld returned 1 exit status
>
> Apparently the Solaris linker is too stupid to combine read-only
> and read-write sections. And crtbegin.o uses a writable .eh_frame
> section (which is a big security hole).
>
> Anyway, I've added a workaround to LuaJIT git HEAD. Thank you for
> the report!
>
>> If I use the GNU version of ld via LD_ALTEXEC it dies almost immediately:
>>
>> [...]
>> /usr/sfw/bin/gld:built in linker script:21: syntax error
>> collect2: ld returned 1 exit status
>
> That looks more like a configuration mishap.
>
> --Mike
>
>

Attachment: 0001-__solaris__-does-not-seem-to-be-set-for-me-so-use-__.patch
Description: Binary data