I am, trying to find the gstreamer lib in windows (msvc) using pkg-config
pkg-config gstreamer-0.10 --cflags --libs
but i am getting any result like this
Package gstreamer-0.10 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gstreamer-0.10.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gstreamer-0.10' found
a .pc like is created when a library is installed (automatically through the use of an RPM, deb, or other binary packaging system or by compiling from the source).I can't find the .pc file in my gstreamer directory.
Should i just create a .pc file with all the necessary details.
prefix=C:\Program Files (x86)\OSSBuild\GStreamer\v0.10.7
exec_prefix=${prefix}
libdir=${exec_prefix}\lib
includedir=${prefix}\sdk\include\gstreamer-0.10
toolsdir=${exec_prefix}\bin
pluginsdir=${exec_prefix}\lib\gstreamer-0.10
datarootdir=${prefix}\share
datadir=${datarootdir}
girdir=${datadir}/gir-1.0
typelibdir=${libdir}/girepository-1.0
Name: GStreamer
Description: Streaming media framework
Requires: glib-2.0, gobject-2.0, gmodule-no-export-2.0, gthread-2.0, libxml-2.0
Version: 0.10.35
Libs: -L${libdir} -lgstreamer-0.10
Cflags: -I${includedir}
or there is any other way to do this or Am i missing somthing?
Hope you can help.Thankz for taking the time to read the problem.
Well i am doing this to find solution why i am getting not found message in my waf configure for gstreamer
conf.check_cfg(atleast_pkgconfig_version='0.0.0')
conf.check_cfg(package='gstreamer-0.10', uselib_store='GSTREAMER', args='--cflags --libs', mandatory=True)
the code works in linux and is supposed to work in windows too.
ADDED LATER
Well making the .pc and setting a path of the .pc dir to the PKG_CONFIG_PATH environment variable does the trick.Its not hard do it
Check out this out. Thankz for readings and helping me..:)
pkg-config is a great tool but unfortunately on Windows (vs. UNIX) there is no standard executable PATH or PKG_CONFIG_PATH.
While you can revert to defining options --with-gstreamer-include-dir ... --with-gstreamer-lib-dir ... and avoid the pkg-config dependency, you can also use --pkgconfig-exe c:\path\to\pkg-config.exe --pkgconfig-path c:\path\to\gstreamer;c:\path\to\otherlib, which will help having a good-looking wscript, especially when using a lot of pkg-config libs.
The typical Win32 user may have issues setting PKG_CONFIG_PATH and PATH directly or stumbling onto a cryptic "not found" error and then checking config.log.
If you do add the windows-specific pkg-config options, it might be interesting for everybody.
You could write a pkgconfig_opts tool and submit it as a waf extra.
Related
How can I link libxml on MinGW when using an omnetpp shell?
I am using omnetpp on a windows 10 machine.
My problem happens when I am trying to install the 3rd party package from here
I think that there is a problem in the Makefile failing to locate the libxml library
Following Rudi's answer (following the question) I changed the Makefile libxml path to I/mingw64/include/libxml2 but I still
get a undefined reference to 'xmlFunctionName' error (for many function names)
I tried to isolate the problem and to compile a sample of code from libxml2
Following the compilation guide: using gcc `xml2-config --cflags --libs` -o tree2 tree2.c
I got a fatal error: 'libxml/parser.h' file not found
When I replaced xml2-config --cflags --libs with -I/mingw64/include/libxml2
I got the same error as before undefined reference to 'xmlFunctionName'
what can I do to resolve that issue?
To this specific problem: libxml2 is actually already present as OMNET 5.x also uses it. All dependencies and tools are available in the tools/win64/mingw64 directory. The problem is that (for unknown reasons) the include file of the include/libxml2/libxml folder. The configure script correctly detects this and makes it available in the Makefile.inc as XML_CFLAGS= = -I/mingw64/include/libxml2
This must be added to the compiler flags for each file where you want to use the XML parser. (the library files are in the /mingw64/lib folder) so those are detected and can be used without additional config.
Generally, third party libraries should be available in the /mingw64/include and /mingw64/lib folders. You can either copy them manually there or try to install it with the mingw package manager (however that will most likely ruin your omnet installation as mingw64 is not particularly consistent and it is a rolling release - i.e. this is highly not recommended).
When using a tool like pkg-config (see here), how is one supposed to know what the library name should be? It is not always intuitive. DLIB, for example, doesn't work for
pkg-config --cflags dlib
pkg-config --cflags libdlib
pkg-config --cflags dlib-19.9
I usually have to issue a command like sudo ldconfig -p | grep dlib, but all that does is return libdlib.so, which also doesn't work.
How do experts tackle this problem. Do they simply know all the library names?
It is called package name what you are using as a main parameter for pkg-config, and then applying --cflags or --libs, etc one just accesses the parameters specified and evaluated from the corresponding package config file ([some_package_name].pc, a.k.a pkg-config metadata file) that was found in pkg-config search paths.
And yes, there is no rule how package name relates to library name. Typically it's either library name without lib- prefix or just the whole library name. I found the following in pkg-config guide:
A common choice is to match the library name to the .pc name.
For instance, a package installing libfoo.so would have a
corresponding libfoo.pc file containing the pkg-config metadata. This
choice is not necessary; the .pc file should simply be a unique
identifier for your library. Following the above example, foo.pc or
foolib.pc would probably work just as well.
However, you can list all available in pkg-config search paths and find out the correct names before using them in Makefile:
$ pkg-config --list-all | grep dlib
I have installed QT 4.8 library on my OS X through direct install with .dmg file downloaded from qt-project.org. It seems a framework version. And so far, a lot of tools recognises it well. But when I am building octave on this computer, it gives a warning of "Qt libraries not found". I wonder why. And what can I do to make it recognise the qt lib on my machine.
The command I used for configure is
./configure --prefix=/usr/local --enable-shared F77=gfortran-4.2 LDFLAGS='-L/usr/local/lib'
(further information)
I did tried to find the installation of QT with
find find /Library/ -name QtGui
Returning result being
/Library//Frameworks/QtGui.framework/QtGui
/Library//Frameworks/QtGui.framework/Versions/4/Headers/QtGui
/Library//Frameworks/QtGui.framework/Versions/4/QtGui
Along with the fact that ipython notebook --matplotlib=qt is working well on my system, I assume my Qt Library is successfully installed.
But when performing the check with pkg-config, both pkg-config --cflag QtGui and pkg-config --libs QtGui return no positive result.
Make sure your Qt installation is working. I'll assume it was correctly installed and is visible to the operating system you're using.
The configure command you have pasted accepts two environment variables, QT_CFLAGS and QT_LIBS. Use the pkg-config tool to determine their appropriate values:
pkg-config --cflags QtGui
pkg-config --libs QtGui
and add this information to the command line:
./configure QT_CFLAGS='foo' QT_LIBS='bar' # other stuff...
I think I know the answer now. qt-4.8 installed through .dmg file is a framework version. There is no Qt*.pc file, thus is not able to be found by pkg-config. So, in order to use pkg-config to find qt installed in the system, you need to build qt from source(source downloadable from qt-project.org), specifying that a -no-framework version is to be built:
./configure -no-framework --foo --bar
make
sudo make install
After building and installing, qt would be located in(by default)
/usr/local/Trolltech/Qt-4.8.6/lib/pkgconfig/
Thus adding a line to ~/.bashrc
export PKG_CONFIG_PATH="/usr/local/Trolltech/Qt-4.8.6/lib/pkgconfig/:${PKG_CONFIG_PATH}"
would help pkg-config locating the qt in your system.
If you have installed QT by .run file, you might find pkgconfig folder. For me, I have installed QT to "/opt/qt5.15.x/" and I find this path "/opt/qt5.15.x/5.15.2/gcc_64/lib/pkgconfig". Referencing pkg-config-path-environment-variable, I add it to PKG_CONFIG_PATH by
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/qt5.15.x/5.15.2/gcc_64/lib/pkgconfig/
And then, Octave configure find QT. And it's better to check the .pc file in your pkgconfig folder. "prefix" in the .pc files might be wrong.
I'm using Cygwin on windows to run this command:
g++ `pkgconfig --libs --cflags opencv` -I. -o mergevec mergevec.cpp ....
But I get an error:
-bash: pkg-config: command not found
I've installed cygwin directly on C:. I've added to the PATH environment variable the following:
C:\cygwin64\bin;
C:\cygwin64\lib
I've run cygcheck -c and it gives me a whole list of packages, but pkg-config isn't in that list.
There is a folder called pkgconfig in C:\cygwin64\lib though.
How do I fix this error?
pkg-config is a piece of software that allow your computer to check installed libraries for source compilation. It may not be installed on Windows so in last scenario please check for install.
However in your case i think it is installed, but not set on the right path for linux commands. Try to type in cygwin:
$ export PKG_CONFIG_PATH=c:\\cygwin\\usr\\local\\lib\\pkgconfig
as stated in this post.
Otherwise just abandon Windows and try to compile mergevec on an Linux VM, which is really easier (it was made for it). The only down point of this method is that you will have to do the mergevec operation (and the ones before, otherwise you may have encoding problems) under your linux space. See my previous answer for this manipulation.
If any problem don't hesitate.
run cgywin setup and in package search type pkg-config then make sure that pkg-config utility is installed.
it should solve the not found command problem.
I think that in this case it has nothing to do with the PKG_CONFIG_PATH, because the user complains on the "command not found" error message.
The user probably mixes up pkg-config as a tool (with -) and pkgconfig (without -) as a directory as I see from the command. If I run it without dash on my system I get the same error message of course:
$ pkgconfig --libs --cflags opencv
-bash: pkgconfig: command not found
On Cygwin there is pkgconf.exe as a tool, pkg-config as a symlink to it and pkgconfig as a directory. There is no tool pkgconfig.
If it is not found as pkg-config then it means that pkg-config tool is missing in the Cygwin installation (the solution is to upgate Cygwin tools and select it in the checkbox) or it is probably the symlink problem which I described in https://stackoverflow.com/a/66037850/4807875 (the solution in this case is to use the indeed Cygwin console instead of the native cmd.exe with C:\Cygwin64\bin in PATH in it, or to call explicitly pkgconf.exe).
I am trying to compile a package on ubuntu 8.1
when executing this command: ./configure I get the follwoing error:
checking for Boost headers version >= 103700... no
configure: error: cannot find Boost headers version >= 103700
knowing that I installed needed boost packages using these command:
$ apt-get install libboost-dev libboost-graph-dev libboost-iostreams-dev
Can anybody help please?
thank you. Now it works but i get another error when running ./configure: checking boost/iostreams/device/file_descriptor.hpp usability... yes checking boost/iostreams/device/file_descriptor.hpp presence... yes checking for boost/iostreams/device/file_descriptor.hpp... yes checking for the Boost iostreams library... no configure: error: cannot not find the flags to link with Boost iostreams any ideas please?
It could be that the version of boost that you're getting from the Ubuntu repository is too old (it's suggested here that the highest version for 8.10 is 1.35; it looks like your configure script is asking for 1.37). You might need to build from source; there's some more info in the answers to the question I linked to which will hopefully help.
UPDATE:
From your new error, it sounds like configure now can't find the boost_iostreams library. On my system it's /usr/lib/libboost_iostreams-mt.[a|so] - do you have those files (possibly in a different directory depending on where you installed boost)?
You can also try running ldconfig in case there's a missing symlink (from, say,
libboost_iostreams-mt.so.1.37.0 to libboost_iostreams-mt.so).
Is this configure one generated by GNU autoconf? If it is, there should be a file called config.log in the same directory which contains a list of all the commands configure tried to run when looking for things. If there's anything in there about boost_iostreams could you post it?
One totally random guess: some examples I've found on the web link to boost_iostreams without the multi-threading suffix -mt - but I don't have those on my machine at all. Maybe your configure script is running into the same problem?
UPDATE 2
The configure script seems to be looking for a single-threaded debug build of the boost iostreams library, which won't be produced by default when building from source on linux. Also, the default on linux is not to name the libraries based on the build configuration (so the libs you found in /usr/lib might not be the ones you installed from source unless you overrode this). This stuff isn't really explained on the boost website, I only found out by looking in the Jamroot file (bjam --help works too)! Anyway, to get a library with the right build configuration, and named correctly, I need to go into the root of the boost source tree and run:
sudo bjam --with-iostreams --layout=tagged variant=debug threading=single install
For me this puts the libraries (libboost_iostreams-d.a and the shared versions) into /usr/local/lib where ld will find them by default, so this should be fine. If you need them to go somewhere else you can use the --prefix=... option to bjam eg. if you want them in /usr/lib you can do --prefix=/usr. If the package you're building needs more boost libraries you can remove the --with-iostreams and then they'll all be built (or replace iostream with the name of each other library you need).
A side note: I had to install the libbz2-dev package to get boost iostreams to build - it's easy to miss the error here if you build all of boost as there's so much output!