RE: Creating the sqlite3.exe stand-alone w/o cygwin dependency
On Saturday, December 10, 2022 1:01 PM, Jose Isaias Cabrera expressed: > > These reported DLL are in the search path, and also moving these to the > executable > folder still gives the same error. I also moved the sqlite3.exe file from the > built > folder to the previous folder in the Cygwin environment, and the same problem > happens: Just to put this to rest, and I am sure that there is a way of doing this using i686-w64-mingw32, but the only way that it appears to work is just doing plain ./configure and make. ./configure make And then doing these commands: To create the DLL: i686-w64-mingw32-gcc -shared -static-libgcc sqlite3.c -o sqlite3.dll To create the CLI tool: i686-w64-mingw32-gcc -static-libgcc shell.c -o sqlite3.exe sqlite3.c Both sqlite3.dll and sqlite3.exe CLI tool will work outside the cygwin environment. Just in case someone ever needs this. Thanks for all the support. josé -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] cygwin 3.4.1-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.4.1-1 * cygwin-devel-3.4.1-1 * cygwin-doc-3.4.1-1 This is a bugfix release. - Fix a backward incompatibility problem in the definition of the base type of the stdio type FILE. This requires that C++ binaries compiled under Cygwin 3.4.0 having a public facing interface using FILE need to be recompiled. Addresses: https://savannah.gnu.org/bugs/index.php?63480 - Fix an error introduced into the build process, resulting in `gcc -pg' becoming disfunctional. Addresses: https://cygwin.com/pipermail/cygwin/2022-December/252619.html - Fix performance degradation of non-cygwin pipe. Addresses: https://cygwin.com/pipermail/cygwin/2022-December/252628.html == IMPORTANT DEPRECATION NOTES == - Cygwin 3.4 is the FIRST major version dropping support for - 32 bit Windows including WOW64 on 64 bit Windows. - Windows Vista - Windows Server 2008 - Cygwin 3.4 is the LAST major version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 - Cygwin 3.5, which will probably be release at some point in late 2023, will run on - Windows 8.1 - Windows 10 - Windows 11 - Windows Server 2012 R2 - Windows Server 2016 - Windows Server 2019 - Windows Server 2022 There are no plans to deprecate support for 64 bit systems starting with Windows 8.1 / Windows Server 2012 R2 any time soon. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
cygwin 3.4.1-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.4.1-1 * cygwin-devel-3.4.1-1 * cygwin-doc-3.4.1-1 This is a bugfix release. - Fix a backward incompatibility problem in the definition of the base type of the stdio type FILE. This requires that C++ binaries compiled under Cygwin 3.4.0 having a public facing interface using FILE need to be recompiled. Addresses: https://savannah.gnu.org/bugs/index.php?63480 - Fix an error introduced into the build process, resulting in `gcc -pg' becoming disfunctional. Addresses: https://cygwin.com/pipermail/cygwin/2022-December/252619.html - Fix performance degradation of non-cygwin pipe. Addresses: https://cygwin.com/pipermail/cygwin/2022-December/252628.html == IMPORTANT DEPRECATION NOTES == - Cygwin 3.4 is the FIRST major version dropping support for - 32 bit Windows including WOW64 on 64 bit Windows. - Windows Vista - Windows Server 2008 - Cygwin 3.4 is the LAST major version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 - Cygwin 3.5, which will probably be release at some point in late 2023, will run on - Windows 8.1 - Windows 10 - Windows 11 - Windows Server 2012 R2 - Windows Server 2016 - Windows Server 2019 - Windows Server 2022 There are no plans to deprecate support for 64 bit systems starting with Windows 8.1 / Windows Server 2012 R2 any time soon.
RE: Creating the sqlite3.exe stand-alone w/o cygwin dependency
On December 10, 2022 10:20 AM, Michael Soegtrop expressed: > > > The problem happens after I move that sqlite3.exe to C:\bin directory. > > very likely quite a few of the MinGW shared libraries supplied by cygwin are > missing - you need to copy these as well. You can use the `ldd` tool on the Very interesting: $ ldd sqlite3.exe ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7ffc1d6f) ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x778c) wow64.dll => /cygdrive/c/Windows/System32/wow64.dll (0x7ffc1c83) wow64win.dll => /cygdrive/c/Windows/System32/wow64win.dll (0x7ffc1d54) Why are there two ntdll.dll files? Never mind. :-) These reported DLL are in the search path, and also moving these to the executable folder still gives the same error. I also moved the sqlite3.exe file from the built folder to the previous folder in the Cygwin environment, and the same problem happens: jcabrera@JIC ~/build/sqlite/SQLite-060eb284 $ mv sqlite3.exe .. jcabrera@JIC ~/build/sqlite/SQLite-060eb284 $ cd .. jcabrera@JIC ~/build/sqlite $ ./sqlite3 jcabrera@JIC ~/build/sqlite $ ./sqlite3.exe jcabrera@JIC ~/build/sqlite Well, let's say that nothing happens. So, it's something to do with the built command that only allows the sqlite3.exe to be run in the folder built folder and no-where else. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: Creating the sqlite3.exe stand-alone w/o cygwin dependency
On December 10, 2022 9:48 AM, Eliot Moss expressed: > > On 12/9/2022 9:43 PM, Jose Isaias Cabrera wrote: > > > > On Friday, December 9, 2022 6:33 PM, Eliot Moss expressed: > >> > >> On 12/9/2022 4:34 PM, Jose Isaias Cabrera via Cygwin wrote: > >> > >> This is a bit of a shot in the dark, but I wonder about search paths > >> and find the DLL when trying to start the program. Is the necessary > >> directory on the search path available to Windows and/or passed to > >> the sqlite3 executable as an environment variable? > > > > Thanks, Eliot. I have placed the sqlite3.dll in the same folder of the > > executable, but, it does not work either. I don't think is the > > sqlite3.dll that is looking for. It's probably some of the Cygwin > > libraries. > > > > Any thoughts where I can get help? > > This list continue to be a place. > > I still wonder if there is some path issue. Just because the dll is in > the same directory does not mean that Windows will look there if . (the > current directory) is not on your path. As I recall (and I hope someone > will correct me!) the relevant environment variable is PATH, but it may > be a different one for finding dlls. (I'm sure someone on the list can > clarify that point!) I can tell you that in Windows 10 the search path is the live directory first (.), then the path. But, again, I don't think it's the DLL, because this application does not use the sqlite3.dll or needs it. It's a stand-alone application. It has all it needs inside. For example, if I download the Windows Tool from the Sqlite page, I can place it anywhere in the computer and it will run without anything else. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Creating the sqlite3.exe stand-alone w/o cygwin dependency
Actually if the dlls is in the same directory it does mean that windows will look there even if the current directory is not in your path (always true if the executable is in the same location, only true if safe dll search is off) given that windows has not found the dll registered in the system in any other place and there are no overrides anywhere else. The search goes in this order: If the dll is already in memory, this is used. If the dll is in the list of known dlls versions it is loaded from there (list of dlls is at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs) If it is not found in any of those locations then it is searched Finally dependencies are resolved using this steps as well If dll has not been found and it is not overridden by a full path definition nor a manifest then the search goes as follow Directory from which the application was loaded If safe dll search mode is disabled then the current directory is searched The system directory - starting with the current arch, then fallbacks to previous archs The windows directory And finally all the path environment variable Hopes this helps a little bit. Reference: https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order Best regards - Cristobal E -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Creating the sqlite3.exe stand-alone w/o cygwin dependency
> The problem happens after I move that sqlite3.exe to C:\bin directory. very likely quite a few of the MinGW shared libraries supplied by cygwin are missing - you need to copy these as well. You can use the `ldd` tool on the .exe and the .dll to find out which these are. You need to copy sqlite.dll and all MinGW shared libraries required by both to the bin folder. A typical example is the C runtime shared library- I have no idea about sqlite, but I maintain a project which compiles MinGW executables using shared libraries and create relocatable installers from that. The shell script which finds the shared library dependencies is here: https://github.com/coq/platform/blob/cb1646593beb42629d660e22323a3fe9e3779435/windows/create_installer_windows.sh#L107 It should explain how to do this. Best regards, Michael -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Creating the sqlite3.exe stand-alone w/o cygwin dependency
On 12/9/2022 9:43 PM, Jose Isaias Cabrera wrote: On Friday, December 9, 2022 6:33 PM, Eliot Moss expressed: On 12/9/2022 4:34 PM, Jose Isaias Cabrera via Cygwin wrote: This is a bit of a shot in the dark, but I wonder about search paths and find the DLL when trying to start the program. Is the necessary directory on the search path available to Windows and/or passed to the sqlite3 executable as an environment variable? Thanks, Eliot. I have placed the sqlite3.dll in the same folder of the executable, but, it does not work either. I don't think is the sqlite3.dll that is looking for. It's probably some of the Cygwin libraries. Any thoughts where I can get help? This list continue to be a place. I still wonder if there is some path issue. Just because the dll is in the same directory does not mean that Windows will look there if . (the current directory) is not on your path. As I recall (and I hope someone will correct me!) the relevant environment variable is PATH, but it may be a different one for finding dlls. (I'm sure someone on the list can clarify that point!) Best - Eliot Moss -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Creating the sqlite3.exe stand-alone w/o cygwin dependency
On 12/9/2022 4:34 PM, Jose Isaias Cabrera via Cygwin wrote: Greetings! Using these commands, ./configure --host=i686-w64-mingw32 CFLAGS=-shared CFLAGS=-static-libgcc make sqlite3.exe sqlite3.dll I can create the sqlite3 DOS application and the sqlite3 Windows 10 DLL. I have no problem with the DLL. But with the sqlite3.exe CLI tool, I can run it in the Cygwin environment, and I can also double click on the app from the Windows 10 environment and run it, and that also works perfectly. The problem happens after I move that sqlite3.exe to C:\bin directory. When I run it from the DOS Command Prompt, I get this error: DOS|16:19:00.58>sqlite3 DOS|sqlite3: FATAL: Couldn't find sqlite3. If I add .exe to the end, DOS|16:19:57.46>sqlite3.exe DOS| DOS|16:21:33.36> It appears as if it starts and does nothing. I tried chatting with SQLite folks, but, apparently, I am the only one that uses Cygwin. I have been using Cygwin for a long time, and I like it. Thoughts? Suggestions? Any help would be greatly appreciated. PS: This is the make sqlite.exe run: E608313@HOR711318E ~/b/sqlite/SQLite-78723a9a $ make sqlite3.exe ./libtool --mode=link i686-w64-mingw32-gcc -shared -static-libgcc -DSQLITE_OS_WIN=1 -I. -I/home/E608313 I don't know if this is the problem, but do you really want to be using '-shared' when building an executable? I thought that was for building shared libraries. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
You are being denied of access this is your nite for use in any court case in the future
Fraudulent unauthorized .Aka Satoshi nakamoto -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
