SqLite header and source version mismatch for sqlite3 - sqlite

I am searching for a way to get rid of the error message
SqLite header and source version mismatch 2016-04-08 15:09:49
fe7d3b75fe1bde41511b323925af8ae1b910bc4d 2015-07-29 20:00:57
cf538e2783e468bbc25e7cb2a9ee64d3e0e80b2f
when ,e.g., typing in sqlite3. I had to check a python script, using SQLite. I had to overwrite the libsqlite.so in my folder /usr/lib/x86_64-linux-gnu/ due to a project specific libsqlite.so-file.
But older files libsqlite3.la, libsqlite3.so.0 and libsqlite3.so.0.8.6 remained unchanged.
My folder /usr/local/lib does not contain any sqlite files. I found this hint to change the source_id in the .c- and .h-file:
https://forum.ubuntuusers.de/topic/header-and-source-version-mismatch-bei-sqlite3/2/
I did this for the file sqlite3.h, but the file sqlite3.c is also missing.
Any other suggestions how I can fix this annoying problem?
Update:
After deleting and re-installing sqlite3 and libsqlite3-dev, I am receiving the same error message. The delete process also included the deletion of the file libsqlite3.so, that was substituted by the use case specific libsqlite3.so.
I also deleted the files libsqlite3.so.0 and libsqlite3.so.0.8.6 in the folder /usr/lib/x86_64-linux-gnu/. This leads to the error message:
sqlite3: error while loading shared libraries: libsqlite3.so.0: cannot open > shared object file: No such file or directory
Kind regards

If you don't want to use the SQLite version that happens to be shipped with your distribution, put all the source files (sqlite3.h and sqlite3.c of the "amalgamation") of the desired version into your project, just like any other source file.

Related

call gRPCTargets.cmake can't found libgpr.so

I import grpc project use gRPCConfig.cmake file. But the following error occurred
CMake Error at /home/openwrt/openwrt/staging_dir/target-arm_cortex-a53+neon-vfpv4_glibc-2.22_eabi/usr/lib/cmake/grpc/gRPCTargets.cmake:178 (message):
The imported target "gRPC::gpr" references the file
"/usr/lib/libgpr.so"
but this file does not exist. Possible reasons include:
The file was deleted, renamed, or moved to another location.
An install or uninstall procedure did not complete successfully.
The installation package was faulty and contained
/home/openwrt/openwrt/staging_dir/target-arm_cortex-a53+neon-vfpv4_glibc-2.22_eabi/usr/lib/cmake/grpc/gRPCTargets.cmake
but not all the files it references.

missing .dependencies in user/ when bin/grav

