Good day,
I recently could install Lua 5.3 to /opt/lua53 on Centos 7
I also added the following line into /etc/bashrc
PATH=/opt/lua35/bin:$PATH
LD_LIBRARY_PATH=/opt/lua53/lib:$LD_LIBRARY_PATH
export PATH LD_LIBRARY_PATH
export LUA_INCLUDE_DIR=/opt/lua53/include
My colleague also install a software and when I compile by doing
make
I got the following errors
[root#pc6 jixie]# make
-- Release Build
-- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is at least version "5.2")
-- Could NOT find ZEROMQPP (missing: ZEROMQPP_LIBRARIES ZEROMQPP_INCLUDE_DIRS)
-- Could NOT find OPENVDB (missing: OPENVDB_LIBRARIES OPENVDB_INCLUDE_DIRS)
-- Downloading/updating kdtree
-- Configuring done
-- Generating done
I look into serveral thread but none of then could help me.
As I wrote, I added the following line
export LUA_INCLUDE_DIR=/opt/lua53/include
hoping it can provide the path to LUA_INCLUDE_DIR, but unfortunately I still get the same error.
Any idea how I can solve my problem? DO you need more information of my system?
NB: I am using cmake 3.10
PATH=/opt/lua35/bin:$PATH looks wrong: It should be /opt/lua53/bin.
You are re-inventing the wheel and making it square this time round...
If you have installed Lua development (package or from source) then there should be a package-config file named lua.pc placed at a location where cmake or configure can find it and enquire it as to what should the libs and cflags of any application requiring Lua include/libs. For my system, these files are usually located at /usr/lib64/pkgconfig/ and indeed lua.pc lives there with this content:
V= 5.3
R= 5.3.4
prefix= /usr
exec_prefix=${prefix}
libdir= /usr/lib64
includedir=${prefix}/include
Name: Lua
Description: An Extensible Extension Language
Version: ${R}
Requires:
Libs: -llua -lm -ldl
Cflags: -I${includedir}
The above file tells configure where the include dir is, and what's more important, what flags to use during compilation (-I... -L... -l...).
If you are on a system with a package manager (say yum, dnf, apt-get, etc.) then placing these pc files to their location is taken care of automatically if they exist in the package that is.
If you insist to do it the way you have done it above by hand-coding LUA_INCLUDE_DIR to your shell's environment, then make sure that LUA_INCLUDE_DIR points to an existing and valid location with valid content. Are you sure the include files required can be found in that dir? Maybe there is an extra dir in there?
I am trying to program a Xilinx zc706 board, which involves building a Linux kernel and setting up the bootloader. I am following the workflow given here.
The first step after downloading stuff involves making the device tree compiler, which I need to get UBoot, which I need to start up linux. I obtained the source for DTC off github, but when I went into the SDK shell, moved to the directory, and entered "MAKE", I got an error:
sed: -e expression #1, char 1: unknown command: `''
-x was unexpected at this time.
" " LEX convert-dtsv0-lexer.lex.c
process_begin: CreateProcess(NULL,flex -oconvert-dtsv0-lexer.lex.c convert-dtsv0-lexer.1, ...) failed.
and then followed with some other stuff saying files could not be found, presumably because this first thing failed.
I have no idea how to read this error, it's gibberish to me. Can someone explain either what's wrong with this build, or how I can get either the DTC or UBoot I would need to run a Zynq chip?
It looks like you're making things much harder on yourself by doing manually what PetaLinux will do automatically for you. Unless you're a die-hard Linux purist and want to build your embedded Linux system from scratch, you should stop reading after the first paragraph of the link you posted and head to the PetaLinux wiki page.
Follow the steps in the PetaLinux Tools Reference Guide to get your project up and running. It will handle building u-boot, rootfs, linux kernel, and device tree compiler for you (petalinux-* commands) and you can focus on developing your application.
When doing Ctrl+B on SublimeText3, the following error is output:
[Compiling first.tex]
TraditionalBuilder: Invoking latexmk...
COULD NOT COMPILE!
Attempted command:latexmk -cd -e $pdflatex='pdflatex -interaction=nonstopmode -synctex=1 %S %O' -f -pdf first.tex
Build engine: Traditional Builder
Running the exact same command compiles a pdf file just fine.
This answer does not solve the problem, as I've
Removed spaces around "="
Done a "Reconfigure LaTeXTools and migrate settings".
Made sure pdflatex is installed.
Made sure the path for texpath is correct.
If your command runs on terminal then most likely there is an issue either with the path or with the command itself (in the file). There has been some update to the README file by the developer:
some distros do not want a space before and after the = in $pdflatex = %E. But some do want the space there (sigh!)
sometimes latexmk is not on the PATH, or the path is not correctly picked up by ST. In this case, instead of "latexmk", use "/usr/bin/latexmk" or wherever latexmk is in your system.
some distros require quoting the $pdflatex assignment, as in "$pdflatex = \"'%E -interaction=nonstopmode -synctex=1 %S %O'\""
So it might take a while but you'll find it eventually in the settings or the traditionalbuilder.py file.
Also when I tried putting /usr/bin/latexmk, latex did not produce the correct pdf (I checked it with few changes and it just opened the old pdf) but in your case it might work.
Also, at least in Arch Linux I can't run sublime with sublime-text but instead with subl so I changed that too in the settings (I don't know if it actually matters) and I needed to change the permissions for the files because user-run sublime could not access my settings files!
I'm trying configure PyScripter 2.5.3 to use a version of Python that is installed in a non-standard install location (i.e., c:\MyProj\Python27).
NOTE: I also have ActivePython 26 and 27 also installed, in the default locations c:\python26 and c:\python27)
I have a short program that simply dumps the python path to verify that I have the correct version:
import sys; print( "\n".join(sys.path) )
When I'm using the "desired version", I'll see "c:\MyProj\Python27\lib" show up on the path.
I've looked at several postings (one is How to change the version of python that pyscripter uses) and most just say the defaults work and the defaults do work. I'm trying to use a non-default directory.
I've used Tools | Configure Tools to set the Python Interpreter, and Command Prompt to run "MyProj" version of python.
So Tools | Python Interpreter, starts c:\MyProj\Python27\python.exe
Also Tools | Command Prompt, starts c:\MyProj\Python27\python.exe version.
But I can't get the Python IDE to use the desired version when I use "Run | Debug (F9)".
I've configured Tools | Options | IDE Options | Python engine type = peRemote.
I've also tried internal.
I've tried starting PyScripter from the command line with the following options (none of these examples worked)
...\PyScripter.exe --python27 --pythondllpath=C:\MyProj\Python27
...\PyScripter.exe --python27 --pythondllpath=C:\MyProj\Python27\python27.dll
...\PyScripter.exe --python27 --pythondllpath C:\MyProj\Python27
...\PyScripter.exe --python27 --pythondllpath C:\MyProj\Python27\python27.dll
I've tried having only my version of python on the windows PATH (removing c:\Python27)
set PATH=C:\MyProj\Python27;%PATH%
...\PyScripter.exe
This has also failed to work.
Has anyone had success at using a non-standard location? If so what steps were followed?
I don't know if this is the best way to do it, but those are the two ways I did it:
WAY 1 (The best of two)
Go to PyScripter>>Tools>>Options...>>Custom Parameters... and add the following values
1. PythonDir = C:\Program Files\CustomPythonInstallation
2. PythonExe = C:\Program Files\CustomPythonInstallation\python.exe
3. PythonVer = 3.3.3
Note: Adapt the Name = Value pairs above to your case.
And close the window with OK button.
Now select PyScripter>>Run>>Python Engine>>Remote and your are ready to go.
WAY 2 (The more temporary solution)
Go to PyScripter>>Run>>Configure External Run...
set the "Application:" field to your python.exe file
Close the window with OK button.
Make sure you run your scripts with PyScripter>>Run>>External Run (Alt+F9)
I hope this helped, good luck.
I'm using two different pythons, tried to use pyscripter with both, but it kept messing up. My simple solution was to download the standalone pyscripter that doesn't use the registry, put copies into two different directories, then set each up for the different py. You can then right click on their icons and set them to start in the proper directories. You can also make two cmd icons and set them respectively so you have a command line. The command line icon can also be set to start in your working directory, although that's normally one level below python, and if it isn't on the path, you have to type ../python to get it (or use a keyboard macro for that.) This works trouble free.
I did delete both pythons and removed them from the system path just in case pyscripter looked for them. Then I installed 2.7 and set up the first scripter. I installed 34 and set up the second. Oddly, the scripters found the correct py each time - I imagine they go for the highest one. But you can also set that in scripter options. And frankly, it may not be necessary to delete py**. If not deleting them doesn't work you can just make a fresh copy of scripter and try again, since that will be a new standalone. For all I know you can reinstall python on the path once pyscripter is set up for each. I haven't tried that. Fiddle around. You can always make a new copy of the pyscripter standalone directory if things don't work out ;')
The interactions between the registry, the path, and the installed pyscripter just led to too many headaches.
Oh, pyscripter doesn't seem to play well with 3.4 but there's a fixed exe for your 3.4 standalone, here - just replace the 3.4 standalone python.exe with this one:
https://pyscripter.googlecode.com/issues/attachment?aid=7680027000&name=PyScripter-Updated.7z&token=ABZ6GAd40xS88r5vwgY9m8Y18vSFKN8q3g%3A1421517339924
I'm ask/answering this question because it hung me up & it's likely someone else will have the same problem.
Install of RabbitMQ x64 v2.8.6 on Windows Server 2008 x64.
After Erlang install using default install location to C:\Program Files\erl5.9.2, I'm attempting to start the server via running the rabbitmq-service.bat. Fail:
Please either set ERLANG_HOME to point to your Erlang installation
or place the RabbitMQ server distribution in the Erlang lib folder.
Problem is the .bat file does not have the correct subpath. with 5.9.2 (R15B02) version of erlang. My ERLANG_HOME directory is set correctly, but the script does not use it correctly for this version of Erlang, which, it appears to this Erlang noob to have a new subdirectory called "erts-5.9.2" which is causing the problems. Maybe someone intimate with these scripts can describe how to make this work correctly without the hack workaround I'm about to describe?
1- Set environment variable:
Variable name : ERLANG_HOME
Variable value: C:\Program Files (x86)\erl6.4
note: don't include bin on above step.
2- Add %ERLANG_HOME%\bin to the PATH environmental variable:
Variable name : PATH
Variable value: %ERLANG_HOME%\bin
This works well.
There are several RabbitMQ control .bat files on windows. Every one you use needs to get changed to reflect the Erlang path correctly. In this example, I'm editing the rabbitmq-server.bat because it's one of the easier ones... any of the .bat files you want to run will need this hack to get them to work, with the rabbitmq_service.bat file being the most involved to adjust.
editing that rabbitmq_server.bat file, you can see on about line 48 or so there's a check to see if the erl.exe is found, but the path isn't correct:
if not exist "!ERLANG_HOME!\bin\erl.exe" (
that path does not match the file structure for the 5.9.2 version of Erlang. I fixed this by simply removing this path check from about line 48 to 58, then, where the .bat actually makes a call to the erl.exe on about line 129 which reads:
"!ERLANG_HOME!\bin\erl.exe"
I simply hardcoded the path to my erl.exe:
"C:\Program Files\erl5.9.2\erts-5.9.2\bin\erl.exe"
With the pathing correct, the rabbitmq .bat files will run.
I had the similar issue, modifying ERLANG_HOME in .bat files did not work. Then I tried echo %ERLANG_HOME% in command prompt, that did not print the environment variable value(I could see that ERLANG_HOME environment variable has been created under advance system settings), that lead me to believe that I need to restart server for 64 bit installation of Erlang. After rebooting server, It worked like a charm. I hope this helps someone.
Just to share an up-to-date answer as of 2019: On Windows Server 2019, after setting up the environment variable, a restart is required to solve the problem.
I got into same kind of problem.
I solved it by doing three changes as given below.
Update Path variable "ERLANG_HOME" : "C:\Program Files\erl8.0" in Environment Variables.
Upadte "Path" variable "Path" : ";%ERLANG_HOME%\bin;"
Give urself FULL CONTROL permissions over "Program Files" in C drive.
It worked for me in this way.
This problem still occurs in Erlang 18.3 (erl7.3) and RabbitMQ 3.6.9 on Windows when upgrading from any older version of RabbitMQ to version 3.6.9. The solution as already stated here is to manually set ERLANG_HOME with 'setx -m ERLANG_HOME "C:\Program Files\erl7.3"' before starting the service.
What happens is that the RabbitMQ 3.6.9 installer removes the environment variable ERLANG_HOME from the system while removing the older version of RabbitMQ. Then, when it proceeds to the installation step, it does not put back the ERLANG_HOME variable. Then, the batch files that start up RabbitMQ cannot find Erlang. They try to find Erlang's home directory using "where.exe" but it always fails after an upgrade.
RabbitMQ's installer also does not kill all of the Erlang background processes, causing many of its files to be undeletable due to the Windows "file in use" problem. This leaves behind "files in use" in %APPDATA%\RabbitMQ and "C:\Program Files\RabbitMQ." These processes are "erl.exe," "erlsrv.exe," and "epmd.exe." The RabbitMQ installer should taskkill these processes after shutting down the RabbitMQ Windows service.
RabbitMQ is rather clunky on Windows.
Download Erlang or OTP - Only one Version of OTP should be installed
Download RabbitMQ installer
Install both exe file as Administrator
Set class path for Erlang. (Setting classpath is a bit troublesome, so follow these steps)
Set a new path with name ERLANG_HOME and value C:\Program Files\erl-23.1 (do not copy bin folder here)
Edit System "path" and add %ERLANG_HOME%\bin
Go to Start - Open rabbitmq command promt and run
rabbitmq-plugins enable rabbitmq_management
Navigate to localhost:15672
Use guest/guest to login
Interesting that this worked for you. There is record of a two bugs in Erl5.9.2 that cause an incomplete installation where %ERLANG_HOME%\bin is not installed.
Either of
* Installed 64bit erlang on 32bit machine
* "The program can't start because MSVCR100.dll is missing from your computer."
https://groups.google.com/d/topic/erlang-programming/wGtFLzapiQ0/discussion
Try 5.9.1 or any other version. They also mention making the future versions of the installer alert you if it fails.
I just had the same problem mentioned here. I installed otp_win64_R15B02 on a Windows 7 machine and everything worked perfectly, but I used the same installer on a Windows 2008 server and the bin directory was not created. I then uninstalled otp_win64_R15B02 and downloaded the otp_win64_R15B02_with_MSVCR100_installer_fix and the bin directory was created.
I suspect the reason it worked on my Windows 7 system is that I have Visual Studio installed and the required libraries were already available which allowed the otp_win64_R15B02 installer to work correctly.
Oh, and if you're installing Erlang to run RabbitMQ the RabbitMQ install will succeed with the broken installer but installing otp_win64_R15B02_with_MSVCR100_installer_fix after RabbitMQ will not work, just un-install and re-install RabbitMQ to resolve this.
Just give C:\Program Files\erl10.6\ not C:\Program Files\erl10.6\bin\erl.exe in the environment variable. If you open the server.bat file I came to know the issueenter image description here
I think this is encoding issue on windows.I see a correct value but I write echo %ERLANG_HOME% on console the value come with question mark. These steps fix it.
1.go environment variable window
2.edit ERLANG_HOME item
3.copy the value, open notepad and paste there
4.copy again on notepad and paste to edit window
5.apply and exit window
6.close command line tools and reopen
7.run rabbitmq bat file.
I solved it in a quick and dirty way,without naming path variables
I've opened the bat file and replaced every occurrence of
!ERLANG_HOME!\bin\erl.exe
with hard coded path for example might be diffrent path for you because of diffrent version
C:\Program Files\erl10.3\erts-10.3\bin\erl.exe
and replaced
%RABBITMQ_HOME%\escript\rabbitmq-plugins
with
C:\Program Files\RabbitMQ Server\rabbitmq_server-3.7.14\escript\rabbitmq-plugins
Even I was this problem. The issue was the environment variable ERLANG_HOME=c:\Program Files\erl9.0 which was never existed.
I cross checked the path. The correct path was c:\Program Files\erl9.3.
After correcting the
ERLANG_HOME=c:\Program Files\erl9.3
the problem solved. So, definitely it is a path issue.
In my case, it should be installed erlang using admin role running
If above solutions doesn't work for you then you can try following
Find another compatible version of erlang for your rabbit mq e.g. for rabbit 3.7.x erlang version 20.3.x to 22.0.x all are compatible .
Right click newly downloaded erlang version and from properties select the option to unblock the file .
Run the erlang with admin persssion .
Re run rabbit mq exe