extension-functions.c - pre-compiled Windows Binary
extension-functions.c (50.96 KB) contributed by Liam Healy on 2010-02-06 15:45:07
Is there a link from which I can download a Windows 32-bit pre-compiled binary?
Why does this question only come from Windows users?
I mean, I get it, you're used to getting binaries for everything, but the rest of the world just gets on with it and builds from source where necessary. It's not ideal, but it's not a show-stopper, either.
20 years ago it was hard to find a C compiler for Windows that was both good and free, but that's changed. For purely-native binaries, your best options are:
The first is GUI, huge, and complicated, and the second is CLI-only, small, and "complicated" only in the sense that you'll have to learn to drive a command line C compiler.
I characterize MinGW like that because this:
C:\> gcc -shared -o extension-functions.dll extension-functions.c
...is 1970s level UI technology, so to call that "complicated" relative to modern environments is rather strange to me.
If you're willing to step out of the purely-native box, then you also have Cygwin and WSL as top-tier offerings.
Why does this question only come from Windows users?
One lifetime is not enough to learn everything!
If Windows users are behind the times (or deficient), providing the binary for just Windows would ensure a bigger reach for extensions; Liam's extension looks to be comprehensive & well worth having.
I just pointed you at the compiler and gave you the command to compile the extension.
(5) By RandomCoder on 2020-09-06 16:42:57 in reply to 2.0 [link] [source]
For those that are trying to follow these directions to build their own copy of extension-functions.dll on a Windows machine, a few things to keep in mind:
You'll need a copy of the sqlite3 sources available. Generally, decompressing the sqlite3 amalgamation and copying the files from the zip file to a working directory alongside extension-functions.c is enough.
Also, speaking of working directories, you'll want to make a working folder to perform your work in. The example above suggests working in the root directory, but that will not work on most modern Windows installations, so make a directory to build in.
The command itself should be:
gcc -shared -o extension-functions.dll extension-functions.c
Note the correct filename extension-functions.c. This is the file you want to build, the extension-functions.dll name is a free form output filename of your choosing. You will use .load on this filename later in the sqlite shell.
And, the original post in this thread mentioned a request for a 32-bit DLL. That's likely the version you want as well, since the version of sqlite3.exe that's available on the SQLite website itself is 32-bit, so I think this is the command you'll want to run:
gcc -m32 -shared -o extension-functions.dll extension-functions.c
(I don't have a Windows machine to test this on to verify it works)
I tried & get this error
extension-functions.c(124): fatal error C1034: sqlite3ext.h: no include path set
RandomCoder told you to unpack a copy of the SQLite amalgamation alongside your extension module.
sqlite3ext.h is in that package.
Why does this question only come from Windows users?
I think it's a simple hole in education that's almost artificially introduced - which is also why so many people love GUI's so much, because they don't know better.
As someone who learned programming on DOS, then Windows OS architectures initially, I can tell you that as a beginner, the tools made it real easy and you almost never had to touch a command-line. (Think Visual Basic, Turbo Pascal, C++, C# etc.)
This of course causes a serious lack of education and a strange avoidance/fear of anything command-line - simply because it is unknown territory. Just give me that "Run" button pls.
Sure enough I had to quickly learn when going to Linux, and as long-term Linux users, slash programmers, I think it is easy for us to forget how much knowledge is locked up in the consoles, shell, Bash, etc. It's like walking - we can all do it so think it easy and intuitive, but for the new human learning it for the first time, it's a daunting task. And let me add, any modern console has a few more things to learn than those that were around when I first started.
Any respectable somewhat professional/accomplished programmer needs to be Console-literate, of course, but I think there is a large swathe of beginner programmers who will have the deficit (and this percentage will probably not become smaller in future), and we need them, cause they will be the accomplished programmers of tomorrow.
So nothing much to do... Just sigh, give the download link for the pre-compiled binaries, and keep posting those command-line examples (as you did) so that those programmers who are emerging from their "n00b" chrysalises into their "1337" butterfly forms can easily find these examples along this formative journey.
(Because if we leave this up to Stackoverflow... God help us all.)
The point in asking for pre-compiled binaries is to ensure that the starting point is common.
If I compiled the source code and encountered aberrant behaviour, it could be EITHER because of how I compiled the source OR because there is an issue with the source. (Responders fall back position becomes How did you compile it?)
If I used a pre-compiled binary and encountered aberrant behaviour, it can only be some issue with the source and the experience would be readily reproducible.
Besides, it seems such as shame that after all the work in producing the source, there is a reluctance in providing pre-compiled binaries therefrom (at least for Windows, since users on other platforms are adept with the command line).
Besides, it seems such as shame that after all the work in producing the source, there is a reluctance in providing pre-compiled binaries therefrom (at least for Windows...
I was with you right up until that statement - which is outright false.
A very prominent position is held right on the SQLite downloads page for pre-compiled binaries for every main Platform - ESPECIALLY Windows which gets the further preferential treatment of having pre-compiled binaries for all of the CLI (sqlite3.exe), the SQLite Analyzer (analyzer.exe) and both the 32-bit and 64-bit DLL's!
Calling this a "reluctance in providing pre-compiled binaries (at least for Windows..." seems an utterly ignorant thing to say. It's very much the opposite.
If your complaint is that some other people are reluctant to make a pre-compiled binary for you based on your spec and/or some specific extension - why should they? Can we wash your car while we at it?
So we might not wish to be your slaves, however, every effort was made in sharing the HOW-TO of compiling so that you can achieve your own build, both from the SQLite website how-to-compile page and on the forum here, where the first reply contained the exact command-line needed for the specific thing that was asked. (Because this post is anonymous I can't tell if you are the same anonymous as the original poster, or a troll, but assuming the former).
PS: There is nothing "common" about the pre-compiled binaries, that's a very Windows-centric way of thinking. Nobody writing SQLite use those as their guiding stars. If you make ANY build in which some code fails, the people here will be happy to hear about it and fix it. That said - Proving a deficit is certainly easier if the pre-compiled SQLite CLI also chokes on it, but again, those are provided directly on the main download page - it couldn't be more un-reluctant.
(11.1) By Richard Hipp (drh) on 2020-09-07 20:44:29 edited from 11.0 in reply to 2.0 [link] [source]
The first is GUI, huge, and complicated,
Edit: I thought I was answering a question about how to compile Fossil, not SQLite. I'm on the wrong forum. Sorry....
I'm sure it has all the GUI bloat in it. But does it not also have the "nmake" and "cl" commands, which are all you really need to do a build? I do the 64-bit windows builds on the website using VS2015. In a command prompt window, I type:
nmake -f Makefile.msc FOSSIL_ENABLE_SSL=1 clean fossil.exe
No GUI ever gets involved. I don't do GUIs. See the Release Build How-To wiki page for details.
Thanks for the tip. The links aren't working for me.
Links work now. But notice also the disclaimer near the top of my post.
does [Visual Studio] not also have the "nmake" and "cl" commands
Yes, the CLI tools are still there, and I expect them to be there in VS2020 as well.
My problem with it is that I only run Windows in VMs these days, and then rarely, which means the typical 20-50 GB installation size chews up a tremendous amount of space, compared to what I'd normally consider a reasonable VM size. Indeed, most of my VMs are well under 20 GB total! When the host has a "big" 1 TB SSD, a 100 GB VM is rather costly.
On top of that, the last time I installed VS into a VM, it took like 2 hours to set up.
This brings me to my point in making that comment to the OP. He seems like a "just install the GUI and double-click things until it works" sort, so I felt the need to warn him that installing MinGW is actually the low-friction path, all things considered.
Actually, you do not need the clickety-pokey at all. You can simply install the (Visual Studio) C/C++ Build Tools (which are free) and only a few GB (as in 2 or 3)(mostly for the SDK) and installs in seconds (maybe minutes if you have a slow computer).
For MinGW you do not even need to do that. Just download the installation zip and unzip and put the bin directory in the path. Some versions of GCC may require more farting about than others depending on who built it -- for example the GCC 9.1.0 build has some stipulations on directory naming and some fiddling because of the way it was built.
(This is a response from an anonymous user which i inadvertently moderated away and then restored from the email notification about it...)
Here's an interesting alternative: Zig as a C Compiler. Extract below from that link:
An alternative to installing MSVC on Windows
You could spend days - literally! - waiting for Microsoft Visual Studio to install, or you could install Zig and VS Code in a matter of minutes.
And below's what I got when reloading the page with my post awaiting moderation, after you've moderated it away...
/forumpost: Unknown or ambiguous forum id: "6d5eb2fddb" uid=33, gid=33 g.zBaseURL = https://sqlite.org/forum g.zHttpsURL = https://sqlite.org/forum g.zTop = /forum g.zPath = forumpost g.userUid = 3 g.zLogin = g.isHuman = 1 capabilities = ghjo237 anonymous-adds = g.zRepositoryName = /fossil/sqlite-forum.fossil load_average() = 0.340000 cgi_csrf_safe(0) = 1 fossil_exe_id() = 28201ea88552f43964a7f07875834798 DOCUMENT_ROOT = /default.website GATEWAY_INTERFACE = CGI/1.0 HTTPS = on HTTP_ACCEPT = text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 HTTP_ACCEPT_ENCODING = gzip, deflate, br HTTP_HOST = sqlite.org HTTP_REFERER = https://sqlite.org/forum/forume2 HTTP_USER_AGENT = Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 PATH_INFO = /forumpost/6d5eb2fddb QUERY_STRING = REMOTE_ADDR = 18.104.22.168 REMOTE_HOST = ::ffff:22.214.171.124 REMOTE_PORT = 51190 REQUEST_METHOD = GET REQUEST_URI = /forum/forumpost/6d5eb2fddb SCRIPT_FILENAME = /default.website/forum SCRIPT_NAME = /forum SERVER_PROTOCOL = HTTP/1.1 name = 6d5eb2fddb This page was generated in about 0.003s by Fossil 2.13 [5c90832d79] 2020-09-06 14:49:24
Yes: a moderator's rejection removes an artifact marked as "private" from the repository, so that continuing to refer to it gives this error. See the docs for more info on how Fossil forum moderation works.
Most of the info on that page is meant to help the repo admin to work out what happened, but here it's quite clear without the detail.
So there's zero audit-trail on moderation?
As in, one cannot recover the original post, to moderate the moderators?
So there's zero audit-trail on moderation?
There is, but you have to be a repo admin to see it, since it exposes the IPs of users, which is considered PII in some jurisdictions.
one cannot recover the original post
All of us moderators get a copy.
And because of that, I can tell you that Stephan's right: your original post's Markdown was malformed.
For what it's worth, I almost rejected your post myself, since it's basically an ad for a niche toolchain which isn't likely to help this thread's OP. It's quite a stretch to consider it an on-topic post, IMO.
to moderate the moderators?
That's why Fossil has Setup and Admin users above moderators. If you distrust drh to do that here, then I wonder why you're running his software on your computer?
That result is expected - the artifact is no longer in the repository at that point.
It was moderated away because the link you provided went to nowhere and the text below it added nothing to the conversation without that link. After moderating the message away i noticed, in the unparsed email notification, that the link was valid but your markdown syntax was not, making it parse like an invalid link. That syntax was corrected when reposting your response.
The syntax I used was displaying correctly in Preview mode,
so either you're mistaken, and there's a bug in Preview...
On the contrary, you didn't test the link in preview mode. It used a parenthesis around the number instead of square brackets. That was interpreted as a link to forum post with id 1, which does not exist. My re-post changed that to square brackets.
Hmmm, I think I see what you mean now.
It showed up as an HTML link in Preview, never in a million miles would have
thought that was some kind of internal linking kicked-in, instead of the URL
I posted which had a full/absolute
So my mistake on the syntax, and somewhat surprising from my POV, for preview.
Hello Richard !
Related to this I usually add some extensions by default on the sqlite3 amalagamation and I need to manually edit src/shell.c.in, src/main.c and others would be nice if the extensions define a preprocessor macro that can be tested to not include then more than once, so people that create custom amalgamations do not need to do hacks to prevent double inclusion/definitions and still be able to use the standard build of sqlite3.
(18.1) By Warren Young (wyoung) on 2020-09-08 11:38:48 edited from 18.0 in reply to 16 [link] [source]
You shouldn't edit the amalgamation at all.
Instead, clone the Fossil repository, make your edits to a local working copy, then commit the change to a local branch. Since you don't have commit rights on the official repository, they won't autosync, so you don't need to mess with private branches. Since they're on a branch, you can then pull upstream changes and merge them into your branch, effectively reapplying your local edits in a single step.
Here's the distilled workflow:
$ mkdir -p ~/src/sqlite/my-branch $ cd ~/src/sqlite/my-branch $ fossil open https://sqlite.org/src ...make your local edits to src/*.c... $ ./configure --with-chosen-opts # one time only $ make sqlite3.c # build new amalgamation w/your edits ...test it... $ fossil set autosync pullonly # once; squishes an annoying warning $ fossil ci --branch my-branch -m 'initial version of my branch'
This may look a bit complicated, but most of that is one-time-only stuff which doesn't need to be repeated when a new version of SQLite comes out that you want to merge your local changes into:
$ cd ~/src/sqlite/my-branch $ fossil merge trunk # implicit update due to autosync $ make sqlite3.c ...retest that your changes still work atop the new trunk... $ fossil ci -m 'updated to latest trunk'
It's as simple as it could be now: pull upstream changes, tell Fossil to automatically merge them with your branch's changes, and rebuild the new amalgamation from the combination.