Re: Linking problem building iconv on Solaris x86

[Dr. David Kirkby]

On 08/11/10 05:33 AM, Ralf Wildenhues wrote:
> * Dr. David Kirkby wrote on Tue, Aug 10, 2010 at 11:33:36PM CEST:

> > > 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.
> >
> > If you don't know, I'm sure I don't.
>
> Can you try removing that from the archive_cmds and archive_expsyms_cmds
> variable settings in the first 150 lines of the generated libtool script
> and seeing if the link then works?  You might still have to also remove
> -no-undefined from the link command line again.  Thanks.

There's no such things in the first 150 lines, but if you are happy with the 
first 320 lines, then yes. I set:

archive_cmds=""
archive_expsym_cmds=""

That seems to have some benefit, as there are now two lines of errors:

Text relocation remains                         referenced
    against symbol                  offset      in file
aliases_lookup                      0x1a1be     objects/.libs/iconv.o
aliases_lookup                      0x1a394     objects/.libs/iconv.o
ld: fatal: relocations remain against allocatable but non-writable sections

rather than the five I had before.

Text relocation remains                         referenced
    against symbol                  offset      in file
aliases_lookup                      0x1ab1e     .libs/iconv.o
aliases_lookup                      0x1acf4     .libs/iconv.o
aliases_lookup                      0x1b234     .libs/iconv.o
aliases_lookup                      0x1b40a     .libs/iconv.o
aliases_lookup                      0x1bd04     .libs/iconv.o
ld: fatal: relocations remain against allocatable but non-writable sections

With the empty commands now, if I now change to the lib directory, and run what 
you said earlier (without -no-undefined), it does appear the libraries build, 
though note there's an error message about "../libtool: line 952: rmr: command 
not found"

(sage subshell) fulvia:src drkirkby$ cd lib
SAGE_ROOT=/home/drkirkby/fulvia/64/sage-4.5.3.alpha0
(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: rmr  .libs/libiconv.la .libs/libiconv.lai .libs/libiconv.so 
.libs/libiconv.so.2
../libtool: line 952: rmr: command not found
libtool: link: (cd ".libs" && rm "libiconv.so.2" && ln -s "libiconv.so.2.5.0" 
"libiconv.so.2")
libtool: link: (cd ".libs" && rm "libiconv.so" && ln -s "libiconv.so.2.5.0" 
"libiconv.so")
libtool: link: ( cd ".libs" && rm "libiconv.la" && ln -s "../libiconv.la" 
"libiconv.la" )

I confirmed the .so was a 64-bit shared library (at least according to the 
'file' command).

> If that works, then at least you have a workaround.

It's not so easy as that, as I don't know how to modify the makefile/configure 
script so that it installs all the files needed in the right places. This does a 
lot more than build a few libraries that I can copy to a lib directory.

The other problem is that to make some progress on Sage, I really need a package 
that is not going to be very difficult for someone to install. Getting people to 
test on Solaris is hard enough - without the hassles of them doing this manually

> And, do you have a link to a tarball that shows this issue?

I created one. This is built outside of Sage. All I set was CLFAGS to -m64 and 
configured with --prefix=/tmp, which I guess was unnecessary.

http://boxen.math.washington.edu/home/kirkby/failed-Solaris-10_x86-build-of-libiconv-1.13.1.tar.bz2

It will extract to a directory "libiconv-1.13.1" and not 
"failed-Solaris-10_x86-build-of-libiconv-1.13".

At 4.6 MB it is too large to attach to the trac ticket

http://trac.sagemath.org/sage_trac/ticket/9718

Does this look like it is a libtool bug to you? If so, it might be the answer to 
a lot of problems people experience with these errors on Solaris.

> A login might help, thanks, but it might take a while to look at it.

I've requested you one, as you should have seen in the private email.

 >> It's not so obvious where the bug here is, which is perhaps why
> > people don't really know where to report it to.
>
> Good point.
>
> Thanks,
> Ralf

Thank you for your help Ralf.

Dave