Building NSIS from source on windows (VS2012) - nsis

I'm working on a pure x64 version of my software. Our installer for the x86 version is NSIS and my software is built using VS2012. I found online that in order to build x64 installers using NSIS you have to build NSIS (and all plugins/etc) from source. That is the end goal. However, right now I'm having issues just building x86 (before moving on to x64) using the instructions in the NSIS docs. https://nsis.sourceforge.io/Docs/AppendixG.html#build_windows
I'm trying to build NSIS v3.0.4 which uses SCons to build. I've installed scons using pip (SCons version 3.1.1).
However, when trying to build NSIS, I get the following (using python 3.8.0).
C:\Source\nsis\nsis-code-r7069-NSIS-tags-v304>scons ZLIB_W32=C:\Source\zlib-1.2.7 MSTOOLKIT=yes
scons: Reading SConscript files ...
TypeError: cannot use a string pattern on a bytes-like object:
File "C:\Source\nsis\nsis-code-r7069-NSIS-tags-v304\SConstruct", line 263:
for v in re.compile(r'^\\H\{[v]?(\S+)\}', re.M).finditer(File('#/Docs/src/history.but').get_contents()): # Try to parse the Halibut history file
the section of the SConstruct file is as follows (starting at line 260 so the for loop starts at 263):
if not defenv.has_key('VER_PACKED'):
import re
found = None
for v in re.compile(r'^\\H\{[v]?(\S+)\}', re.M).finditer(File('#/Docs/src/history.but').get_contents()): # Try to parse the Halibut history file
if v and not found:
v = v.group(1).split('.')
if len(v) >= 2:
mi = int(re.search(r'\d+', v[1]).group())
if mi < 1: mi = 1 # Make sure we can subtract 1 from the minor number so trunk stays below the next release
defenv['VER_PACKED'] = '0x%0.2i%0.3i%0.2i%0.1i' % (int(re.search(r'\d+', v[0]).group()), mi - 1, 66, 6)
if int(defenv['VER_PACKED'], 0) >= int('0x03000000', 0):
found = v
if not found:
defenv['VER_PACKED'] = '0x%0.2i%0.3i%0.2i%0.1i' % (3, 3, 42, 0) # Default to a version number we never used
print('WARNING: VER_PACKED not set, defaulting to %s!' % defenv['VER_PACKED'])
At this point, I'm not sure if there is a dependency I'm missing or if this is an issue with the build script and needs to be reported at the NSIS issue tracker. Ideas?
-UPDATE 1-
Based on suggestions from #Anders, first I tried to build the head of the repo (r7132 trunk) instead of v3.0.4 using Python3. This got me farther but still failed on what appears to be Python2 vs 3 syntax errors in mstoolkit.py (might be a symptom of another issue rather than the cause though). I didn't investigate this too much further yet.
So next, I went back to Python 2.7. This got me further but the mstoolkit.py appears to be dependent on VS2003 implementation. I duplicated the VCToolkitInstallDir environment variable on my machine using the contents of the VS110COMNTOOLS (C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools) but that fails also:
File "C:\Source\IQClient_Interim\Shared\third_party\nsis\nsis-code-r7132-NSIS-tags-v304\SCons\Tools\mstoolkit.py", line 87, in get_msvctoolkit_paths
raise SCons.Errors.InternalError, "The Platform SDK directory was not found in the registry or in the `MSSdk` environment variable."
InternalError: The Platform SDK directory was not found in the registry or in the `MSSdk` environment variable.
I don't know what the VS2003 VCToolkitInstallDir ENVVAR was pointing to to fix this.
With all that said, I just noticed that Anders said that I might also have to use an older version of scons as well with python2.7 so I suppose I'll spend some time investigating that (along with looking into #bdbaddog's solution).
-UPDATE 2-
it was the mstoolkit directive (see #Anders answer's comments)
I got it working after that while using py 2.7 for NSIS 3.0.4.
Now on to x64 build but that's a different story so I'll post a different question.

NSIS v3.04 does not support Python 3, you have to grab the latest source code from SVN. v3.05 is coming out soon with support for Python 3.
VS2012 is old enough that you should be able to use Python 2.7 and a older version of SCons as an alternative.
As a final alternative, you can try to apply this diff to v3.04.

The issue you're running into is twofold.
Python > 3.0 strings are no longer bytes. They are unicode
SCons which supports Python > 3.0 (SCons >3.0 supports Python 2.7 and Python > 3.5.0)
In order to support this Node()'s (SCons's way of representing files, directories, and values which feed into a build) now have two methods get_contents() and get_text_contents().
Since you're using Python 3.8.0, get_contents() will return bytes, which explains the error you've received.
The proper way to resolve it is to change this line:
for v in re.compile(r'^\\H\{[v]?(\S+)\}', re.M).finditer(File('#/Docs/src/history.but').get_contents()): # Try to parse the Halibut history file
to:
for v in re.compile(r'^\\H\{[v]?(\S+)\}', re.M).finditer(File('#/Docs/src/history.but').get_text_contents()): # Try to parse the Halibut history file
Please let me know if this doesn't resolve the issue.
Also, if you're willing to install Python 2.7 and reinstall SCons via
py -2.7 -mpip install scons
(Assuming you've install the py launcher when installing Python. Not sure if that's default with Python 3.8 and/or Python 2.7. If not then /python -m pip install scons. You might have to install pip as well. Once again not sure on the default for that.)
Then you can avoid changing the SConstruct file.
Hope this helps!

