I have been using the "file" command in terminal (Mac) for a while.
Now encountering this error:
file: File 5.31 supports only version 14 magic files. `/usr/share/file/magic.mgc' is version 13
Seems like a fairly simple solution to update the magic file, but can't find any instructions to complete this. Can someone advise?
Any help is much appreciated here.
Perhaps you have more than one file executable in your $PATH. It can get confused if it finds a different database (magic) than it expected. File 5.29 (tagged October 2016) bumped the format to version 14. File 5.31 appears to be the current version on MacOS (works for me).
The "magic" file is built up from many smaller files (see git repository (mirror)). If you needed a specific version that's not prepackaged, you could download the source and compile it, starting with the project page, which points to an ftp site.
However, replacing that magic.mgc file runs into Apple's "system protection" (limited permissions). It's possible to turn that off (perhaps not a Good Idea®) But it's doable.
While you could replace the data file, it might be simpler to just install MacPorts and use the file package from that. It's currently at 5.32 (a step ahead of Apple's package), and if you did not like that, it's simpler to remove/alter.
Related
C: Clarity needed on Cython, Cythonize, setup.py/MSVC, GCC issues and creating/using header files
Hello all,
I am relatively new to Cython and very new to C but do have some programming experience with Python, Visual Basic and Java.
For my current project, my machine is running on Windows Pro 10 1909 x64, Python 3.7.9 x64 and Cython 0.29.21 and my ultimate goal is to create an EXE file with all the modules included.
I have not included any cdef statements or such like at this time and I plan to add these incrementally. Essentially what I am doing at the moment is at the proof-of-concept stage to show that I can compile and run current and future code without issues.
I have a __main__ module stored in the root project folder and my other (some very large) Python modules renamed as .pyx files which handle different types of files (.csv, .json, .html, .xml, etc) each with their own characteristics and method of extraction, stored in an 'includes' folder.
As I understand it, the header files contain function definitions which are then called upon as needed to act as a bridge between the subroutines and the main module. I have not created any header files at this time as I need clarity on a few points.
I am also having trouble Cythonizing with setup.py (setuptools) through MSVC and GCC.
Below are a discussion of the steps outlined so far to reach this point regarding setup.py, GCC and running directly from the prompt with my main questions at the end.
Step 1
My first attempt at compiling the code is to prepare a setup.py file from an elevated command prompt.
from setuptools import Extension, setup
from Cython.Build import cythonize
extensions = [
Extension("main", ["__main__.pyx"],
include_paths=r"C:\path\to\parsing_company_accounts_master_cython\includes"),
]
setup(
name="iXBRLConnect",
ext_modules=cythonize(extensions, compiler_directives={'language_level' : "3"}),
)
However, in Python 3.7.9 x64, I get the following output.
python setup.py bdist
running bdist
running bdist_dumb
running build
running build_ext
building 'main' extension
error: Microsoft Visual C++ 14.0 or greater is required. Get it with "Microsoft C++ Build Tools": https://visualstudio.microsoft.com/visual-cpp-build-tools/
I have this same error with all versions of Python and installing many variants of the build tools starting from 2015, when running in an elevated x64 Native Tools Command Prompt (any version of VS or standalone Build Tools).
Searching on this site points to many different SDKs, libraries and so forth that need to be added but after following many answers and numerous restarts I still am unable to get setup.py to run.
I CAN compile with VS Community Edition as a GUI, but all efforts seem to be confounded when using the command line (no other reason but for keeping a lean installation). It's not clear why the prompt route does not work.
Step 2
Not to be outdone, I attempt to install GCC - MinGW-w64 (https://wiki.python.org/moin/WindowsCompilers), an alternative compiler that is supported up to Python 3.4.
Noting that Python 3.4 is past end of life I uninstall Python 3.7.9 x64, install 3.4 and reinstall my pip site-packages.
However, installing BeautifulSoup4 gives me this message:
RuntimeError: Python 3.5 or later is required
I would take the EOL issue for Python 3.4 with a large pinch of salt but BS4 is a key library for my project so this is pretty much a showstopper.
Step 3
Finally, I attempt to build the files directly on the command line.
First, I move my other .pyx modules into "c:\path_with_spaces\to\includes" (9 in total), keeping __main__.pyx in the main project folder then run the next command from the project folder.
cython -3 --annotate --embed=main __main__.pyx --include-dir "c:\path_with_spaces\to\includes"
Questions
So, all the above said and done (phew!), here are the points I need clarity on: -
Q1: It seems to me that the 'include_paths'/'include-dir' arguments specify other additional directories only to create new C files - I presume the reason that this is because there are no header files alongside the existing *.pyx modules? [Initially, I naively thought Cython would automatically raise the headers and .c files? Instead, nothing at all - .c or .h - is generated for them.] Is there something wrong with my command line syntax for '--include_dirs' as the .c files should have been raised regardless and I just 'slot' the header files in? There is no error to say so. Or are the included files just meant to be read and no other action being taken on them, as you would expect from a library file?
Q2: As I continue to learn more It is increasingly clear that the header files need to be prepared in advance, according to this: https://cython.readthedocs.io/en/latest/src/userguide/external_C_code.html and this: http://hplgit.github.io/primer.html/doc/pub/cython/cython-readable.html However as far as I can ascertain from their examples (unless I am looking at the wrong thing), they only call their modules from the main module at some point. Taking the last link, I am not clear about 'dice6_cwrap' in the dice6_cwrap.pyx example (I think it should be referenced in the main module but it is not directly shown in this example). Also, may I also need other files perhaps a manifest of some sort?
Q3: In part answer to Q2, I think I can 'chain' modules together as explained here: How does chain of includes function in C++?? This is important to me because the way my code has worked up to now is to load each module (depending on what files are found) and then run through the modules in a 'chain' sequence to first parse all elements in a soup object, run through each line element and finally extract each attribute and insert them into a common database. In actual practice that can mean up to 8 'links' in total counting from the 'start' method in the submodule and depending on the attribute in question. FYI, some of the modules also include pandas, numpy and multiprocessing modules too. Thinking aloud - including header files, that means prepping 16 files? Eww! (BUT, with a little luck and fingers crossed - speed gains from C compilation vs Python interpretation...other bottlenecks permitting).
Apologies for my waffle, I welcome your thoughts on how I can move forward on this.
Thanks in advance.
I'm trying to install a geocoder for a website I'm building. I'm using Geocoder because the query limit for the Google Maps API falls short of my needs. I installed all the gems required and have SQLite3. When I'm actually trying to install the geocoder gem (Geocoder::US) I get an error while running the make file.
I'm getting an error I cannot figure out. It mentions the error (in the title) then talks of an non-existent file (sqlite3ext.h). Here is the error:
I know this is vague but I've been working for 10+ hours trying to install this and have found little help online. Any advice on which direction to go would be appreciated.
This is from the project's Readme:
To build Geocoder::US, you will need gcc/g++, make, bash or equivalent,
the standard *NIX ‘unzip’ utility, and the SQLite 3 executable and
development files installed on your system.
It seems that you lack the SQLite3 development headers.
This is relevant:
NOTE: If you do not have /usr/include/sqlite3ext.h installed, then
your sqlite3 binaries are probably not configured to support dynamic
extension loading. If not, you must compile and install SQLite from
source, or rebuild your system packages. This is not believed to be a
problem on Debian/Ubuntu, but is known to be a problem with Red
Hat/CentOS.
Also they do not mention Windows. You should:
Ask them if someone uses it on Windows and if there are instructions for that.
Evaluate the thing on Linux, Debian/Ubuntu especially.
-fPiC is not your problem. As the log states, the compiled code is already position independent. The problem is, that the sqllite3ext.h is not in the compiler include path.
I have downloaded and ran the CUDA 5.0 installer on my Mint 15 64bit distro. After hours of agony adjusting / removing / installing packages, it was able to finish installation - at least that what it said.
I can go run the CUDA samples so I thought hey it's working. However, I just made a new cu file and wanted to compile but it said "nvcc command not found"
I have looked at a topic similar to this here and they are talking about /opt/bin/ directory however on mine, there is no such directory. Does that mean it actually did not install ? It tells me to install nvidia cuda toolkit with apt-get but I am not sure if I should do that.
Also, I did say I ran the CUDA samples fine but I have to say ldconfig /usr/local/cuda/lib64
before I can get it to working. Is there a way to automate that ?
Thanks
You need to add the bin directory of the nvcc compiler driver to your PATH (environment variable), and you need to add the appropriate lib directories to your LD_LIBRARY_PATH environment variable.
For an immediate test, this should be as simple as:
export PATH=$PATH:/usr/local/cuda/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib64:/usr/local/cuda/lib
These instructions should be presented to you at the completion of a successful cuda toolkit install, but it seems your install method may have been roundabout.
To make this "automatic" you may want to investigate one of the methods to add these statements to a script run at login. For example, if you have a .bashrc file in your user's home directory, try editing that with the above commands. It should probably be sufficient to put the above commands at the very end of your ~/.bashrc file if you have one.
Note that Linux Mint is not one of the officially supported CUDA distros, so your mileage may vary.
Gnuplot experts or anyone who is willing to help me - I have explained what I have done in very simple words and in a detailed manner. Thanks for your time and patience in advance.
My aim is to develop a new feature in Gnuplot by adding a new terminal to it. I did the following steps in the order mentioned
I formatted my system and reinstalled Windows 7. (no antivirus installed)
Installed Visual Studio 2008
Downloaded the source code of Gnuplot
Now, am supposed to set up the compiling environment for Gnuplot in Windows. So, I did the following steps as per the instructions in "README" and "INSTALL" files in the source code package.
Opened up Visual Studio 2008 Command Prompt
changed directory to the "src" folder in the source code
Then I ran the nmake tool (the make tool meant for Visual Studio) using the file makefile.nt (which is for Windows)
nmake -f C:\Users.........\config\makefile.nt
It compiled successfully and gave the wgnuplot.exe and gnuplot.exe files as output. Also the manifest files were created. (Note: I have not changed any piece of code from the original source code package)
When I tried to open the exe file generated from the compilation, it threw me this error
The program can't start because MSVCR90.DLL is missing from your computer. Try re-installing the program to fix this problem.
This MSVCR90.dll should be installed already when Visual Studio was installed. I checked the C:\Windows\winsxs\x86_microsoft.vc90... folder and the MSVCR90.DLL was alread there. Then, I tried 2 things to solve this -
Anything to do with PATH variable? I made the PATH variable point to that directory. It threw me a new error that says
Microsoft Visual C++ Library. Run time error. R6034. Here is the detailed picture of the error
So, I reset my path variable back to the old value and followed the steps in THIS FORUM POST to fix the missing dll problem by copying the dll files to the C:\Windows\system32 folder. Again it threw me the same run time error
AM STUCK AT THIS POINT. Please advise me on how to rectify this
problem. THANKS A MILLION :) Advance thanks to you :)
Is there any reason you need to use VS2008?
If not I'd recommend to use the current VC release.
Your problem looks like some sort of version mismatch/incompablilty issue to me ...
I know it can sound as a pretty dumb question, but I do not have a great experience with installing downloaded libraries...
Anyhow I downloaded the source code of JudyArrays (which is a C library for a 256-trie for those who doesn't know it) from sourceforge and the installation instructions refers to the make command. I tried to download this utility, but I can't get it work. Which is the correct target makefile? All I managed to get was:
"..path\Makefile.in":15: *** missing separator. Stop.
I tried googling for some help but didn't find anything, either I'm searching with the wrong query string or I'm the only dumb person in the whole planet that can't manage to install it...
Any help? Is there any simpler method?
Thanks everyone
Run your Visual Studio Command Prompt to get a cmd.exe with the proper paths set. cd into the src directory of the JudyArrays source code and run build.bat. This'll compile Judy and produce a .lib and a .dll and a Judy.h header file file you'll have to use in your projects as any other 3. party library.