[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: solaris 11 (i386), PIC, dlopen &c

From: Bruno Haible
Subject: Re: solaris 11 (i386), PIC, dlopen &c
Date: Wed, 4 May 2011 20:07:39 +0200
User-agent: KMail/1.9.9

Sam Steingold wrote:

> 2. dynmod/lib-wildcard.so cannot be created when clisp is configured
> --with-debug:
> gcc -shared -Wl,-z -Wl,text -Wl,-h -Wl,lib-wildcard.so -o 
> /export/home/sds/src/clisp/current/build-g/dynmod/lib-wildcard.so wildcard.o 
> libgnu_wc.a -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit 
> -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral 
> -falign-functions=4 -g -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE 
> Text relocation remains                         referenced
>     against symbol                  offset      in file
> .bss (section)                      0x5e        libgnu_wc.a(fnmatch.o)
> .rodata.str1.1 (merged string section) 0x97             libgnu_wc.a(fnmatch.o)
> .bss (section)                      0xad        libgnu_wc.a(fnmatch.o)
> .bss (section)                      0x1d2       libgnu_wc.a(fnmatch.o)
> ...
> ld: fatal: relocations remain against allocatable but non-writable sections
> collect2: ld returned 1 exit status

In my experience with the Solaris linker, this error goes away when you
omit "-g" from the CFLAGS for all compilation units that make up the
library. I conclude that there is some friction between the debugging
information emitted by gcc and the linker's interpretation of this
debugging information.

> 3. when clisp is configured normally, dynmod/lib-wildcard.so is created
> without an error, but loading is fails:
>  (REQUIRE "wildcard") ==>
> ;; Loading file /.../dynmod/wildcard.lisp ...
> ;;  Loading module wildcard from /.../dynmod/lib-wildcard.so
>   "ld.so.1: lisp.run: fatal: relocation error:
>   file /.../dynmod/lib-wildcard.so: symbol rpl_mbsrtowcs:
>   referenced symbol not found"

Here you need to play around with "nm" to see whether lib-wildcard.so
is right in expecting the symbol rpl_mbsrtowcs and where this symbol
is defined. Use a "grep MBSRTOWCS config.status" in order to understand
which symbol should be defined.

In memoriam Henri Curiel <http://en.wikipedia.org/wiki/Henri_Curiel>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]