I'm trying to install Grav on Heroku following the learn.getgrav.org docs.
I've got the web app deployed successfully, however it tells me to bin/grav install.
I do that and it gives me the following output:
ERROR Missing .dependencies file in user/ folder
I do not know what to do at this point as it's happened everytime I've installed Grav.
Hope this will be solved.
Sadly this problem is all too common when copying files :(
hidden (dotted) files are not always copied.
.dependencies
.htaccss
using ls -l -a in the folder where you extracted the files originally Dowloads/grav I could see the files that were not copied to fix it
cp .dependencies .htaccss /var/www/grav/
When I install GRAV on my server each time, I always copy the Zip file to the server, unzip it in place, then remove the zip file - using this method I have never had a problem with the installing of GRAV
HTH Rich

Accidentally deleted status.cgi in my nagios cgi folder

Can anyone tell me how to recreate my status.cgi file for nagios. I have a status.dat file that supposedly it is created from. Bonus points if you can tell me how to make a status-json.cgi file also.
I have downloaded the status.c file from nagios 3.5.0 and also the Makefile that was in the same cgi folder. However when I tried copying those to my server and running the command "make status.cgi" I got "no rule to make target 'status'. Stop.
SOLVED:
Recreating just the status.cgi file proved difficult and trivial. What I did to get the file back was this.
I created a copy of my whole /usr/local directory just to have a
backup.
I downloaded the source for a new full install of nagios for the specific version I had installed.
./configure
make all
make install <- this recreates all the cgi files.
I then recopied my original local directory back (changing the name of the one I just made)
Then moved the status.cgi file from the new local directory to the original one (in /usr/local/nagios/sbin)
the status.cgi file is now working again
you need the command:
make install-webconf
That'll recreate the files and drop them where they need to be

jar file not found iexpress

I am using iexpress to make my .jar files into .exe files
for this I add the jar file(myjarfile.jar) and in run command box I type : java -jar myjarfile.jar
but after creating the .exe the cmd that is flashing says cannot find the jar file myjarfile.jar
can any body help me find what I am doing wrong
To test this, I built a simple HelloWorld.jar file (using these instructions) and tested it like so:
java -jar HelloWorld.jar
Then I made an IExpress package with it. The Install program was exactly the command I used above. This worked exactly as it should.
Two possible causes of the error:
In the IExpress wizard, there's a checkbox Store files using Long File Name inside Package. You should definitely select this option; ignore the warning that appears, as it applies to Windows 95/98. In the .sed file, this is:
UseLongFileName=1
Check that the .exe actually contains myjarfile.jar. 7-Zip will open the .exe and show you the archive contents. (IExpress .exe files are just a CAB file with a wrapper.) If the file is missing, then you'll need to check your .sed file to see what went wrong.

Temp path too long when publishing a web site project

I am trying to publish an ASP.NET web site project using the Publish Web Site tool but get this error:
ASPNETCOMPILER(0,0): Error ASPRUNTIME: The specified path, file name,
or both are too long. The fully qualified file name must be less than
260 characters, and the directory name must be less than 248
characters.
I see that it is trying to copy the files to a very long path in AppData:
Copying all files to temporary location below for package/publish:
C:\Users\imx0\AppData\Local\Temp\1\WebSitePublish\BMW.Web-424993535\obj\Debug\AspnetCompileMerge\Source.
c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v /BMW.Web -p C:\Users\imx0\AppData\Local\Temp\1\WebSitePublish\BMW.Web-424993535\obj\Debug\AspnetCompileMerge\Source C:\Users\imx0\AppData\Local\Temp\1\WebSitePublish\BMW.Web-424993535\obj\Debug\AspnetCompileMerge\TempBuildDir
I couldn't find anything about this temp directory in my .pubxml publish profile. How can I change the temporary directory that Visual Studio copies the files to?
Add this to your publish profile to modify the temporary directory for package/publish:
<AspnetCompileMergeIntermediateOutputPath>c:\shortPath\</AspnetCompileMergeIntermediateOutputPath>
Go to your web project folder, navigate to Properties\PublishProfiles folder.
open your profile file profile_name.pubxml (not the profile_name.pubxml.user)
copy/past <AspnetCompileMergeIntermediateOutputPath>c:\shortPath\</AspnetCompileMergeIntermediateOutputPath> under the <PropertyGroup> tag
save your file, you would be able to publish your website using this profil
This is sort of an aside answer, but I ran into this problem when trying to MSBuild a solution that depended on nodeJS and gulp. The problem was that the gulp dependency tree became very deep and the aspnet_compiler was trying to copy that tree to a deeper directory, resulting in this error. I tried everything noted in here but nothing worked.
As it so happened, I was building with TFS, so my solution was to run an attrib +h node_modules\* /S /D before msbuild to hide the directory tree and then attrib +h node_modules\* /S /D. That did it for me.
Sure would be nice if the error thrown in this situation by the compiler revealed the path that caused the write to fail...
try adding this
<IntermediateOutputPath>..\Temp</IntermediateOutputPath>
to the default <propertyGroup />
None of the other answers worked for me.
Visual Studio 2013 Community Edition.
I changed the TMP and TEMP environment variable to a short folder name and it worked.
We identified the lengthy files/folders using this solution, then corrected the issue from there:
Run this script at the command prompt: dir /s /b | sort /r /+261 > out.txt it will output all file paths into the out.txt file
Copy the output to an Excel file
In the next column over from what you pasted in add this Excel function: =LEN(A1) where "A1" is the cell, copy this against every file length so you can see how long the paths are
Sort in Excel by the path length
Identify the lengths over the recommended limit
I know this is a bit long-winded but if you have several files that are resulting in this issue you'll be able to see them all.
Even though the content of node_modules was not included in neither version control not in the *.csprojfile itself Deleting the whole node_modules folder did the trick for me.
You can try the selected solution for correcting the long file path issue.
Still if not able to publish due to some other issue, You can try below method.
=> If the 'Solution Configuration' is in 'Debug' mode, please change the same to 'Release' mode and Publish the files.
=> If the Solution Configuration is in Release mode, and if the problem still persists, please try to delete the dll generated earlier in the 'Release' folder of our project and Publish the project once again.
Any of the above method will solve the issue.
For me, using Visual Studio 2019, the only change to the publish profile .pubxml file that worked was:
<WPPAllFilesInSingleFolder>c:\shortPath\</WPPAllFilesInSingleFolder>
I discovered this property at line 484 of Microsoft.Web.Publishing.targets file. Full path was C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VisualStudio\v16.0\Web.

Resources