I was trying out the godal library and wrote a simple script as follows:
package main
import (
"github.com/airbusgeo/godal"
)
func main() {
godal.RegisterAll()
}
Running go run main.go throws the following error
dyld[19569]: Library not loaded: #rpath/libgdal.30.dylib
Referenced from: /private/var/folders/y5/yh59dj093xn_dz8lm0mhv6lh0000gp/T/go-build1573968352/b001/exe/test
Reason: tried: '/usr/local/lib/libgdal.30.dylib' (no such file), '/usr/lib/libgdal.30.dylib' (no such file)
signal: abort trap
godal has a dependency on gdal and I had installed it via conda. Due to this, the dylib is located under my conda folder - /Users/ash/miniconda3/lib not /usr/local/lib.
How can I have the program search for libgdal.dylib in /Users/ash/miniconda3/lib instead of /usr/local/lib ?
You could try setting GDAL_LIBRARY_PATH=/Users/ash/miniconda3/lib/libgdal.dylib
You can try this in both the shell where you run go run .... or as an os.Setenv("GDAL_LIBRARY_PATH", "/Users/ash/miniconda3/lib/libgdal.dylib")
Add the path to the miniconda3 lib directory to the DYLD_FALLBACK_LIBRARY_PATH environment variable. In your case, that would be:
DYLD_FALLBACK_LIBRARY_PATH=/Users/ash/miniconda3/lib:$DYLD_FALLBACK_LIBRARY_PATH YourGoExecutable
Note: Don't use DYLD_LIBRARY_PATH, as this will clobber existing path resolution, and mostly likely result in unintended trouble down the line.
Related
I am trying to install omni compiler in order to compile XcalableMP programs on OSX. I can ./configure successfully as per the instructions but am receiving this error when I make:
../include/xmp_internal.h:19:10: fatal error: mpi.h: No such file or directory
My Open MPI is installed via homebrew and mpi.h is located through my Cellar folder. How do I go about including this header file?
can you try the following command to be sure the location of the installed openmpi is correct:
mpicc -showme
Then, are you sure the mpi path is in your path, try to set these environment variables and then try:
Note that I assume the openmpi is installed in "/home/openmpi" path for example:
export PATH=/home/opempi/bin:/home/opempi/include:$PATH
and for the runtime:
export LD_LIBRARY_PATH=/home/openmpi/lib:$LD_LIBRARY_PATH
Then try to configure and make again the omnicomppiler,
We use cx_Freeze to produce standalone binary build of our python application under Mac OS. The build runs well under the build machine (which has Homebrew-and-Python installed), but failed in client machine with following error messages.
Traceback (most recent call last):
File "/usr/local/lib/python2.7/site-packages/cx_Freeze/initscripts/__startup__.py", line 14, in run
module.run()
File "/usr/local/lib/python2.7/site-packages/cx_Freeze/initscripts/Console.py", line 26, in run
exec(code, m.__dict__)
File "./utest2.py", line 15, in <module>
from ttLib import *
File "ttLib.py", line 848, in init ttLib
import ctypes
File "/usr/local/Cellar/python#2/2.7.15_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 7, in <module>
from _ctypes import Union, Structure, Array
ImportError: dlopen(/Users/gff/src/TextSeek_test/build/test_build/lib/_ctypes.so, 2): Symbol not found: __PySlice_AdjustIndices
Referenced from: /Users/gff/src/TextSeek_test/build/test_build/lib/_ctypes.so
Expected in: flat namespace
in /Users/gff/src/TextSeek_test/build/test_build/lib/_ctypes.so
By browsing stackoverflow answers about "__PySlice_AdjustIndices" and "flat namespace", we suspect this error was caused by the python conflict between system-default version and homebrew version.
Then we use "brew install python#2" in client machine, and the ctypes error disappeared. We run "brew uninstall python#2", this error returned back.
The question is : how can we embed necessary part of homebrew-python to bypass this ctype error?
We used "otool -L lib/_ctypes.so" to know the depenency of dynamic-linked file, it only showed out one file "/usr/lib/libSystem.B.dylib". This file seems to have no relation with python.
Any advice to move forward?
Dev Machine Info: Mac High Sierra, python 2.7.15 64bit. Use homebrew-python to build.
setup.py for cx_Freeze :
build_exe_options = {
"packages": ["wcwidth", "watchdog", "xlrd", "jinja2", "subprocess"],
"excludes": [ "AppKit", "Carbon", "CoreFoundation", "Finder", "Foundation", "FSEvents", "objc"],
"include_msvcr": True,
"zip_include_packages":["winshell", "wcwidth", "watchdog", "pyhk", "xlrd", "jinja2",\
"argh", "ctypes", "email", "encodings" ]
}
exeList = [Executable( "utest2.py", base = None, targetName= "utest") ]
setup( name = "XXX",
description = u"XXX desc",
options = {
"build_exe": build_exe_options,
'bdist_mac': {
'bundle_name': "XXX",
}
},
executables = exeList)
I found the solution by myself.
This issue is caused by wrongly linked dylib files. We use "otool -L" to find the dependency and re-link them with "install_name_tool -change" one by one. Finally the program works.
On the client machine, after installation of the frozen application, try to manually copy all dynamic libraries (.so, .dylib, ...?) which are in the lib subdirectory of the build directory into the build directory itself. Copy also all dynamic libraries which are in the build directory into its lib subdirectory. Does this solve the problem? On the build machine, you should of course use the same python version to produce the frozen application than you use to run the unfrozen application.
If 1. solves the problem, find out which dynamic libraries need to be copied in order that the application works (i.e. find out which of the manual copy actions you've done are really necessary). Use the include_files list of the build_exe options in your setup script to let cx_Freeze include the dynamic library automatically at the build step. You can use a tuple (source, destination) as item in the include_files list to let cx_Freeze copy a file from source to a specific destination into the build directory.
Explanation: I don't know Mac/OS. But I believe the issue you describe could be related to a similar issue with Microsoft Visual C++ Redistributable DLLs under Windows: cx_Freeze 5.1.1 includes packages in a lib subdirectory of the build directory, in the previous versions of cx_Freeze they used to be in the build directory itself. Some dynamic libraries need to be found in the build directory but are erroneously included in the lib subdirectory by cx_Freeze or vice versa. On the build machine it is usually not a problem, because a copy of the library is usually found in the system path, but on the client machine often no copy of the library can be found on the system path, or an incompatible one.
By the way the build_exe option "include_msvcr": True does not seem to work in cx_Freeze5.1.1, see this issue.
I had been trying to install tensorflow for a few day. However, cuda 7.5 is the version that tensorflow r0.10.0 supports default. So I can only install it from source. But I came after the following problem which bother me a lot.
.....
INFO: Reading options for 'clean' from /home/lhx/tensorflow-r0.10/tools/bazel.rc:
Inherited 'build' options: --force_python=py2 --host_force_python=py2 --python2_path=/usr/bin/python --define=use_fast_cpp_protos=true --define=allow_oversize_protos=true --define PYTHON_BIN_PATH=/usr/bin/python --spawn_strategy=standalone --genrule_strategy=standalone
Unrecognized option: --host_force_python=py2
ERROR: /home/lhx/tensorflow-r0.10/WORKSPACE:18:6: First argument of load() is a path, not a label. It should start with a single slash if it is an absolute path..
ERROR: /home/lhx/tensorflow-r0.10/WORKSPACE:22:6: First argument of load() is a path, not a label. It should start with a single slash if it is an absolute path..
ERROR: WORKSPACE file could not be parsed.
ERROR: package contains errors: third_party/boringssl.
ERROR: no such package 'external': Package 'external' contains errors.
Configuration finished
I just can't figure out what is going wrong and I have been trying for so long.
I experienced similar errors when my bazel was too outdated. You can try newer bazel version.
Here is the command I typed:
clang++ -Iboost -Ijpeg_lib/include/ -Ljpeg_lib/lib/ -ljpeg.9 mandelbrot.cpp
The directory structure is like this:
mandelbrot.cpp
/boost
/jpeg_lib/lib/
libjpeg.9.dylib
/jpeg_lib/include/
The compilation is successful, but when I run the binary file, an error occurs:
dyld: Library not loaded: /usr/local/lib/libjpeg.9.dylib
Referenced from: /Users/hanxu/Documents/./a.out
Reason: image not found
Trace/BPT trap: 5
I have specified the library searching path to jpeg_lib/include/, why does the program still search at /usr/local/lib ?
You should include the directory where libjpeg.9.dylib lives in LD_LIBRARY_PATH, which is required to locate the libraries at runtime:
export LD_LIBRARY_PATH=/path/to/libjpeg
Have you checked permissions on your jpeg_lib ? If you installed whatever it is you are running as root and then ran as yourself this may have happened.
I just had the same error message with running GD graphics from a Perl cgi after a portmanteau install as root and found that the /usr/local/lib directory in which my libjpeg.9.dylib resides had permissions 700. Changing to 755 (like all the other directories in /usr/local) solved the problem.
To install luarocks, I downloaded the most recent (2.0.11) tar.gx file from here. I unpacked it, and followed the instructions.
$ ./configure
Lua interpreter found: /usr/local/bin/lua...
Lua version detected: 5.1
Looking for Lua...
lua found in $PATH: /usr/local/bin
Checking Lua includes...
lua.h found in /usr/local/include/lua.h
curl found at /usr/bin
openssl found at /opt/local/bin
Configuring for system...
Darwin
Configuring for architecture...
i386
Writing configuration...
Installation prefix: /usr/local
LuaRocks configuration directory: /usr/local/etc/luarocks
Using Lua from: /usr/local
Done. You can now run 'make' to build.
I then ran sudo make install, and finally tried installing a package but when I try to run it I get this error:
$ sudo luarocks install lpeg
/usr/local/bin/lua: /usr/local/share/lua/5.1//luarocks/cfg.lua:355: attempt to call global 'tonumber' (a nil value)
stack traceback:
/usr/local/share/lua/5.1//luarocks/cfg.lua:355: in main chunk
[C]: in function 'require'
/usr/local/share/lua/5.1//luarocks/command_line.lua:6: in main chunk
[C]: in function 'require'
/usr/local/bin/luarocks:4: in main chunk
[C]: ?
Running lua manually, tonumber works just fine as does everything else. I don't know why it's failing here.
At the top of cfg.lua you need to add
local tonumber = tonumber
before the module call. You can include tonumber in both lines of the list of similar local definitions. You can make these changes in the installed version in /usr/local/share/lua/5.1//luarocks/cfg.lua or in the source version and make install once again.
This is a bug in luarocks and will be fixed in the next release.
My modified luarocks-2.0.11/src/luarocks/cfg.lua contains:
local rawset, next, table, pairs, require, io, os, setmetatable, pcall, ipairs, package, type, assert, tonumber, _VERSION =
rawset, next, table, pairs, require, io, os, setmetatable, pcall, ipairs, package, type, assert, tonumber, _VERSION
module("luarocks.cfg")