Related

unable to execute 'x86_64-conda_cos6-linux-gnu-gcc': No such file or directory (pysam installation)

I am trying to install pysam.
After excecuting:
python path/to/pysam-master/setup.py build
This error is produced:
unable to execute 'x86_64-conda_cos6-linux-gnu-gcc': No such file or directory
error: command 'x86_64-conda_cos6-linux-gnu-gcc' failed with exit status 1
There are similar threads, but they all seem to address the problem assumig administriator rights, which I do not have. Is there a way around to install the needed files?
DISCLAIMER: This question derived from a previous post of mine.
manually installing pysam error: "ImportError: No module named version"
But since it might require a different approach, I made it a question of its own.
You can also receive the same error while installing some R packages if R was installed using conda (as I had).
Then just install the package by executing: conda install gxx_linux-64 to have that command available.
Source:
https://github.com/RcppCore/Rcpp/issues/770#issuecomment-346716808
It looks like Anaconda had a new release (4.3.27) that sets the C compiler path to a non-existing executable (quite an embarrassing bug; I'm sure they'll fix it soon). I had a similar issue with pip installing using the latest Miniconda, which I fixed by using the 4.3.21 version and ensuring I was not doing something like conda update conda.
See https://repo.continuum.io/miniconda/ which has release dates and versions.
It should now be safe to update conda. This is fixed in the following python packages for linux-64:
python-3.6.2-h0b30769_14.tar.bz2
python-2.7.14-h931c8b0_15.tar.bz2
python-2.7.13-hac47a24_15.tar.bz2
python-3.5.4-hc053d89_14.tar.bz2
The issue was as Jon Riehl described - we (Anaconda, formerly Continuum) build all of our packages with a new GCC package that we created using crosstool-ng. This package does not have gcc, it has a prefixed gcc - the missing command you're seeing, x86_64-conda_cos6-linux-gnu-gcc. This gets baked into python, and any extension built with that python goes looking for that compiler. We have fixed the issue using the _PYTHON_SYSCONFIGDATA_NAME variable that was added to python 3.6. We have backported that to python 2.7 and 3.5. You'll now only ever see python using default compilers (gcc), and you must set the _PYTHON_SYSCONFIGDATA_NAME to the appropriate filename to have the new compilers used. Setting this variable is something that we'll put into the activate scripts for the compiler package, so you'll never need to worry about it. It may take us a day or two to get new compiler packages out, though, so post issues on the conda-build issue tracker if you'd like to use the new compilers and need help getting started.
Relevant code changes are at:
py27: https://github.com/anacondarecipes/python-feedstock/tree/master-2.7.14
py35: https://github.com/anacondarecipes/python-feedstock/tree/master-3.5
py36: https://github.com/anacondarecipes/python-feedstock
The solution that worked for me was to use the conda to install the r packages:
conda install -c r r-tidyverse
or r-gggplot2, r-readr
Also ensure that the installation is not failing because of admin privileges.
It will save you a great deal of pain
After upgrading Golang to 1.19.1, I started to get:
# runtime/cgo
cgo: C compiler "x86_64-conda-linux-gnu-cc" not found: exec: "x86_64-conda-linux-gnu-cc": executable file not found in $PATH
Installing gcc_linux-64 from the same channel, has resolved it:
conda install -c anaconda gcc_linux-64
Somewhere in your $PATH (e.g., ~/bin), do
ln -sf $(which gcc) x86_64-conda_cos6-linux-gnu-gcc
Don't put this in a system directory or conda's bin directory, and remember to remove the link when the problem is resolved upstream. gcc --version should be version 6.
EDIT: I understand the sentiment in the comments against manipulating system paths, but maybe we can use a little critical thinking for the actual case in hand before reciting doctrine. What actually have we done with the command above? Nothing more than putting an executable (symlink) called x86_64-conda_cos6-linux-gnu-gcc in one's personal ~/bin directory.
If putting something in one's personal ~/bin directory broke future conda (after it fixes the C compiler path to point to gcc it embeds), then that would be a bug with conda. Would the existence of this verbosely named compiler mess with anything else? Unlikely either. Even if something did pick it up, it's just your system gcc after all...

does changing python version need rebuilding caffe

