Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
Which problem did you experience on SPARC? It is a nearly impossible process. Can not be done unless you have a very specific class of hardware. Really? SQLite3 builds quite happily on the various SPARC S8 ... Can we stop talking about historical hardware? I have Apache httpd running neatly on new shiney Oracle M-class hardware. The point is Solaris 11.4 and Oracle Studio. Nothing else. Dennis Clarke ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
On 20/01/2019 15:03, Dennis Clarke wrote: On 1/19/19 10:55 AM, Igor Korot wrote: Dennis, On Sat, Jan 19, 2019 at 9:31 PM Dennis Clarke wrote: And SPARC version is still available for download... Let us know when you get that running. Install of x86 went very smooth. The x86_64 process is trivial. And I was able to compile fairly recent SQLite with Oracle Studio 12.6 with just couple of warnings... Which problem did you experience on SPARC? It is a nearly impossible process. Can not be done unless you have a very specific class of hardware. Really? SQLite3 builds quite happily on the various SPARC S8 systems we keep alive, because, customers, and on the S8 Zone on the T1000 running S10. (I have the zone (and an S9 zone) because keeping old hardware alive is a worry.) (Not using Studio 12.6, of course :-) ) Cheers, GaryB-) ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
On 1/20/19 12:50 AM, Gary R. Schmidt wrote: On 20/01/2019 15:03, Dennis Clarke wrote: On 1/19/19 10:55 AM, Igor Korot wrote: Dennis, On Sat, Jan 19, 2019 at 9:31 PM Dennis Clarke wrote: And SPARC version is still available for download... Let us know when you get that running. Install of x86 went very smooth. The x86_64 process is trivial. And I was able to compile fairly recent SQLite with Oracle Studio 12.6 with just couple of warnings... Which problem did you experience on SPARC? It is a nearly impossible process. Can not be done unless you have a very specific class of hardware. Really? We are talking about Solaris 11.4 and not ye old Solaris 10 or other historical artifacts. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
On 20/01/2019 15:03, Dennis Clarke wrote: On 1/19/19 10:55 AM, Igor Korot wrote: Dennis, On Sat, Jan 19, 2019 at 9:31 PM Dennis Clarke wrote: And SPARC version is still available for download... Let us know when you get that running. Install of x86 went very smooth. The x86_64 process is trivial. And I was able to compile fairly recent SQLite with Oracle Studio 12.6 with just couple of warnings... Which problem did you experience on SPARC? It is a nearly impossible process. Can not be done unless you have a very specific class of hardware. Really? SQLite3 builds quite happily on the various SPARC S8 systems we keep alive, because, customers, and on the S8 Zone on the T1000 running S10. (I have the zone (and an S9 zone) because keeping old hardware alive is a worry.) (Not using Studio 12.6, of course :-) ) Cheers, GaryB-) ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
On 1/19/19 10:55 AM, Igor Korot wrote: Dennis, On Sat, Jan 19, 2019 at 9:31 PM Dennis Clarke wrote: And SPARC version is still available for download... Let us know when you get that running. Install of x86 went very smooth. The x86_64 process is trivial. And I was able to compile fairly recent SQLite with Oracle Studio 12.6 with just couple of warnings... Which problem did you experience on SPARC? It is a nearly impossible process. Can not be done unless you have a very specific class of hardware. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
Dennis, On Sat, Jan 19, 2019 at 9:31 PM Dennis Clarke wrote: > > > > And SPARC version is still available for download... > > Let us know when you get that running. Install of x86 went very smooth. And I was able to compile fairly recent SQLite with Oracle Studio 12.6 with just couple of warnings... Which problem did you experience on SPARC? Thank you. > > Dennis > > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
And SPARC version is still available for download... Let us know when you get that running. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
Dennis Clarke wrote: > On 1/19/19 4:47 PM, Andy Goth wrote: >> Dennis Clarke wrote: >>> On 2018-07-28 08:33, Andy Goth wrote: SQLite 3.24.0 fails to build on Solaris 9 (a.k.a. Solaris 2.9) >> >>> It may be [worth] while to spin up a Solaris 9 zone on a Solaris 10 >>> or Solaris 11 server for this purpose. >> >> I don't have access to any Solaris servers of any kind. And yet, I had >> the requirement to produce a working binary for a computer I wasn't >> even allowed to go visit. It was rough, but the task is done and sold off. > > From the better late than never file eh? Haha yeah, late last year I noticed my patch never made it into official SQLite and resolved to check up on its status, but I got busy again. Though today I found a bit of free time since I was going to pour a concrete slab and yet my cement mixer hasn't been returned to me yet. And so I'm catching up. > I have no idea how you managed to land that task but these days if > someone asks me to do any work on a Solaris 8 or 9 server I simply say > "no" and that is the end of it. I have seen too many nights and days > lost to cursing over old Solaris 8 sparc servers. No one knew Solaris was in the mix. It was the OS chosen by a vendor who eons ago sold our predecessors an appliance we just plugged in and tried to not think about too much. When I was given the task, people were thinking exclusively Linux, but over the course of development I discovered it was necessary for my software to work on (or with) a much wider variety of systems dating back to Windows 98. A few (such as VxWorks) I was able to query over the network without having to run my code on them directly, and some others I was able to handwave away because the only way to identify the software configuration was to unscrew a panel and read the version number off the sticker on a PROM. But most of the time I had to actually install and run my code right on the box. That wasn't really all that difficult, since I wrote my code in Tcl to begin with. So all that was necessary was to build the Tcl interpreter, along with the right set of extensions, into basekits which I combined with scripts and data files to produce single-file executables known as Starpacks. Thus, I made a Linux VM with cross compilers for all target platforms, then I compiled the basekits, and I used and/or wrote Tcl scripts to combine the basekits with application scripts into the Starpacks. Because the basekits themselves are Tcl interpreters, and I had them built for all platforms, I was thus able to use any platform to "build" for every platform. It was a thing of beauty, and Fossil was the cherry on the top. Incidentally, limited understanding of system configurations is the whole reason the task came to be in the first place. Now that's all solved, but there were many lessons learned along the way. The funny thing is I'm not even using SQLite in this application! It's just part of my standard basekit. Since one of the systems I had to support was Red Hat 9, I first used an RH9 VM to compile for it, but the included version of GCC was buggy beyond belief. The SQLite binaries it produced would sometimes give SQLITE_MISUSE (or some similar issue) when I tried to UPDATE a table from within Tcl. So I grudgingly decided to not use SQLite, on account of one broken platform. By the time I set up a better cross compiler that didn't output trash, I had gone too far down an alternate design path to be willing to rearchitect in terms of SQLite. I may yet do so in a follow-on project now that SQLite is available to me. > I have a few Solaris 10 servers left in life and zero, none, nothing for > Solaris 11 simply because Oracle made it impossible to run. > > So well done and now do your self a favour and say good bye to it. > > Time to go look at Debian and FreeBSD on RISC-V if you want adventure! I don't anticipate ever needing to support Solaris again, but if it does crop up, at least I'm prepared. Specifically, I know how to make a cross compiler for it so that I don't have to touch it daily in order to do my development. However, for some strange reason, I've been thinking about MS-DOS lately... --- CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
Hi, On Sat, Jan 19, 2019 at 4:29 PM Dennis Clarke wrote: > > On 1/19/19 4:47 PM, Andy Goth wrote: > > Dennis Clarke wrote: > >> On 2018-07-28 08:33, Andy Goth wrote: > >>> SQLite 3.24.0 fails to build on Solaris 9 (a.k.a. Solaris 2.9) > > > >> It may be [worth] while to spin up a Solaris 9 zone on a Solaris 10 or > >> Solaris 11 server for this purpose. > > > > I don't have access to any Solaris servers of any kind. And yet, I had the > > requirement to produce a working binary for a computer I wasn't even > > allowed to go visit. It was rough, but the task is done and sold off. > > From the better late than never file eh? > > I have no idea how you managed to land that task but these days > if someone asks me to do any work on a Solaris 8 or 9 server I > simply say "no" and that is the end of it. I have seen too many > nights and days lost to cursing over old Solaris 8 sparc servers. > > I have a few Solaris 10 servers left in life and zero, none, nothing > for Solaris 11 simply because Oracle made it impossible to run. Well I don't know. I successfully installed 11.4 on x86 architecture. And SPARC version is still available for download... Thank you. > > So well done and now do your self a favour and say good bye to it. > > Time to go look at Debian and FreeBSD on RISC-V if you want adventure! > > Dennis > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
On 1/19/19 4:47 PM, Andy Goth wrote: Dennis Clarke wrote: On 2018-07-28 08:33, Andy Goth wrote: SQLite 3.24.0 fails to build on Solaris 9 (a.k.a. Solaris 2.9) It may be [worth] while to spin up a Solaris 9 zone on a Solaris 10 or Solaris 11 server for this purpose. I don't have access to any Solaris servers of any kind. And yet, I had the requirement to produce a working binary for a computer I wasn't even allowed to go visit. It was rough, but the task is done and sold off. From the better late than never file eh? I have no idea how you managed to land that task but these days if someone asks me to do any work on a Solaris 8 or 9 server I simply say "no" and that is the end of it. I have seen too many nights and days lost to cursing over old Solaris 8 sparc servers. I have a few Solaris 10 servers left in life and zero, none, nothing for Solaris 11 simply because Oracle made it impossible to run. So well done and now do your self a favour and say good bye to it. Time to go look at Debian and FreeBSD on RISC-V if you want adventure! Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
Dennis Clarke wrote:
> On 2018-07-28 08:33, Andy Goth wrote:
>> SQLite 3.24.0 fails to build on Solaris 9 (a.k.a. Solaris 2.9)
> It may be [worth] while to spin up a Solaris 9 zone on a Solaris 10 or
> Solaris 11 server for this purpose.
I don't have access to any Solaris servers of any kind. And yet, I had the
requirement to produce a working binary for a computer I wasn't even
allowed to go visit. It was rough, but the task is done and sold off.
By the way, I've come to find out that the system in question is actually
Solaris 8, but I have to call it 9 because GCC doesn't support 8. What a
mess. I'm glad it's behind me.
> Not sure how you are getting a cross compile to work at all with just
> /usr/include on hand. Are you using the Sun Studio compilers for this ?
I'm using GCC.
When I said I had only /usr/include, I oversimplified. I have the following:
/lib (symlink to usr/lib)
/usr/include
/usr/lib
/usr/ccs/lib
/usr/local/include
/usr/local/lib
/usr/openwin/include
/usr/openwin/lib
/usr/dt/include
/usr/dt/lib
My notes say I have the next two directories as well, but my notes are
wrong:
/usr/X11/include
/usr/X11/lib
The above is all stored in a file called pkg/solaris-sysroot.tar.
Here's how I built my cross compiler:
TARGET=sparc-sun-solaris2.9 &&
tar xf pkg/binutils-2.31.tar.xz &&
tar xf pkg/gcc-4.9.4.tar.bz2 &&
sudo mkdir -p /opt/cross/sysroot/$TARGET &&
sudo tar -xf pkg/solaris-sysroot.tar -C /opt/cross/sysroot/$TARGET &&
mkdir build-binutils build-gcc &&
cd build-binutils &&
../binutils-2.31/configure -v --target=$TARGET --prefix=/opt/cross \
--with-sysroot=/opt/cross/sysroot/$TARGET &&
make -j2 &&
sudo make install &&
cd ../build-gcc &&
../gcc-4.9.4/configure -v --target=$TARGET --prefix=/opt/cross \
--with-sysroot=/opt/cross/sysroot/$TARGET \
--with-gnu-as --with-gnu-ld \
--disable-libgcj \
--enable-languages=c,c++ --enable-obsolete &&
make -j2 &&
sudo make install &&
cd .. &&
rm -rf build-binutils build-gcc
I then built SQLite in the context of building a Tclkit basekit, and I did
that using the KitCreator script. Here are the commands relevant to SQLite:
[...]
rm -rf tcl/buildsrc/tcl8.6.9/pkgs/sqlite3.25.3 &&
tar xf ../pkg/sqlite-autoconf-326.tar.gz \
sqlite-autoconf-326/{tea,sqlite3.{c,h}} &&
patch -d sqlite-autoconf-326 -p1 < ../pkg/sqlite-sunos.diff &&
mv sqlite-autoconf-326/tea tcl/buildsrc/tcl8.6.9/pkgs/sqlite3.26.0 &&
mv sqlite-autoconf-326/sqlite3.[ch] \
tcl/buildsrc/tcl8.6.9/pkgs/sqlite3.26.0/generic &&
rm -rf sqlite-autoconf-326 &&
[...]
export CFLAGS=-Os CXXFLAGS=-Os
CFLAGS=-O0 CXXFLAGS=-O0 KITCREATOR_PKGS=mk4tcl ./kitcreator &&
mv tclkit-8.6.9 tclkit-local &&
export TCLKIT=$PWD/tclkit-local
TARGET=sparc-sun-solaris2.9 &&
CC=/opt/cross/bin/$TARGET-gcc \
CXX=/opt/cross/bin/$TARGET-g++ \
AR=/opt/cross/bin/$TARGET-ar \
RANLIB=/opt/cross/bin/$TARGET-ranlib \
STRIP=/opt/cross/bin/$TARGET-strip \
KITCREATOR_PKGS="itcl mk4tcl tdom tnc" \
./kitcreator --host=$TARGET &&
mv tclkit-8.6.9 ../tclkit-sunos
The file "sqlite-sunos.diff" is the patch I outlined in my first email:
https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg111233.html
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
On 07/30/2018 03:59 AM, Gary R. Schmidt wrote: On 2018-07-28 08:33, Andy Goth wrote: SQLite 3.24.0 fails to build on Solaris 9 (a.k.a. Solaris 2.9) It may be work while to spin up a Solaris 9 zone on a Solaris 10 or Solaris 11 server for this purpose. Not sure how you are getting a cross compile to work at all with just /usr/include on hand. Are you using the Sun Studio compilers for this ? Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
On 2018-07-28 08:33, Andy Goth wrote: SQLite 3.24.0 fails to build on Solaris 9 (a.k.a. Solaris 2.9) due to not finding fchmod, fchown, readlink, lstat, usleep, struct timeval, and gettimeofday. To correct, do not #define _XOPEN_SOURCE. There's already a check for Mac OS X, so I would suggest extending the check to also exclude Solaris 9 with something like the following: #if !defined(_XOPEN_SOURCE) && !defined(__DARWIN__) && !defined(__APPLE) && \ !(defined(__sun) && defined(__SVR4)) # define _XOPEN_SOURCE 600 #endif This check isn't version-specific. There doesn't appear to be a guaranteed macro for that purpose. Sun Studio offers macros like _SunOS_5_9 (meaning Solaris 9), but gcc does not. Though it's a bit silly for me to obsess over versions since I don't know exactly which versions of Solaris hide the relevant functions and structs if _XOPEN_SOURCE is defined. I only have access to Solaris 9, and by "access" I mean I have a copy of /usr/include and such, not a computer I can log in to. Just enough to do a cross-compile, which succeeds with the above change. More investigation is needed to figure out how to make SQLite build for Solaris 9 without breaking other Solaris/SunOS platforms. For some time at $ORK I have been configuring with "--disable-readline"[1] and inserting the following lines into sqlite3.c as provided in the autoconf archive. I don't recall which UNIX variant caused the need, or when, but the changes are applied across all my Linux and UNIX builds now. #include #include #include These changes, plus updating libz to a newer version, builds happily on Solaris 8, 9, 10, and 11. As well as HP-UX 11.x and AIX 5.x to 7.x. Cheers, GaryB-) 1 - Yes, we could supply readline(), but $ORK decided not to do so before I arrived. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] SQLite 3.24.0 Solaris 9 build failure
SQLite 3.24.0 fails to build on Solaris 9 (a.k.a. Solaris 2.9) due to not finding fchmod, fchown, readlink, lstat, usleep, struct timeval, and gettimeofday. To correct, do not #define _XOPEN_SOURCE. There's already a check for Mac OS X, so I would suggest extending the check to also exclude Solaris 9 with something like the following: #if !defined(_XOPEN_SOURCE) && !defined(__DARWIN__) && !defined(__APPLE) && \ !(defined(__sun) && defined(__SVR4)) # define _XOPEN_SOURCE 600 #endif This check isn't version-specific. There doesn't appear to be a guaranteed macro for that purpose. Sun Studio offers macros like _SunOS_5_9 (meaning Solaris 9), but gcc does not. Though it's a bit silly for me to obsess over versions since I don't know exactly which versions of Solaris hide the relevant functions and structs if _XOPEN_SOURCE is defined. I only have access to Solaris 9, and by "access" I mean I have a copy of /usr/include and such, not a computer I can log in to. Just enough to do a cross-compile, which succeeds with the above change. More investigation is needed to figure out how to make SQLite build for Solaris 9 without breaking other Solaris/SunOS platforms. -- Andy Goth | ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
