Re: [sqlite] Build problem of sqlite-3.6.14.2 on Solaris 10 with gcc 4.4.0
Tim Bradshaw wrote: > On 13 Jun 2009, at 12:29, Dr. David Kirkby wrote: > >> I believe if Sun make some public access machines available, there >> would >> be a benefit to Sun, and would hopefully avoid a lot of the GNUisms >> one >> sees in software. Whether the cost would outweigh the benefit I have >> no >> idea. There is obviously the cost of power, hardware and staff to >> run it. > > I guess we probably should just agree to differ about that. I really > don't think people who can't be bothered to download & install a free > copy of Solaris (in a VM, so with no hardware cost in almost all > cases) are interested in fixing stuff on some platform other than > their favoured one. I guess we will have to agree to differ. I've no problem with that. I once reported a Solaris specific bug to some developer, who replied "As long as it builds on Redhat 8, that is good enough for me". I never understood why he bothered making the code publicly available in that case! ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Build problem of sqlite-3.6.14.2 on Solaris 10 with gcc 4.4.0
On 13 Jun 2009, at 12:29, Dr. David Kirkby wrote: > I believe if Sun make some public access machines available, there > would > be a benefit to Sun, and would hopefully avoid a lot of the GNUisms > one > sees in software. Whether the cost would outweigh the benefit I have > no > idea. There is obviously the cost of power, hardware and staff to > run it. I guess we probably should just agree to differ about that. I really don't think people who can't be bothered to download & install a free copy of Solaris (in a VM, so with no hardware cost in almost all cases) are interested in fixing stuff on some platform other than their favoured one. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Build problem of sqlite-3.6.14.2 on Solaris 10 with gcc 4.4.0
Tim Bradshaw wrote: > On 12 Jun 2009, at 23:46, Dr. David Kirkby wrote: > >> 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. > > Surely this would only matter for SPARC-related issues (which I don't > think we're looking at here, are we?) I can't imagine anyone finding > it too much hard work to install a Solaris x86 on a VM (both available > free of charge, from Sun even, if you use virtualbox). The situation > is different for HP-UX & AIX which don't run on (VMs on) commodity HW, > and even if they did might not be legal to run there. Yes, SPARC systems mainly I would agree, but ... I think there are a lot of people that can't be bothered to install Solaris x86, but might be more inclined to try to resolve Solaris-specific bugs if someone sent them a bug report, with a link to a Sun site where they could verify the bug. I've got an Intel based Sony laptop, but I gather Sony fix the BIOS in some way that prevents vitualisation software working - or possibly it works, but with poor performance. I've got OpenSolaris on that anyway, but I don't have any x86 machine with Solaris 10. HP did in fact have linux systems too and I think some of those are on x86 hardware. > The Sun compilers are free as well (though not open source to my > knowledge). Yes. > My experience (I'm contracted through Sun at the moment) is that > virtually the only place where you need to care about the x86/SPARC > thing is differences in booting, which won't matter for SQLite. I > guess compiler options might be different, and certainly getting > good performance from the CMT systems would probably require access to > them. Experience tells me, the differences are more than just booting. I assume compiler flags could be easily set on Intel based Solaris system which would not work on a SPARC based Solaris system. My Sony laptop has the BIOS screwed up *purposely* by Sony to prevent virtualisation software being used (or at least severely cripple the performance of it). That runs OpenSolaris anyway, but not everyone is going to take that route. People could often dual boot or install Solaris, but a lot don't bother. I think they could be persuaded to fix Solaris-specific bugs if they are made aware of them, and have *easy* access to a Solaris machine. Over the years, I have let the occasional developer have access to my SPARC based systems, but not as root. There was in fact someone on comp.unix.solaris recently letting people have root access in a zone. The University of Washington has given me access to their T5240, despite the fact I have my own SPARC hardware. So there are cases of people allowing others access to their SPARC based systems. But to my knowledge, Sun have never done it. The guys at the University of Washington produced some binaries of the compiler tools (based on gcc-4.3.3) to build Sage on a Blade 2500 running Solaris 10, update 4. I downloaded them to my Blade 2000, which runs Solaris 10 update 6, where they worked fine. But the fortran compiler did not work on the universities Sun T5240, which runs Solaris 10 update 4. I know of a bug in Mathematica, a rather expensive bit of software from Wolfram Research, which meant it run on a Solaris x86 system with an AMD processor, but not some Intel ones. I believe if Sun make some public access machines available, there would be a benefit to Sun, and would hopefully avoid a lot of the GNUisms one sees in software. Whether the cost would outweigh the benefit I have no idea. There is obviously the cost of power, hardware and staff to run it. Dave ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Build problem of sqlite-3.6.14.2 on Solaris 10 with gcc 4.4.0
Nicolas Williams wrote: > On Sat, Jun 13, 2009 at 01:43:15AM +0100, Dr. David Kirkby wrote: >> Thank you for your help. The fact you told me I did not need to link >> libpthread was crucial to solving this. >> >> I've found that just removing the libpthread from the generated Makefile >> solves this. > > Glad to help. I must say, Sun employees have been most helpful at solving Sun-related problems I've posted on the internet over the years. (Although this issue arose when I was trying to build Sage on the T5240 Sun at the University of Washington, I have a few Suns at home in England). I like the machines and the OS. Casper Dik, who you may know of, has solved numerous issues for me. Casper is very helpful on comp.unix.solaris. >> The offer is still there for a sqlite developer to fix this properly on >> a Sun, but as a hack, just removing the library works. See my code below. > > Where does that code go, that is, in what file? Also, isn't this a bug > in libtool? > > Nico The bit of code I posted which striped libpthread from the Makefile using sed was added to a file in the Sage project http://www.sagemath.org/ Sage aims to be a free GPL'ed alternative to the expensive commercial maths packages like Mathematica, Maple, MATLAB etc. It's primarily a Linux application. Microsoft are paying for a port to Windows, and Sun have contributed towards getting it running on Solaris. You are probably right this sqlite issue is a libtool bug. I've suspected that for some time, as a Google on error messages with 'undefined reference to somefunct...@sunw_x' have appeared in many programs over the years. Apache in particular seems to have suffered it, going back to at least as early as 2005. I had noticed that in most or all of the cases, libtool was used. But I was never sure if it was a libtool bug, or developers using libtool in an incorrect way. I would add, both sqlite 3.5.3 and sqlite 3.6.14.2 build OK on Solaris 10 update 4 with gcc 4.3.2. So I did wonder if it was a bug in gcc 4.4.0 As with many of these software issues, it is often difficult to know exactly where the fault lies. But at least in this case, a simple hack solves the problem for Sage. As a matter of interest, do you know in what release of Solaris the functionality of libpthread was moved into libc? (Don't spend too much time over it if you don't know - it's not that important to me). Dave ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Build problem of sqlite-3.6.14.2 on Solaris 10 with gcc 4.4.0
On 12 Jun 2009, at 23:46, Dr. David Kirkby wrote: > 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. Surely this would only matter for SPARC-related issues (which I don't think we're looking at here, are we?) I can't imagine anyone finding it too much hard work to install a Solaris x86 on a VM (both available free of charge, from Sun even, if you use virtualbox). The situation is different for HP-UX & AIX which don't run on (VMs on) commodity HW, and even if they did might not be legal to run there. The Sun compilers are free as well (though not open source to my knowledge). My experience (I'm contracted through Sun at the moment) is that virtually the only place where you need to care about the x86/SPARC thing is differences in booting, which won't matter for SQLite. I guess compiler options might be different, and certainly getting good performance from the CMT systems would probably require access to them. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Build problem of sqlite-3.6.14.2 on Solaris 10 with gcc 4.4.0
On Sat, Jun 13, 2009 at 01:43:15AM +0100, Dr. David Kirkby wrote: > Thank you for your help. The fact you told me I did not need to link > libpthread was crucial to solving this. > > I've found that just removing the libpthread from the generated Makefile > solves this. Glad to help. > The offer is still there for a sqlite developer to fix this properly on > a Sun, but as a hack, just removing the library works. See my code below. Where does that code go, that is, in what file? Also, isn't this a bug in libtool? Nico -- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Build problem of sqlite-3.6.14.2 on Solaris 10 with gcc 4.4.0
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, b) libtool is doing things not apparent from the logs > that you've posted, 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). Thank you for your help. The fact you told me I did not need to link libpthread was crucial to solving this. I've found that just removing the libpthread from the generated Makefile solves this. The offer is still there for a sqlite developer to fix this properly on a Sun, but as a hack, just removing the library works. See my code below. Dave if [ `uname` = "SunOS" ]; then # Linking in pthread is not necessary in recent versions of Solaris, as all the functionality is # in libc. The thread library is only included for backwards compatibility. However, libtool # appears to be messing things up, so the library will be removed from the Makefile. # This is probably not the most elegant way, but it works. # David Kirkby, 13th June 2009 sed 's/LIBPTHREAD=-lpthread/LIBPTHREAD=/g' Makefile > Makefile-without-pthread mv Makefile-without-pthread Makefile fi ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Build problem of sqlite-3.6.14.2 on Solaris 10 with gcc 4.4.0
On Fri, Jun 12, 2009 at 11:46:01PM +0100, Dr. David Kirkby wrote: > > 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 > > [...] > > I can try it with Solaris ld. OK, let us know how that goes. Also, if there's any bug in either autoconf or SQLite3 that is causing -lpthread to be added, that'd be worth knowing about too. I can't quite tell where that's coming from... > > 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). > > 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. This is getting OT for this list, so we should take it off-list. There may be some useful information below for the list, so I'll post this. Yesterday I saw a post on blogs.sun.com about Sun Studio besting GCC on x86/64 too. GCC has lots of C extensions that Sun Studio doesn't yet (it has support for some, but not all of them), and from what you say about Sage it wouldn't surprise me if some parts of Sage used these extensions. The key thing though is this: you can mix objects compiled from C source by GCC and Sun Studio. So you can build SQLite3 with Sun Studio and Sage with GCC, if that's what you want. > 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've used GCC plenty, but on Solaris I always use the Solaris ld, and I avoid libtool like the plague. I'm tempted to contribute a Makefile.solaris for SQLite3 so as to avoid libtool and make use of Solaris linker features like -Bdirect. > 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. OpenSolaris has been getting lots of FOSS integrated, and there's a /contrib repository that developers can contribute to. I'll pass the word about Sage on to the teams that are working on this. > 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. Perhaps, but we'd like to know why so we can make our linker better. Also, if gld is choking on filters, then it may be a good idea to file a bug against gld, and to at least document the incompatibility and any workarounds. On the other side, if our ld is failing because, for example, it doesn't have gld's --wrap option, or some such feature, and that becomes an issue, then we might add support for that. > I'll try removing libpthread. That should be easy enough - if all else > fails, I'll run sed on the Makefile !! :) Thanks, Nico -- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Build problem of sqlite-3.6.14.2 on Solaris 10 with gcc 4.4.0
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
Re: [sqlite] Build problem of sqlite-3.6.14.2 on Solaris 10 with gcc 4.4.0
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've no idea if that is a bug in gcc, a bug in libtool or a bug in sqlite. > > I don't see -lpthread in configure.ac, but I do see this in the output > of ./configure: > > checking whether to support threadsafe operation... yes > checking for library containing pthread_create... none required > > and then the generated Makefile does actually include -lpthread, but > only for building the Tcl module, testfixture, and sqlite3_analyzer: > > ./Makefile:LIBTCL = -L/usr/lib -ltcl8.4 -ldl -lsocket -lnsl -lpthread -lm > > Very strange. > > Nico The thing that made me try exchanging libc and libpthread was in fact some hints on other pages, totally unrelated to sqlite. There are tons of links with people having this problem on Apache, ntop, and other bits of software. libtool is always involved. I can't seem to find the page which suggested transposing the order of the libraries, but there was one, which made me transpose them. Perhaps I should try to find what is adding libpthread then, and remove it. In the short term I'd like to get this working on sqlite-3.5.3. But in the longer term, I would hope that Sage updates to the latest sqlite, so it would need to run on that. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Build problem of sqlite-3.6.14.2 on Solaris 10 with gcc 4.4.0
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, b) libtool is doing things not apparent from the logs that you've posted, 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. 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 -- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Build problem of sqlite-3.6.14.2 on Solaris 10 with gcc 4.4.0
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've no idea if that is a bug in gcc, a bug in libtool or a bug in sqlite. I don't see -lpthread in configure.ac, but I do see this in the output of ./configure: checking whether to support threadsafe operation... yes checking for library containing pthread_create... none required and then the generated Makefile does actually include -lpthread, but only for building the Tcl module, testfixture, and sqlite3_analyzer: ./Makefile:LIBTCL = -L/usr/lib -ltcl8.4 -ldl -lsocket -lnsl -lpthread -lm Very strange. Nico -- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Build problem of sqlite-3.6.14.2 on Solaris 10 with gcc 4.4.0
Dr. David Kirkby wrote: > Dr. David Kirkby wrote: >> Dr. David Kirkby wrote: > > >> >> I just tried to build libtool 1.5.24 (the version of libtool used in >> the latest sqlite release, and noticed that: >> >> 4 of 107 tests failed >> (5 tests were not run) I just realised i done a stupid thing and replied to my own message!!! I thought someone else was confirming the exact same issue! Sorry about that. I'm not quite as mad as I must have seemed. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Build problem of sqlite-3.6.14.2 on Solaris 10 with gcc 4.4.0
Dr. David Kirkby wrote: > Dr. David Kirkby wrote: > > I just tried to build libtool 1.5.24 (the version of libtool used in the > latest sqlite release, and noticed that: > > 4 of 107 tests failed > (5 tests were not run) > Please report to bug-libt...@gnu.org > Yes, there are definite issues with the version of libtool used as part of sqlite. I think it should be updated. At least on Solaris, the current version of libtool passes all but one test. I have reported that one test to them. In version 3.5.3 of sqlite, I think I have identified the problem. This line of code is the route of the error message. gcc -shared .libs/alter.o .libs/analyze.o .libs/attach.o .libs/auth.o .libs/btmutex.o .libs/btree.o .libs/build.o .libs/callback.o .libs/complete.o .libs/date.o .libs/delete.o .libs/expr.o .libs/func.o .libs/hash.o .libs/journal.o .libs/insert.o .libs/loadext.o .libs/main.o .libs/malloc.o .libs/mem1.o .libs/mem2.o .libs/mem3.o .libs/mutex.o .libs/mutex_os2.o .libs/mutex_unix.o .libs/mutex_w32.o .libs/opcodes.o .libs/os.o .libs/os_unix.o .libs/os_win.o .libs/os_os2.o .libs/pager.o .libs/parse.o .libs/pragma.o .libs/prepare.o .libs/printf.o .libs/random.o .libs/select.o .libs/table.o .libs/tokenize.o .libs/trigger.o .libs/update.o .libs/util.o .libs/vacuum.o .libs/vdbe.o .libs/vdbeapi.o .libs/vdbeaux.o .libs/vdbeblob.o .libs/vdbefifo.o .libs/vdbemem.o .libs/where.o .libs/utf.o .libs/legacy.o .libs/vtab.o -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. I've no idea if that is a bug in gcc, a bug in libtool or a bug in sqlite. The same sort of error messages are generated in the latest sqlite, but it's not so easy to see where the problem is. As I said before, if any of the regular sqlite develops could attempt to debug this, I can arrange access to a Sun at the University of Washington. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Build problem of sqlite-3.6.14.2 on Solaris 10 with gcc 4.4.0
i thought I'd copy the output of the config.log too. The message size limit of 40 KB was exceeded when I tried it in a previous attempt to submit this, so hopefully this will be ok. kir...@t2:~/sqlite-3.6.14.2$ more config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by sqlite configure 3.6.14.2, which was generated by GNU Autoconf 2.62. Invocation command line was $ ./configure ## - ## ## Platform. ## ## - ## hostname = t2 uname -m = sun4v uname -r = 5.10 uname -s = SunOS uname -v = Generic_127111-09 /usr/bin/uname -p = sparc /bin/uname -X = System = SunOS Node = t2 Release = 5.10 KernelID = Generic_127111-09 Machine = sun4v BusType = Serial = Users = OEM# = 0 Origin# = 1 NumCPU = 128 /bin/arch = sun4 /usr/bin/arch -k = sun4v /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /home/kirkby/bin PATH: /home/kirkby/dependencies/bin PATH: /usr/bin ## --- ## ## Core tests. ## ## --- ## configure:2092: checking for a BSD-compatible install configure:2160: result: ./install-sh -c configure:2171: checking whether build environment is sane configure:2214: result: yes configure:2276: checking for gawk configure:2306: result: no configure:2276: checking for mawk configure:2306: result: no configure:2276: checking for nawk configure:2292: found /usr/bin/nawk configure:2303: result: nawk configure:2314: checking whether make sets $(MAKE) configure:2336: result: yes configure:2533: checking for style of include used by make configure:2561: result: GNU configure:2634: checking for gcc configure:2650: found /home/kirkby/dependencies/bin/gcc configure:2661: result: gcc configure:2899: checking for C compiler version configure:2907: gcc --version >&5 gcc (GCC) 4.4.0 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2911: $? = 0 configure:2918: gcc -v >&5 Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../gcc-4.4.0/configure --with-gnu-as --with-as=/home/kirkby/bin/as --with-gnu-ld --with-ld=/home/kirkby/bin/ld --with-gmp=/home/kirkby/dependencies/ --with-mpfr=/home/kirkby/dependencies/ --enable-languages=c,c++,fortran --prefix=/home/kirkby/dependencies/ Thread model: posix gcc version 4.4.0 (GCC) configure:2922: $? = 0 configure:2929: gcc -V >&5 gcc: '-V' option must have argument configure:2933: $? = 1 configure:2956: checking for C compiler default output file name configure:2978: gccconftest.c >&5 configure:2982: $? = 0 configure:3020: result: a.out configure:3037: checking whether the C compiler works configure:3047: ./a.out configure:3051: $? = 0 configure:3068: result: yes configure:3075: checking whether we are cross compiling configure:3077: result: no configure:3080: checking for suffix of executables configure:3087: gcc -o conftestconftest.c >&5 configure:3091: $? = 0 configure:3115: result: configure:3121: checking for suffix of object files configure:3147: gcc -c conftest.c >&5 configure:3151: $? = 0 configure:3174: result: o configure:3178: checking whether we are using the GNU C compiler configure:3207: gcc -c conftest.c >&5 configure:3214: $? = 0 configure:3231: result: yes configure:3240: checking whether gcc accepts -g configure:3270: gcc -c -g conftest.c >&5 configure:3277: $? = 0 configure:3378: result: yes configure:3395: checking for gcc option to accept ISO C89 configure:3469: gcc -c -g -O2 conftest.c >&5 configure:3476: $? = 0 configure:3499: result: none needed configure:3519: checking dependency style of gcc configure:3609: result: gcc3 configure:3634: checking for special C compiler options needed for large files configure:3729: result: no configure:3735: checking for _FILE_OFFSET_BITS value needed for large files configure:3770: gcc -c -g -O2 conftest.c >&5 conftest.c:16: warning: left shift count >= width of type conftest.c:16: warning: left shift count >= width of type conftest.c:18: error: size of array 'off_t_is_large' is negative configure:3777: $? = 1 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "sqlite" | #define PACKAGE_TARNAME "sqlite" | #define PACKAGE_VERSION "3.6.14.2" | #define PACKAGE_STRING "sqlite 3.6.14.2" | #define PACKAGE_BUGREPORT "http://www.sqlite.org; | #define PACKAGE "sqlite" | #define VERSION "3.6.14.2" | /* end confdefs.h. */ | #include | /* Check that off_t can represent 2**63 - 1 correctly. | We can't simply define LARGE_OFF_T to be 9223372036854775807, | since some C++ compilers masquerading as C compilers | incorrectly reject 9223372036854775807. */ | #define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) | int
