[Top][All Lists]

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

Re: Linking problem building iconv on Solaris x86

From: Ralf Wildenhues
Subject: Re: Linking problem building iconv on Solaris x86
Date: Tue, 10 Aug 2010 23:10:29 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

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 
> > -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 -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,
> -o .libs/  .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).


reply via email to

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