Hello David,
* Dr. David Kirkby wrote on Tue, Aug 10, 2010 at 10:48:25PM CEST:
> On 08/10/10 09:28 PM, Ralf Wildenhues wrote:
> >/bin/bash ../libtool --mode=link gcc -m64 -fvisibility=hidden -o
> >libiconv.la -rpath /home/drkirkby/fulvia/64/sage-4.5.3.alpha0/local/lib
> >-version-info 7:0:5 iconv.lo localcharset.lo relocatable.lo
>
> No, it does not.
>
> (sage subshell) fulvia:lib drkirkby$ /bin/bash ../libtool
> --mode=link gcc -m64 -fvisibility=hidden -o libiconv.la -rpath
> /home/drkirkby/fulvia/64/sage-4.5.3.alpha0/local/lib -version-info
> 7:0:5 iconv.lo localcharset.lo relocatable.lo
> libtool: link: gcc -shared -Wl,-z -Wl,text -Wl,-h -Wl,libiconv.so.2
> -o .libs/libiconv.so.2.5.0 .libs/iconv.o .libs/localcharset.o
> .libs/relocatable.o -lc -m64
Hrmpf. On Solaris, we add '${wl}-z ${wl}text' to archive_cmds and
archive_expsyms_cmds unconditionally, as opposed to only with
-no-undefined. I wonder why that is the case.
But of course I also wonder why the problem happens at all. iconv.o is
built with PIC, so that would indicate a bug in GCC, or possibly the
assembler or linker. Which GCC version is this, and how was it
configured? Any chance you can create a small reproducible example to
send to the GCC bugzilla?
> I've often had these "relocations remain against allocatable but
> non-writable sections" messages on Solaris. They seem to fox a lot of
> people when you Google for them.
Sorry for them, but I don't think Google is accepting bug reports for
Libtool nor GCC. I don't recall a prior report for gcc on Solaris on
the Libtool lists (unlike for a C++ compiler on Solaris).
Cheers,
Ralf
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
