I'm trying to install a program on a HPC cluster on which I do not have root access. I've been chasing a bunch of dependencies and trying to install them locally.
The original program requires mariadb, which apparently requires GLIBC 2.14/2.17 (cluster is on 2.12), which requires make 4.0 or higher (cluster has 3.81).
configure: error:
*** These critical programs are missing or too old: make bison python
*** Check the INSTALL file for required versions.
I've installed make 4.1 in a local directory, but cannot figure out how to point the configure file for GLIBC 2.35 towards that version of make.
Is there a way to redefine the environmental "make" command or to point a configure file towards a particular folder?
Just point the path to the directory first... export PATH=<dir_path_to_make>:${PATH}
Related
I'm trying to deploy an asp.net core 3.1 API on cloud foundry. I don't have admin rights, i just have developer rights. Is there a way to specify the URL of these libraries (libc6-dev, libgdiplus and libx11-dev) (maybe git or some official repository) so that i can execute the manifest.yml file during deployment and install these dependencies? Also to mention, i cannot turn on support for docker file on cloud foundry, as i get a message (insufficient rights)
I would suggest you give the apt-buildpack a try. You can give it additional Ubuntu package names, and it will install those for you.
You do that through an apt.yml file. Check out this post for instructions.
It's important to understand that the apt-buildpack will install these packages into a non-standard location. Since it also runs as a non-root user, it cannot install them into standard locations.
To work around this limitation, it sets variables like $PATH and $LD_LIBRARY_PATH to point to the locations where it has installed items. Most build tools will pick up these env variables and be able to locate what you install.
It's not perfect though, and some tools require additional env variables to be set. If you still get errors when building, look at your build tools and check if there are ways you can point to where apt-buildpack is installing stuff. The path it writes to can vary based on your buildpack order, but if you print out $PATH you can see the location. It's often /home/vcap/deps/0/... but the index can change based on your buildpack order.
When writing luarocks install gumbo
In the location/directory of my luarocks file in cmd, I am getting the following error
Warning: Could not find Lua 5.3 in PATH.
Modules may not install with the correct configurations. You may want to specify the path prefix to your build of Lua 5.3 using --lua-dir
Installing https://luarocks.org/gumbo-0.5-1.src.rock
Error: Failed finding Lua library. You may need to configure LUA_LIBDIR.
I've added lua53.exe to the same directory, and added the file both to my user variables and system variables in control panel.
Not sure if worth mentioning, but when running lua53.exe and trying to use luarocks install gumbo from there,
the lua53 cmd-like window responds with stdin:1: syntax error near 'install'
I was hoping to do some web scraping with lua, and later on building a World of Warcraft addon that utilizes gumbo to show certain helpful information within the WoW client, but I can't seem to even get the most basic stuff to work...
Setting up LuaRocks on Windows is annoying and I'm not familiar with it myself. If you added both the LuaRocks and Lua 5.3 Windows binaries (Executables and Includes) to your Path system variable:
luarocks path prints the commands for setting up the LUA_PATH and LUA_CPATH system variables.
The config.lua file tells you what your variables.LUA_LIBDIR value is. You can check it with luarocks config. For me that file would be in:
C:/Users/Ketho/AppData/Roaming/luarocks/config-5.3.lua
otherwise you can create an empty file there and put in this line to point it to wherever your Lua folder is:
variables.LUA_LIBDIR = "C:/lua-5.3.5_Win32_bin"
variables.LUA_INCDIR = "C:/lua-5.3.5_Win32_bin/include"
As for using gumbo to show information within WoW, the addon environment is sandboxed. Unless you meant you just want to get the data to hardcode into your addon.
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 need to install glibc static from source (I'm working on a server where I don't have root access) and I'm having some difficulties.
I downloaded the glibc-2.24.tar.gz from the GNU FTP, unpacked it and ran ./configure from another directory, as indicated in the instructions. I got the following message:
configure: WARNING:
*** These auxiliary programs are missing or incompatible versions: makeinfo
*** some features will be disabled.
*** Check the INSTALL file for required versions.
checking LD_LIBRARY_PATH variable... contains current directory
configure: error:
*** LD_LIBRARY_PATH shouldn't contain the current directory when
*** building glibc. Please change the environment variable
*** and run configure again.
First, should I bother about makeinfo? Second and more important, I don't understand the error concerning LD_LIBRARY_PATH. The path is not in this variable:
$ echo $LD_LIBRARY_PATH
:/usr/local/cuda/lib64
First, should I bother about makeinfo?
Only if you want configure to actually work. (By the way, your entire goal: "install glibc static from source" is likely based on incorrect assumptions and you probably shouldn't be attempting that).
Second and more important, I don't understand the error concerning LD_LIBRARY_PATH. The path is not in this variable:
$ echo $LD_LIBRARY_PATH
:/usr/local/cuda/lib64
That leading empty string before : is equivalent to ., i.e. it's the same as having LD_LIBRARY_PATH=.:/usr/local/cuda/lib64 and the warning is correct.
Is it possible to use Erlang with ZMQ on Windows? I have tried to use erlzmq2, but rebar fails to compile it with cryptic linker errors. Of course i can invest some time and investigate makefiles, but maybe other way exists?
Update
Whose who are interested in compilation errors can download latest erlang for windows and try to build erlzmq2 (Visual Studio 2012 compiler, msys sh and make). Error looks like:
cl : Command line error D8021 : invalid numeric argument '/Wl,-DLL,-IMPLIB:.libs
\zmq.dll.lib'
Makefile:541: recipe for target 'libzmq.la' failed
make[3]: *** [libzmq.la] Error 2
Please note that other erlang libs are compiling with this setup without any problems.
Your problem lies in compiling ZeroMQ for Windows. You haven't actually gotten to any Erlang yet. Here are some of the clues that tell you this:
Makefile:541: recipe for target 'libzmq.la' failed
This line says there's a problem on line 541 of the Makefile. But in erlzmq2, you can see that neither the main Makefile nor the c_src Makefile (which is what would build libzmq.la) has anything close to that many lines.
make3: * [libzmq.la] Error 2
The [3] means that you're 3 invocations deep into Make. Specifically, you started at the top-level Makefile, which called Rebar, which ran make -C c_src, which downloads ZeroMQ version 3.2.2 and tries to do a ./configure && make
To fix this Unix-style, go into the deps directory of erlzmq2 and figure out how to correctly compile ZeroMQ. Hopefully, you will just need to pass some arguments to configure. Then you can edit c_src/Makefile and set ZMQ_FLAGS to whatever you had to do for configure, clean, and make.
To fix it more Windows-style, follow the Windows build instructions for ZeroMQ. Put the compiled libzmq under deps and just edit the c_src Makefile to a no-op.
Finally, if you don't actually need to run this code on Windows, but are just using Windows as your development environment, I think you'll have the easiest time by running the build inside a Linux VM (not a hard thing at all with tools like Vagrant). Sorry, but Unix is the real system for this stuff; Windows support is an afterthought.