When trying to link to a system-installed library through Swift Package Manager, specifying it under pkgConfig, it says that the installed package wasn't found in the pkg-config search path. It suggests finding the .pc file that comes with the module but there isn't one.
How do I go about linking the library with SPM?
The way I went about it is creating the .pc file and putting it into /usr/local/lib/pkgconfig, where .pc files are kept, on your own.
.pc files essentially follow the following format:
Defined variables
Name, Description, Version
Libs and Cflags
So for example:
prefix=/usr/local/ModuleFolder
libdir=${prefix}/lib
includedir=${prefix}/include
Name: samplemodule
Description: Appears in a Stack Overflow answer.
Version: 1.0.0
Libs: -L${libdir}
Cflags: -I${includedir}
You can check if pkg-config now detects the file with pkg-config yourmodule --libs --cflags and if so then it should work in Package.swift as well.
If the application was installed through Homebrew, the missing .pc file issue should probably be reported to the developers, although they may not want to implement it in some cases.
More info on pkg-config files can be found at https://people.freedesktop.org/~dbn/pkg-config-guide.html
Related
I got the following error when I use homebrew. Does anybody know how to fix the problem?
dyld: Library not loaded: /usr/local/opt/libffi/lib/libffi.6.dylib
Referenced from: /usr/local/Cellar/pypy/7.1.1_1/libexec/lib/libpypy-c.dylib
Reason: image not found
Here is the output of brew doctor.
$ brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!
Warning: Some installed formulae were deleted!
You should find replacements for the following formulae:
inchi
python#2
libmpc#0.8
pygtk
isl#0.11
f2c
indigo
mpfr#2
gmp#4
phantomjs
phantomjs
rdkit
casperjs
mumps
ecj
pygobject
isl#0.12
gcc#4.8
gcc#4.8
Warning: Calling a Formula#patches definition is deprecated! Use 'patch do' block calls instead.
Please report this issue to the docmunch/pdftk tap (not Homebrew/brew or Homebrew/core), or even better, submit a PR to fix it:
/usr/local/Homebrew/Library/Taps/docmunch/homebrew-pdftk/pdftk.rb:15
Warning: You have the following deprecated, official taps tapped:
Homebrew/homebrew-dupes
Homebrew/homebrew-fuse
Homebrew/homebrew-head-only
Homebrew/homebrew-versions
Homebrew/homebrew-x11
Untap them with `brew untap`.
Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and which additional flags to use when
compiling and linking.
Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew-provided
script of the same name. We found the following "config" scripts:
/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7-config
/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7m-config
/Library/Frameworks/Python.framework/Versions/3.7/bin/python3-config
/Library/Frameworks/Python.framework/Versions/2.7/bin/python2-config
/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7-config
/Library/Frameworks/Python.framework/Versions/2.7/bin/python-config
Warning: Putting non-prefixed coreutils in your path can cause gmp builds to fail.
Warning: Putting non-prefixed findutils in your path can cause python builds to fail.
Warning: Unbrewed dylibs were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected dylibs:
/usr/local/lib/libgcc_ext.10.4.dylib
/usr/local/lib/libgcc_ext.10.5.dylib
/usr/local/lib/libgcc_s.10.4.dylib
/usr/local/lib/libgcc_s.10.5.dylib
/usr/local/lib/libgcc_s_x86_64.1.dylib
/usr/local/lib/libgfortran.2.0.0.dylib
/usr/local/lib/libgfortran.3.dylib
/usr/local/lib/libgomp.1.dylib
/usr/local/lib/libpocketsphinx.3.dylib
/usr/local/lib/libpostal.1.dylib
/usr/local/lib/libquadmath.0.dylib
/usr/local/lib/libsphinxad.3.dylib
/usr/local/lib/libsphinxbase.3.dylib
/usr/local/lib/libtcl8.6.dylib
/usr/local/lib/libtk8.6.dylib
/usr/local/lib/libwkhtmltox.0.12.1.dylib
/usr/local/lib/libwkhtmltox.0.12.2.dylib
/usr/local/lib/libwkhtmltox.0.12.4.dylib
Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected header files:
/usr/local/include/fakemysql.h
/usr/local/include/fakepq.h
/usr/local/include/fakesql.h
/usr/local/include/itcl.h
/usr/local/include/itcl2TclOO.h
/usr/local/include/itclDecls.h
/usr/local/include/itclInt.h
/usr/local/include/itclIntDecls.h
/usr/local/include/itclMigrate2TclCore.h
/usr/local/include/itclTclIntStubsFcn.h
/usr/local/include/libpostal/libpostal.h
/usr/local/include/mysqlStubs.h
/usr/local/include/node/js_native_api.h
/usr/local/include/node/js_native_api_types.h
/usr/local/include/node/libplatform/libplatform-export.h
/usr/local/include/node/libplatform/libplatform.h
... /usr/local/include/tclPlatDecls.h
/usr/local/include/tclThread.h
/usr/local/include/tclTomMath.h
/usr/local/include/tclTomMathDecls.h
/usr/local/include/tdbc.h
/usr/local/include/tdbcDecls.h
/usr/local/include/tdbcInt.h
/usr/local/include/tk.h
/usr/local/include/tkDecls.h
/usr/local/include/tkPlatDecls.h
/usr/local/include/wkhtmltox/image.h
/usr/local/include/wkhtmltox/pdf.h
Warning: Unbrewed .la files were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .la files:
/usr/local/lib/libgfortran.la
/usr/local/lib/libgomp.la
/usr/local/lib/libpocketsphinx.la
/usr/local/lib/libpostal.la
/usr/local/lib/libquadmath.la
/usr/local/lib/libsphinxad.la
/usr/local/lib/libsphinxbase.la
Warning: Unbrewed .pc files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .pc files:
/usr/local/lib/pkgconfig/libpostal.pc
/usr/local/lib/pkgconfig/pocketsphinx.pc
/usr/local/lib/pkgconfig/sphinxbase.pc
/usr/local/lib/pkgconfig/tcl.pc
/usr/local/lib/pkgconfig/tk.pc
Warning: Unbrewed static libraries were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected static libraries:
/usr/local/lib/libgfortran.a
/usr/local/lib/libgomp.a
/usr/local/lib/libpocketsphinx.a
/usr/local/lib/libpostal.a
/usr/local/lib/libquadmath.a
/usr/local/lib/libsphinxad.a
/usr/local/lib/libsphinxbase.a
/usr/local/lib/libtclstub8.6.a
/usr/local/lib/libtkstub8.6.a
Warning: You have unlinked kegs in your Cellar.
Leaving kegs unlinked can lead to build-trouble and cause brews that depend on
those kegs to fail to run properly once built. Run `brew link` on these:
inchi
mpich
ssed
python
libmpc#0.8
nss
isl#0.11
numpy
mpfr#2
gmp#4
poppler
nspr
scipy
gcc#4.8
Warning: Some installed formulae are not readable:
indigo: Unsupported special dependency :python
rdkit: Unsupported special dependency :python3
Warning: Your Xcode (10.3) is outdated.
Please update to Xcode 11.3.1 (or delete it).
Xcode can be updated from the App Store.
Warning: Broken symlinks were found. Remove them with `brew cleanup`:
/usr/local/share/man/man5/package-lock.json.5
/usr/local/share/man/man7/removing-npm.7
Warning: Some installed formulae are missing dependencies.
You should `brew install` the missing dependencies:
brew install imlib2 libcaca opusfile
Run `brew missing` for more details.
This is a duplicate of issue 3229 on the PyPy issue tracker. It seems our buildbot is using a brew installed version of libffi. Until we solve this, you should be able to do brew install pypy3. Help from someone who can make the PyPy build look more like the CPython one (which apparently does not have this problem) are welcome.
I'm attempting to create a Homebrew formula for gtk-mac-integration. Running make in bindings/python/gtkosx_application fails:
/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: can't open file '/usr/local/Cellar/gtk-mac-integration/2.0.7/share/pygobject/2.0/codegen/h2def.py': [Errno 2] No such file or directory
make[3]: *** [gtkosx_application.defs] Error 2
This is because the Makefile tries to find the h2def.py file in the wrong location:
gtkosx_application.defs: $(headers)
$(PYTHON) $(datadir)/pygobject/2.0/codegen/h2def.py $(headers) > $#
It is clear to me why this is failing: $(datadir) points to the share directory of the package that is to be installed (gkt-mac-integration). Because Homebrew installs all packages into their own prefix (/usr/local/Cellar/...), it is not the same for gtk-mac-integration and pygobject.
I know it is possible to find out where the pygobject data directory is located using
pkg-config --variable=datadir pygobject-2.0
I don't suppose the correct fix is to replace datadir in the Makefile with the string above? How should I adjust configure.ac and Makefile.am to make this work properly?
Yeah, that sounds like a bug in the build system.
You can use the inreplace facility to patch this up. Insert this after def install:
inreplace %w[bindings/python/gtkmacintegration/Makefile.am
bindings/python/gtkmacintegration/Makefile.in
bindings/python/gtkosx_application/Makefile.am
bindings/python/gtkosx_application/Makefile.in],
'$(datadir)/pygobject', |
%x[pkg-config --variable=datadir pygobject-2.0].chomp + '/pygobject'
(I tried this out. The formula builds after that.)
You should report this upstream. They should change their build system to sort this out in their configure script.
I downloaded the source of LuaJIT and compiled it with msvc120.dll (VS 2013 x64). When I run it from the command line I have no problems executing some basic lua. Now the LuaJIT installation guide mentions moving luajit.exe and lua51.dll into their own folder. From there it says to create a lua folder and under that a jit folder with the contents of src/jit moved underneath the newly created jit folder.
From my understanding my folder should look like and contain:
luajit.exe
lua51.dll
/lua
/jit
bc.lua
[rest of jit files]
vmdef.lua
Is this correct or am I missing files?
Now after I built my luajit I tried to wire it up into my luarocks to act as my interpreter using
install.bat /LUA C:\LuaJIT\2.0.3\[folder with above content]
However this cannot find the header files. I then copied over what are the header files into the folder above and that wires it up, but I can never actually get anything to compile when pointed over to LuaJIT. Edit: The error I get is the following,
C:\LuaJIT\2.0.3\bin\lua51.dll : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2D0
Error: Failed installing dependency: https://rocks.moonscript.org/luafilesystem-1.6.2-2.src.rock - Build error: Failed compiling module lfs.dll
Is the correct way to handle this to simply point to my lua binaries and from there leverage LuaJIT to run my files or am I doing something wrong with wiring up LuaJIT and luarocks? The former seems to work for the most part, since I only ran into one library compilation issue, lua-cjson.
I've run on exactly the same problem, but they've found a solution right here:
https://github.com/keplerproject/luafilesystem/issues/22
I knew that for "linking DLLs statically" there is a so-called "export" .lib file, which is passed to the linker (and not the DLL itself).
So, for example, when compiling, LuaRocks was doing this:
cl /nologo /MD /O2 -c -Fosrc/mime.obj -ID:/LuaJIT-2.0.4/include/ src/mime.c -DLUA_COMPAT_APIINTCASTS -DLUASOCKET_DEBUG -DNDEBUG -DLUASOCKET_API=__declspec(dllexport) -DMIME_API=__declspec(dllexport) mime.c
link -dll -def:core.def -out:mime/core.dll D:/LuaJIT-2.0.4/bin/lua51.dll src/mime.obj
My LuaJIT was compiled from source in D:\LuaJIT-2.0.4\src, but I made two folders myself: D:\LuaJIT-2.0.4\include with all *.h files copied from src and D:\LuaJIT-2.0.4\bin with luajit.exe, lua51.dll, and then later lua51.exp and lua51.lib. Still same error, but this was the right track.
Fix
Now, check where your LuaRocks configs are:
luarocks.bat help
Scroll down to a section like:
CONFIGURATION
Lua version: 5.1
Configuration files:
System: D:/luarocks/config-5.1.lua (ok)
User : (... snip ...)
Edit the System configuration file, specifically see the part:
variables = {
MSVCRT = 'VCRUNTIME140',
LUALIB = 'lua51.dll'
}
Here! LUALIB should be the .lib file. If your export lib is alongside the DLL, you just need to change to:
variables = {
MSVCRT = 'VCRUNTIME140',
LUALIB = 'lua51.lib' -- here!
}
Verification
And now:
luarocks.bat install luasocket
(...)
link -dll -def:core.def -out:socket/core.dll D:/LuaJIT-2.0.4/bin/lua51.lib src/luasocket.obj (...)
(...)
luasocket 3.0rc1-2 is now built and installed in D:\luarocks\systree (license: MIT)
Note the first argument passed to the linker.
I need to compile OpenCV statically linked with libstdc++ to avoid problems of different dll versions of libstdc++-6.dll needed by Qt5 and OpenCV. Following the steps of this article: http://www.argong.com/docs/how-to-OpenCV-2.2.0.pdf and adding the lines below to CMakeLists.txt i expected to get the OpenCV DLLs statically linked with libstdc++, but the OpenCV continues dependent of the libstdc++-6.dll. What i'm doing wrong to get the OpenCV libraries statically linked with libstdc++?
if (MINGW)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -static-libgcc")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -static-libgcc -static-libstdc++")
set(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "${CMAKE_SHARED_LIBRARY_LINK_C_FLAGS} -static-libgcc -s")
set(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "${CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS} -static-libgcc -static-libstdc++ -s")
endif()
First ensure you're not pulling dependencies on libraries that link on shared system libraries. You can for example enable compilation of bundled source components like zlib, jpeg, etc., with flags BUILD_ZLIB, BUILD_JPEG, etc. You can also disable dependencies on optional components like Vtk (WITH_VTK flag) and others that may be already present in the system as shared libraries. Then, if you are building OpenCV as a shared library, push the setting on the shared linker flags variable (CMAKE_SHARED_LINKER_FLAGS) in the cache with cmake -C command:
set(CMAKE_SHARED_LINKER_FLAGS "-static -static-libgcc -static-libstdc++" CACHE INTERNAL "" FORCE)
Alternatively, if you are compiling OpenCV statically with -DBUILD_SHARED_LIBS=FALSE, you can plug gcc linker flags for static linking on your final shared object or executable.
I hope you can help me.
I have a simple CMakeLists.txt in order to build my project on Leopard 10.5.8.
I'm using CMake 2.8.1 and at the moment this is the code:
cmake_minimum_required(VERSION 2.8)
MESSAGE(STATUS "./src: Going into utils folder")
ADD_SUBDIRECTORY(utils)
MESSAGE(STATUS "./src: utils folder processed")
include_directories(${DIR}/headers)
link_directories (${DIR}/src/utils)
ADD_EXECUTABLE(sample sample.cpp)
TARGET_LINK_LIBRARIES(sample libSample ${EXTERNAL_LIBS})
INSTALL(TARGETS sample DESTINATION "./src")
MESSAGE(STATUS "./src: exiting src folder")
I need to add OpenCV libraries on my project.
When I use Eclipse I set the include path to /opt/local/include
and the libraries path to: /opt/local/lib and then I specify the libraries name such as_ opencv_core, opencv_imgproc, opencv_video.
Can you tell me how to add these information in the CMakeLists.txt file, please?
I've read some information in the official cmake FAQ but i wasn't able to solve my problem.
Please, help me.
Thanks a lot.
You need to add the library names in the TARGET_LINK_LIBRARIES command, but you need to add them without the lib prefix. For example:
include_directories(${DIR}/headers /opt/local/include)
link_directories (${DIR}/src/utils /opt/local/lib)
ADD_EXECUTABLE(sample sample.cpp)
TARGET_LINK_LIBRARIES(sample opencv_core opencv_imgproc opencv_video ${EXTERNAL_LIBS})