I used a virtualbox with ubuntu-16, to install caffe in python 2.6. As I wanted to use py2exe, I needed to change python version to 3.6. When this was done, caffe import code stopped working. Here is the error message:
ImportError: libcaffe.so.1.0.0-rc5: cannot open shared object file: No such file
or directory
Do I have to rebuild caffe? Or is something else that need to be changed?
Here is the full image of the error:
Yes, you need to rebuild Caffe. The Python 2 and Python 3 libraries are not compatible. Not all of the file names are the same (different / added software organization). This rebuild requires that you place a single version of Python first in all search paths: make, compile, load, ...
When I need to do this, I check with my SysOps: there's always something I forget.

Is there an installer for geodict python library?

I wanted to use the code:
import geodict_lib
locations = geodict_lib.find_locations_in_text(text)
But there seems to be no installer for geodict_lib. How do I install this is Anaconda 3.0 Python 3?
I know this is a year on, but perhaps I could help others who stumble on this. You'll need to place the files in the directory for modules that your installation of Python is monitoring.
First, download the .zip file from GitHub here.
Once you've done that, you can run the following at the command line or terminal:
conda list
This will provide the path to all installed packages in your installation of Python. Move the geodict.zip file you downloaded to that location. You might want to run which python as well (see here) since you may have a few different installations to check for.
Now when you run python import geodict in Python it should run without trouble!

How to get Sphinx working in PyCharm with Python 3.5

This is my first time using Sphinx in PyCharm 5.0 with Python 3.5.
When I run sphinx task in PyCharm I get the following error:
File "C:\Program Files (x86)\JetBrains\PyCharm 5.0\helpers\docutils\__init__.py", line 63, in <module>
class ApplicationError(StandardError): pass
NameError: name 'StandardError' is not defined
On this page I discovered that in Python 3.x StandardError is now replaced with Exception. However, when I try to edit the __init__.py file PyCharm prevents me from saving it.
I also noticed that __init__.py is based off of docutils version 0.8. This is not intuitive since I installed docutils version 0.12 in my virtualenv. Meaning that version 0.12 is being ignored.
Does anyone know how to fix this?
Update: PyCharm 5.0.2 fixes this, and Sphinx run configurations work under Python 3
Unfortunately the Python code shipped in PyCharm pre-5.0.2 helpers is not Python 3 compatible. The PyCharm issue tracker has a ticket. I once gave a crack at fixing all the small boo-boos, but then ran into some bigger ones.
So instead, just make a Run Configuration that calls:
Script (on Mac): /Users/paul/projects/jetbrains/env35/bin/sphinx-build
Script parameters: -b html -d _build/doctrees . _build/html
...and set the working directory to the place you want the _build directory.
Edit: Added a link for how to create and edit run/debug configurations in pycharm and a screenshot for windows. Script location is 'Scripts' as opposed to 'bin'.
Creating and Editing Run/Debug Configurations in PyCharm 5.0
PyCharm 5.0 Screenshot (on Windows)

How to link with Python3 Libs with cmake?

I have Python3 installed via brew install python3. However, cmake cannot find PythonLibs 3. Here's the header of my CMakeLists.txt.
cmake_minimum_required(VERSION 3.0)
find_package(PythonLibs 3 REQUIRED)
When I ran cmake, I got this error message
Could NOT find PythonLibs: Found unsuitable version "2.7.6", but required is at least "3" (found /usr/lib/libpython2.7.dylib)
Not sure what I did wrong.
In my experience, this happened because I was using an older version of cmake (2.8 instead of 3+) that didn't know about Python 3.4 (it gave up after 3.3.)
The solution was to go into the CMakeLists.txt file and add an "additional versions" directive ABOVE the find_package:
set(Python_ADDITIONAL_VERSIONS 3.4)
find_package(PythonLibs 3 REQUIRED)
You could probably also fix it by upgrading your version of cmake. But the above worked for me with cmake 2.8
Because you are using CMake >= 3.0, you can you find_package(Python COMPONENTS Interpreter Development) see: https://cmake.org/cmake/help/v3.12/module/FindPython.html
That would for instance give you for:
find_package(Python COMPONENTS Interpreter Development)
message("Python_FOUND:${Python_FOUND}")
message("Python_VERSION:${Python_VERSION}")
message("Python_Development_FOUND:${Python_Development_FOUND}")
message("Python_LIBRARIES:${Python_LIBRARIES}")
Results:
Python_FOUND:TRUE
Python_VERSION:3.8.0
Python_Development_FOUND:TRUE
Python_LIBRARIES:/usr/lib/x86_64-linux-gnu/libpython3.8.so
Another reason for this is that CMake can't ever find Python 3 when it is installed from brew on OSX. It looks like the CMake devs know that FindPythonLibs sucks and have a ticket to revamp it but it doesn't look like it will happen any time soon.
I believe the Python interpreter itself knows where its libraries and headers are so I think the best thing to do would be to run it to find out. To get the path to the Python interpreter I would force the user to specify it manually. One of the big issues with Python is that lots of software includes its own copy so you'll end up with 5 copies of it on your system. The chance of picking up the wrong one is just too high. Get the user to specify the correct one.

Resources