Nicolas Williams wrote: > On Fri, Jun 12, 2009 at 04:34:50PM -0500, Nicolas Williams wrote: >> On Fri, Jun 12, 2009 at 10:06:31PM +0100, Dr. David Kirkby wrote: >>> [...] >>> -lpthread -lc -Wl,-soname -Wl,libsqlite3.so.0 -o .libs/libsqlite3.so.0.8.6 >>> >>> If the order of libpthread and libc are exchanged, the library can be >>> built. In other words, libc needs to be linked before libpthread, not >>> the other way around. >> Hmm, that's really odd. On S10 libpthread is an empty filter on libc, >> which is a fancy way of saying that all of the code in libpthread moved >> to libc and libpthread is just a shell saying as much so that older >> programs linked with libpthread can still run. You should not add >> -lpthread to the link-edit of any program or shared object in Solaris 10 >> or above, but if you did the order in which -lpthread and -lc appear in >> the link-edit command-line should make no difference. > > I spoke to a Solaris linker engineer, and we both suspect that: a) > you're using gld,
Yes, I am. GNU ld version 2.15 b) libtool is doing things not apparent from the logs > that you've posted, Perhaps. I can post libtool if it helps. c) gld is choking on Solaris libraries that are > filters, of which two that are implicated here are: libpthread (appears > explicitly in the output you posted) and libdl (implied by the errors > about dlerror and friends). > Can you try this with the Solaris ld? Alternatively, you could look > into eliminating libtools use of libpthread and libdl, as they are not > needed under Solaris 10. I can try it with Solaris ld. > Also, you say that GNU binutils are easier to use... we'd love to find > out in what specific ways. If there's something about the Solaris ld > that you dislike, it might be a bug that we'd gladly fix, but if you > don't tell us, we might not learn about it. You should post about such > things on tools-link...@opensolaris.org (even if you're working on S10). > > Nico I'm no fan of GNU utilities - I'd love to use the Solaris tools. Sun Studio 12 would be faster than gcc on SPARC. But the problem is Sage, the maths program http://www.sagemath.org/ is written in a different way to most programs. It basically consists of a collection of open-source tools. So one tool would be used for calculus, another for stats, another for arbitrary precision arithmetic etc etc. There are 94 of them, plus optional ones! The problem is, most of those packages were written by Linux developers and have numerous GNUisms. Sorting all them out would be a major nightmare. That's the reason GNU C is used too. There are various reports of gcc working better with the GNU linker than the Sun one. So currently the plan is to get Sage working on 32-bit with gcc. Next stage will be 64-bit. Whether it will ever use the Sun tools is another matter - I think the effort in fixing so many GNUisms would be too great. I don't know if you work for Sun, but if you do, it would be really good if Sun made some open-access Suns available for developers to test their code, like HP do. I believe the Sun linker has been tried, but has caused more problems than the GNU one with the other packages. That's not a fault of Sun, but it is a fact of life. I'll try removing libpthread. That should be easy enough - if all else fails, I'll run sed on the Makefile !! _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
