I want to install protobuf, but as soon as i input "./autogen.sh",it has the error like this:
aclocal: couldn't open `configure.in': No such file or directory
autoreconf: aclocal failed with exit status: 2
I have search for the answer for nearly one day.
I have tried to install many versions of protobuf ,but the error is still on , and i have tried to touch an empty file named "configure.in",it has been failed.so i will appreciate if someone can help me ,thanks very very much.
It sounds like your system has a very, very old version of autoconf installed. These days the input to autoconf is usually called configure.ac, and it has been that way for at least a decade, maybe longer. You could try renaming configure.ac to configure.in, but you'll probably run into other problems with such an old autoconf. I recommend updating autoconf to a newer version (and automake and libtool, too).
Alternatively, if you compile protobuf from a release package instead of from git, you can skip the autogen.sh step entirely, and go directly to running ./configure. It's usually better to use release versions anyway.
Related
It installed about 70% of the dependencies it needed to get ffmpegs going, but it got stuck at installing 'doxygen'.
This is the error I got:
==> Installing dependencies for ffmpeg: doxygen, little-cms2, openjpeg, opus, rust, libgit2, cargo-c, rav1e, flac, libsndfile, libsamplerate, rubberband, sdl2, swig, llvm, snappy, speex, srt, leptonica, libb2, lz4, libarchive, tesseract, theora, x264, x265, xvid, docbook, boost, source-highlight, asciidoc, docbook-xsl, libyaml, ruby, asciidoctor, gnu-getopt, xmlto, libsodium, zeromq and zimg
==> Installing ffmpeg dependency: doxygen
==> cmake ..
==> make
Last 15 lines from /Users/macbook/Library/Logs/Homebrew/doxygen/02.make:
In file included from /tmp/doxygen-20220723-61533-5m5mdv/doxygen-1.9.4/src/outputlist.h:25:
/tmp/doxygen-20220723-61533-5m5mdv/doxygen-1.9.4/src/searchindex.h:29:10: fatal error: 'variant' file not found
#include <variant>
^~~~~~~~~
1 error generated.
make[2]: *** [src/CMakeFiles/doxymain.dir/__/generated_src/code.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/doxymain.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 46%] Linking CXX static library ../lib/libvhdlparser.a
cd /tmp/doxygen-20220723-61533-5m5mdv/doxygen-1.9.4/build/vhdlparser && /usr/local/Cellar/cmake/3.23.2/bin/cmake -P CMakeFiles/vhdlparser.dir/cmake_clean_target.cmake
cd /tmp/doxygen-20220723-61533-5m5mdv/doxygen-1.9.4/build/vhdlparser && /usr/local/Cellar/cmake/3.23.2/bin/cmake -E cmake_link_script CMakeFiles/vhdlparser.dir/link.txt --verbose=1
/usr/bin/ar qc ../lib/libvhdlparser.a CMakeFiles/vhdlparser.dir/CharStream.cc.o CMakeFiles/vhdlparser.dir/ParseException.cc.o CMakeFiles/vhdlparser.dir/Token.cc.o CMakeFiles/vhdlparser.dir/TokenMgrError.cc.o CMakeFiles/vhdlparser.dir/__/generated_src/VhdlParser_adj.cc.o CMakeFiles/vhdlparser.dir/VhdlParserTokenManager.cc.o
/usr/bin/ranlib ../lib/libvhdlparser.a
[ 46%] Built target vhdlparser
make: *** [all] Error 2
Do not report this issue to Homebrew/brew or Homebrew/core!
Error: You are using macOS 10.12.
We (and Apple) do not provide support for this old version.
You will encounter build failures with some formulae.
Please create pull requests instead of asking for help on Homebrew's GitHub,
Twitter or any other official channels. You are responsible for resolving
any issues you experience while you are running this
old version.
Can someone please help me am not sure what it is, that I am supposed to do.
Looks like we're in the same boat. Fighting the "good fight", as it were. We should probably both just bail to linux or even windows, because god knows they are going to keep making this hard for us....
However, probably like yourself, a combination of inertia and "good reasons" keeps us staying the course ;)
Basically, the issue is described correctly by the others here (lack of c++ 17 support) and in my case (and likely yours as well) is because gcc is a symlink to clang (9.0 if you are using the latest version compatible with our os)
Telling brew to use real gcc (I assume you have compiled it already, and if not - gcc 11.3.0 is a dependency for ffmpeg anyhow, so go ahead and build it; brew install gcc) can be done like this :
HOMEBREW_CC=gcc-11 HOMEBREW_CXX=g++-11 brew install doxygen
However, the above didn't work for me because - although it solved the c++ 17 issue, it exposed another problem :(
It seems that for some reason the minimum macos version number is messed up (I think because the sdk headers for 10.13 are installed with the latest version of xcode compatible with our os) and so the compilation fails. Although there is almost certainly a better/cleaner way to deal with this issue, I solved it by manually compiling and installing doxygen after editing the code.
In the doxygen/filesystem/filesystem.hpp file around line 4491 you need to change the line
#if __MAC_OS_X_VERSION_MIN_REQUIRED < 101300
to
#if __MAC_OS_X_VERSION_MIN_REQUIRED < 111400
Then compile doxygen (extract the source from the brew cache), cd to the cmake folder then run
cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/doxygen/1.9.4 -DCMAKE_INSTALL_LIBDIR=lib -DCMAKE_BUILD_TYPE=Release -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_VERBOSE_MAKEFILE=ON -Wno-dev -DBUILD_TESTING=OFF -DCMAKE_C_COMPILER=gcc-11 -DCMAKE_CXX_COMPILER=g++-11
make
make install
brew link doxygen
Then continue the brew install ffmpeg. I had trouble with nettle as well, and needed to compile and install that one manually too because the version of libcrypto packaged with macos (libressl) is incompatible. I had to do the steps shown in "brew info openssl#1.1" in order to make sure the compiler used the openssl libcrypto that IS compatible and I couldn't figure out how to make brew do this for me.
Fun fun fun. I am not all that hopeful that the rest of the compilation will go without issue, but it is chugging away again now. I get the distinct impression that this is SO not worth the hassle/trouble.
Good luck!
** EDIT **
I'm still slogging through it, and it is taking a LONG time. But as I encounter more issues I will try and detail them here with the hope that each issue I encounter is reasonably easy to overcome.
llvm failed to compile with lots of missing header errors. Directing brew to use gcc-11 like i did with doxygen worked to compile it further (27%) but still failed (it looks like because it is calling clang specific options as a result of the brew cmake config passed to it... i'm still working on this one...)
Conclusion - I gave up. It isn't worth the time in my view.
Instead I installed macports and used "sudo port install ffmpeg-upstream" to install ffmpeg-5. Unless you have some dying need to compile yourself, I recommend you do this as well.
I've spent quite some time to get around this issue as well and I ended up with another solution. I merely edited the formula to suit my needs :
brew edit doxygen
Once there, spot the "def install" block then edit the file so that it looks like this :
fails_with :clang
def install
inreplace "CMakeLists.txt", "MACOS_VERSION_MIN 10.14", "MACOS_VERSION_MIN 10.11"
Save, exit.
In short, just add the "fails_with" line and the "inreplace" line. The first one causes brew to not use clang (so you need to have a gcc copy somewhere). This is to solve the C++17 issue. The second one patches the CMakeLists.txt file to allows cmake to do its magic. Once done, "brew install doxygen" should succeed.
I'm working on a Windows 7 computer at work and want to use the libpostal package. Unfortunately, it's apparently not available for Windows, so I'm trying to configure it through Cygwin and I'm SO close. The last step is to install snappy from Google. Again, not available on Windows...
My assumption (based on nothing) is that I can just download the tarball and build it from source, right? I tried that, and I think it worked? But a) I don't know how to tell, and b) if it did, I don't know how to tell ./configure in libpostal to find it.
In order to build it from source, I downloaded the tarball and saved it in the folder that Cygwin reads as my home, which is C:\cygwin64\home\brittenb\. From there, I ran bash autogen.sh, which created the ./configure that I needed. So I ran that and while some responses to the checks were no, it seemed to run fine. I then ran make and make install. Nothing seemed out of place, so my assumption is that it did what it was supposed to do. I just have no idea where to go from here.
Here is the output from ls after I run everything:
aclocal.m4 snappy.cc
AUTHORS snappy.h
autogen.sh snappy.lo
autom4te.cache snappy.o
ChangeLog snappy.pc
compile snappy.pc.in
config.guess snappy_unittest.cc
config.h snappy_unittest.exe
config.h.in snappy_unittest-snappy_unittest.o
config.log snappy_unittest-snappy-test.o
config.status snappy-c.cc
config.sub snappy-c.h
configure snappy-c.lo
configure.ac snappy-c.o
COPYING snappy-internal.h
depcomp snappy-sinksource.cc
format_description.txt snappy-sinksource.h
framing_format.txt snappy-sinksource.lo
INSTALL snappy-sinksource.o
install-sh snappy-stubs-internal.cc
libsnappy.la snappy-stubs-internal.h
libtool snappy-stubs-internal.lo
ltmain.sh snappy-stubs-internal.o
m4 snappy-stubs-public.h
Makefile snappy-stubs-public.h.in
Makefile.am snappy-test.cc
Makefile.in snappy-test.h
missing stamp-h1
NEWS testdata
README test-driver
ls /usr/local/bin shows nothing, but ls /usr/local/include shows:
snappy.h snappy-c.h snappy-sinksource.h snappy-stubs-public.h
So... my question: did it work? Why does ./configure in libpostal say it can't find snappy? Thanks in advance.
The snappy dependency has been removed as of release 1.0.0. I made changes to the source and make and config so that it will build on MinGW.
Get it in my repository:
https://github.com/BenK10/libpostal_windows
Note that this is not the complete source since not everything had to be changed. I would suggest merging my changes with the official libpostal distribution to make sure you've got everything. Also, there are some extra DLLEXPORTs in some source files that I haven't removed yet, and the part in the Makefile that builds the executables like address_parser.exe was removed because some porting is necessary to build those programs on Windows. You can write your own using the DLL you'll get in the Windows build and the original source as a reference.
Check the return code from make install ($?). If it is zero, make install succeeded.
snappy looks like a library, so maybe it doesn't install anything in /usr/local/bin. The library is probably installed into /usr/local/lib.
I use the following autotool steps to install my pacakges:
./configure
make
make install prefix=/my/path
However I got the following libtool warning "libtool: warning: remember to run 'libtool --finish /usr/local/lib' and "libtool: warning: 'lib/my.la' has not been installed in '/usr/local/lib'" when using the autotool to install my software package. If I change to the following command, the problem disappear:
./configure
make prefix=/my/path
make install prefix=/my/path
It looks like the first method doesn't substitute the prefix correctly to libtool. How can I avoid this problem?
Among the information that libtool archives record about the libraries they describe is the expected installation location. That information is recorded when the library is created. You can then install to a different location, but libtool will complain. Often, libtool's warning is harmless.
In order to avoid such a warning, you need to tell libtool the same installation location at build time that you do at install time. You present one way to do that in the question, but if you're using a standard Autotools build system then it is better to specify the installation prefix to configure:
./configure --prefix=/my/path
make
make install
Alternatively, if you're installing into a staging area, such as for building an RPM, then use DESTDIR at install time. libtool will still warn, but you'll avoid messing up anything else:
./configure
make
make install DESTDIR=/staging/area
If there a relatively simple way to make go + libxml2 + gokogiri work on windows?
I mean that I may be can install it (but at the moment I can not, stuck with Package libxml-2.0 was not found in the pkg-config search path), but then I need to provide my utilite to other people, who will never be able (or would wish ) to install lall libxml2 dependencies, modify PATH etc on windows...
It work flawless on Ubuntu...
I found this https://github.com/moovweb/gokogiri/issues/49 thats funny with installation of Gimp 2 (what?!), but I still cannot make it run with such error, I guess might be issue with PATH, but all PATH are set
$ go get github.com/moovweb/gokogiri
# github.com/moovweb/gokogiri/help
Documents\go\src\github.com\moovweb\gokogiri\help\help.go:6:25: fatal error: lib
xml/tree.h: No such file or directory
#include <libxml/tree.h>
^
compilation terminated.
# github.com/moovweb/gokogiri/xpath
Documents\go\src\github.com\moovweb\gokogiri\xpath\expression.go:4:26: fatal err
or: libxml/xpath.h: No such file or directory
#include <libxml/xpath.h>
^
compilation terminated.
You are struggling because it is hard to combine packages that were built by different people for different purposes and get your environment set up correctly. I think it is best to use MSYS2, an environment for Windows that provides a consistent set of packages for things like gcc, go, libxml2, and iconv. MSYS2 has a package manager (pacman) that helps you easily install them and keep them updated.
I don't do much programming with Go, but I am familiar with MSYS2 and it seems like I was able to get gokogiri installed using MSYS2. You should open MSYS2's "MinGW-w64 Win64 Shell" from the Start menu (mingw64_shell.bat), and try running these commands:
pacman -S mingw-w64-x86_64-{gcc,go,libxml2,iconv}
export GOROOT=/mingw64/
export GOPATH=/c/Users/David/Documents/goproj/
mkdir -p $GOPATH
go get github.com/moovweb/gokogiri
I think GOPATH should be set to the directory of your project. If you run into an error, it might be because some pacman package is required that I didn't list here.
The string mingw-w64-x86_64-{gcc,go,libxml2,iconv} gets expanded by Bash into the following list of packages:
mingw-w64-x86_64-gcc
mingw-w64-x86_64-go
mingw-w64-x86_64-libxml2
mingw-w64-x86_64-iconv
If you are actually using 32-bit Windows, replace x86_64 with i686 in the instructions above.
If you are curious, the scripts for building those packages are here: https://github.com/Alexpux/MINGW-packages
As a disclaimer, I haven't actually compiled any go programs in MSYS2, so there could be big problems I am unaware of.
Also, one of the main developers of MSYS2 (alexpux) said this in the #msys2 IRC chat on 2015-06-21:
We not build go for a long time.
This package in very WIP state
Also see
https://github.com/Alexpux/MINGW-packages/issues/421
So you might need to fix some issues with the MSYS2 Go package and recompile it yourself to really make this work. But you have the PKGBUILD script that was used to build it, so maybe that will be less hard than what you are trying to do right now, which involves compiling/collecting every dependency of gokogiri.
MSYS2 would make your other installation of go, libxml2, and iconv obsolete. You can delete those things once you get your MSYS2 environment working.
If you are using visual studio and want to add dependency to your project then just install it using NuGet Package Manager it's easiest method.
Install command: Install-Package libxml2
I'm trying get Homebrew working with Xcode Command Line Tools, and they seem to be having it out with each other... In the words of Rodney King, "Can't we all just get along?"
For some background, when I first got my Mac about a year ago, I had no idea what I was doing. I was also using macports, which was, as the Homebrew website seems to be cognizant, driving me to become a raging alcoholic. As a result, my /usr/local directory got wayyy f-ed up. Eventually, gcc and g++ stopped working, and a lot of other things were breaking. So I did a clean install of OS X, and I want my shiny new installation to stay a little more organized.
Now, I've installed Apple's Command Line Tools, and all the binaries/libraries/etc have ended up in /usr/local. That's fine, but then I try to install homebrew, and it's also putting everything in the /usr/local/ directory. When I run the command
brew doctor
I get the following output (actually, this is just a snippet, but it captures the general spirit of what Homebrew is telling me):
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/libatomic.a
/usr/local/lib/libgfortran.a
/usr/local/lib/libgmp.a
/usr/local/lib/libgomp.a
/usr/local/lib/libitm.a
/usr/local/lib/libmpc.a
/usr/local/lib/libmpfr.a
/usr/local/lib/libquadmath.a
/usr/local/lib/libssp.a
/usr/local/lib/libssp_nonshared.a
/usr/local/lib/libstdc++.a
/usr/local/lib/libsupc++.a
I thought I might place Homebrew in a different directory; however, the Homebrew documentation specifically warned against this. They say:
"Do yourself a favor and install to /usr/local. Some things may not build when installed elsewhere. One of the reasons Homebrew just works relative to the competition is because we recommend installing to /usr/local. Pick another prefix at your peril!"
The whole point is that I don't want to bother with micro-managing every package I install, and I don't want my filesystem to become an ungodly mess either. Anyone have any suggestions? Do I move command line tools to a different directory and add this to my $PATH? Any tips would be much appreciated.
It's a warning, and the message says why. If you later want to install a Homebrew formula that installs one of those files, it will fail, because it will decline to overwrite those files, and then you will have to delete those files, as the message says.
Specifically, those files appear to belong to an installation of gcc. You might want to research or try to remember why that was installed there. It's probably OK to just delete them and install gcc from Homebrew if you need it.