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).
Related
I'd like to specify GCC's search directory for the startfile and
endfile: crt1.o, crti.o and crtn.o. Passing -B on the command line to
the GCC driver works, but is inconvenient. How do I modify the specs
file (lib/gcc/x86_64-unknown-linux-gnu/4.9.2/specs) to specify the search path for startfile?
I tried adding the -B option to the startfile spec and got the error:
ld: unrecognized option '-B/gsc/btl/linuxbrew/lib'
I then tried adding the -B option to the cc1 spec and got the error:
cc1: error: command line option '-B/gsc/btl/linuxbrew/lib' is valid
for the driver but not for C
If it's not possible to do this via the specs file, is there an environment variable or a configure option to GCC that accomplishes the same goal?
I've installed a recent version of glibc in my home directory. Everything's working great. I've modified the specs file to link against the new version of glibc, but it's still linking against the old system version in /usr of startfile and endfile.
Here's a the unanswered question on the gcc-help mailing list. Here's a related Linuxbrew bug, gfortran is broken with stand alone Linuxbrew, and a proposed fix, gcc, binutils: link to Cellar instead of system libs.
Thanks,
Shaun
You can use an absolute path in the *startfile: and *endfile: sections in the specs file, instead of the default relative paths. This will override GCC's choice of the default location.
As per https://wiki.debian.org/Multiarch/LibraryPathOverview, gcc will look for startup files such as crt1.o in $(sysroot)/lib, so you can specify the --sysroot option when running gcc, or compile gcc with --with-sysroot.
I downloaded
Ruben’s build of
Cygwin GCC.
However upon running it seems unable to compile any files
$ touch foo.c
$ gcc foo.c
gcc: error: spawn: No such file or directory
As a workaround, I found this to work
i686-w64-mingw32-gcc foo.c
I had the same problem and solved it by installing the g++ package in addition to gcc-core
I had this same problem on Cygwin64, and the solution was PATH related..kinda.
Turns out, there are copies of gcc in /usr/bin and /bin (at least, there is in my install).
Executing /bin/gcc failed with the error above -- I'm guessing due to incorrectly assumed relative paths???
Executing /usr/bin/gcc works as expected!
In my case, the "problem" was that I had inadvertently injected "/bin" into my PATH environment variable, resulting in /bin/gcc being executed, instead of /usr/bin/gcc. Removing the "/bin" from the path solved the problem.
Still unclear why there are two gcc binaries (which appear to be identical) in different places... but maybe the Cygwin gurus can answer that; or maybe my installation is just foo-barred.
Ruben's builds are not Cygwin GCC packages, rather they are cross-compilers which run on various platforms but target native Windows using the MinGW-w64 toolchain.
In any case, you shouldn't be using them on Cygwin. If you want to compile Cygwin executables, install the gcc4 packages; if you want to cross-compile for Windows, install the mingw64-i686-gcc (for Win32) or mingw64-x86_64-gcc (for Win64) packages instead.
Gcc isn't really the compiler. It's a front end program that orchestrates the execution of any necessary compiler, assembler, and linker components. Typically these others are separately compiled programs.
So, gcc is trying (kind of) to tell you that it can't find the compiler. I guess it needs to be on your PATH or in an expected location.
If you are executing this from a Windows DOS box then it definitely needs a windows PATH setting.
I like to install Cygwin, making sure to include rxvt. At that point, you can configure a purely sh(1) path and your environment is rather more civilized.
I had the same error when I tried to extract a couple of executables from cygwin installation dirctory and copied them into another location.
strace shows me the file which was not found by spawn:
/lib/gcc/x86_64-pc-cygwin/6.4.0/cc1.exe
When I copied cc1.exe into the location relative to
<dir with sh.exe and cpp.exe>/../lib/gcc/x86_64-pc-cygwin/6.4.0/cc1.exe
it works fine.
This error occurs whenever cygwin cc can't find a required file.
For those running stuff within cygwin's bin directly from a Windows shell, a gotcha to watch out for is that Windows allow you to run programs from the command line like this:
e:cyg/bin/gcc -flags
Notice that there is no slash between e: and cyg.
So this command would successfully start cygwin gcc from the Windows shell, but halfway through the run it will error out because some component(s) of gcc will utilize the first argument of the input e:cyg/bin/gcc and unlike mingw, this is not a valid path for cygwin gcc.
This can be fixed simply by changing the command to:
e:/cyg/bin/gcc -flags
Notice the slash in between e: and cyg.
A similar gotcha is due to Windows allowing paths like e:/../folder1 as an alternative to e:/folder1. Windows does not give you an error if you are at the root folder and try to go up another folder using ...
So you could start running cygwin gcc using the command:
e:/../cyg/bin/gcc -flags
..or even:
e:/../../../../../../../../../cyg/bin/gcc -flags
However, it would fail halfway with gcc: error: spawn: No such file or directory because some component(s) of cygwin gcc would attempt to run gcc using the first argument of the command input itself, and unlike mingw, e:/../cyg/bin/gcc is not recognized as a valid path by cygwin because you are going up a folder when there's no folder to go up to.
As like above, this can be fixed by keeping the path valid:
e:/cyg/bin/gcc -flags
Make sure the source file extension is in lowercase (i.e. main.c, not main.C):
$ gcc -o main main.C
$ gcc: error: spawn: No such file or directory
$ gcc -o main main.c
$ # all good
This only refers to the case of the extension as given to the gcc, the actual source file can have the extension in whatever case you want.
Explanation: This is from my experimenting with cygwin and gcc, I don't know the actual reason for this behavior.
When running configure it fails with
checking for leptonica... yes
checking for pixCreate in -llept... no
configure: error: leptonica library missing
But I have leptonica 1.69 built (downloaded source and ran ./configure && make install)
Edit
I think configure: error: leptonica library missing is a bit misleading, please note that it first says checking for leptonica... yes, and then fails on checking for pixCreate in -llept... no. So maybe the problem is not that the library is missing, but something else.
I finally managed to make it compile, after reading this and this thread. The proper steps for were:
./autogen.sh
export LIBLEPT_HEADERSDIR=/local/include
./configure --with-extra-libraries=/local/lib
make install
for leptonica 1.69, lib renamed to .libs, so, parameters are
export LIBLEPT_HEADERSDIR=<your_path>/leptonica-1.69/src
./autogen.sh
./configure --prefix= --with-extra-libraries=<your_path>/leptonica-1.69/src/.libs
and so on
Maybe this could solve the issue:
export LIBLEPT_HEADERSDIR=/usr-or-other/local/include
I am working on redhat linux 7.2 . None of the solution worked for me I was getting following errors in config.log. Package lept was not found in the pkg-config search path.
Perhaps you should add the directory containing `lept.pc'
to the PKG_CONFIG_PATH environment variable PKG_CONFIG_PATH
configure script uses pkg-config utility to check for packages . It was not able to find lept package ( although i had installed leptonica seperately ) By setting PKG_CONFIG_PATH pointing to the directory where lept.pc is present , i was able to resolve the issue . export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
The FAQ addresses this issue and worked for me with tesseract 3.02.02 on Mac OSX 10.6.8.
Apart from the Leptonica library, png, jpeg, tiff libraries had to passed to the configure script with CXX and CPP flags.
To run configure as non-root -
1. LIBLEPT_HEADERSDIR=; export LIBLEPT_HEADERSDIR;
2. CXXFLAGS="-ltiff -lpng -ljpeg" CPPFLAGS="-ltiff -lpng -ljpeg" ./configure --prefix= --with-extra-libraries=
In my case, this issue was caused by a missing compiler. Searching config.log revealed the following:
./configure:17287: g++ -o conftest -I/Usr/local/include/leptonica -L/usr/local/lib conftest.cpp -llept >&5
./configure: line 2040: g++ command not found
Running apt-get install g++ solved the problem. There is an issue in the tesseract issue tracker about this.
In my case (for Ubuntu/Debian) I downloaded the latest leptonica version and the error was not fixed.
To fix it I removed the package "leptonica-dev" with sudo apt-get remove libleptonica-dev and then tesseract found the leptonica version installed from the source code.
Hope it helps!
The answer is going to be slightly different for everyone, depending on the state of your system.
At a high level, the pkg-config software needs to know that leptonica is installed. It searches paths for a .pc file that has the definition for the leptonica package. That file will be in different locations for different people.
You can find it using the Linux locate utility at the command line. locate lept.pc. (If you've done some recent installing/uninstalling, you may need to refresh the locate utilities database with the command updatedb.)
Whichever directory locate finds the file in, export PKG_CONFIG_PATH as that directory (export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig for example).
Then you can continue your configure/build.
i had a similar problem with trying to compile from source, but did not experience it with
apt-get to install tesseract
sudo apt-get install tesseract-ocr
export LIBLEPT_HEADERSDIR=$dir/letonica168/include
./autogen.sh
./configure --prefix=$anotherdir --with-extra-libraries=/$dir/letonica168/lib
make
make install
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.
I have installed the latest version of Cygwin, selecting the following packages during setup:
libgcc1
gcc
gcc-core
And created a file (test.c) with only this line:
#include <link.h>
Then ran the following from my Cygwin bash:
$ gcc test.c
... but got this error:
test.c:1:18: link.h: No such file or directory
Any ideas how I can fix it?
Cygwin is based on the Win32 subsystem, which means it uses Windows' executable format (COFF) and dynamic linker, i.e. it does not have an ELF dynamic linker. Hence providing the ELF-specific <link.h> would probably make little sense.