there are no obvious errors.
the output being similar to building qt 4.8.5 (which I have built succesfully) but the obvious issue is that the bin folder only contains 3 files, moc.exe, rcc.exe, uic.exe
and missing the demos, doc, examples, imports folders etc .. and i cannot find them anywehere else.
i assume the make install step is failing
i'm a bit of a noob :)
i am using these steps to compile -
gunzip qt-everywhere-opensource-src-4.8.3.tar.gz
sudo tar xvf qt-everywhere-opensource-src-4.8.3.gz
./configure -prefix /Users/User/qt4.8.3
make
sudo make install
(i think i've tried sudo on make as well, but can't quite recall exactly)
the makefile seems to have relevant paths
install_qmake: FORCE
#$(CHK_DIR_EXISTS) $(INSTALL_ROOT)/Users/User/Qt4.8.3/bin/ || $(MKDIR) $(INSTALL_ROOT)/Users/User/Qt4.8.3/bin/
-$(INSTALL_PROGRAM) /Volumes/data/qt-creator/qt-everywhere-opensource-src-4.8.3/bin/qmake $(INSTALL_ROOT)/Users/User/Qt4.8.3/bin/
edit..
i went through and compared teh 4.8.3 and 4.8.5 makefiles and apart from the obvious version and directory differences they were identical.
i'm wondering if it's a permission thing and will download a new copy of the source soon and try again.
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've downloaded tar.gz files from official site(versions 2.4.3, 2.4.7, 2.4.8). Then unzipped them somewhere.
mac-mini-olia:Data olia$ cd opencv-2.4.6.1/
mac-mini-olia:opencv-2.4.6.1 olia$ mkdir build
mac-mini-olia:opencv-2.4.6.1 olia$ cd build/
mac-mini-olia:build olia$ cmake -G "Unix Makefiles" ..
mac-mini-olia:build olia$ make -j8
after the last command output is
3910 warnings and 12 errors generated.
Errors are like
/Volumes/Data/opencv-2.4.6.1/3rdparty/libjpeg/._jcapimin.c:1:4096: error: source file is not valid UTF-8
and
/Volumes/Data/opencv-2.4.6.1/3rdparty/libpng/._pngerror.c:1:2: error: expected identifier or '('
And after that in /usr/local/lib and /usr/local/include there are no files of opencv.
There are multiple ways to install OpenCV on OSX.
You can use MacPorts
Make sure you have XCode installed with it's Command Line Tools first.
(An easy way to test that is to see if xcodebuild if a found command in Terminal)
After you install MacPorts simply do
sudo port install opencv
This will take care of building the project from source and installing it for you.
(The path might be /opt/local/lib /opt/local/include though, haven't used it in a while)
There are also port variants: opencv with options. For example if you plan to use openni 1.5.x and have it integrated with opencv you can try
sudo port install opencv +openni
If you do
sudo port variants opencv
you should get a list of all the options(e.g. python support, qt support, etc.)
If you want to build from source yourself, I recommend installing the ccmake command (I think macports can also do that for you) or use the CMake gui tool. This will allow you to easily configure the build and setup your install location(/use/local/...and so on)
So you can try someting like this:
cd /path/to/your/opencv_folder
mkdir build && cd build
ccmake ..
At this stage you should see something like this:
hit Enter to change an option and Enter again to exit edit mode and use the up/down keys to scroll through the options. When you're happy with the settings, press C to configure. Once that's done, you can press G to generate. This will generate the makefiles for you so you can do this:
make
sudo make install
make install will actually copy the built libraries/headers to the /usr/ folder.
You might run into errors when running make, depending on your setup(e.g. if you're missing dependencies, etc.), but the cool thing about ccmake is that you can go back, run it again, disable the things you don't want to build right now and go back to the make stage.
I have a virtual Debian system which I use to develop. Today I wanted to try llvm/clang. After installing clang I can't compile my old c-projects (with gcc).
This is the error:
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
collect2: ld returned 1 exit status
I uninstalled clang and it still did not work. Does anyone have any idea how I can fix this?
Debian / Ubuntu
The problem is you likely only have the gcc for your current architecture and that's 64bit. You need the 32bit support files. For that, you need to install them
sudo apt install gcc-multilib
What helped me is to create a symbolic link:
sudo ln -s /usr/lib/x86_64-linux-gnu /usr/lib64
It seems that while you were playing with llvm/clang you(or the package manager) removed previously existing standard C library development package(eglibc on Debian) or maybe you didn't have it installed in the first place, thus you need to reinstall it, now that you reverted back to gcc.
You can do so like this on Debian:
aptitude show libc-dev
Ubuntu:
apt-get install libc-dev
On Ubuntu, if you don't have libc-dev, since I cannot find it on packages.ubuntu.com, you can try installing libc6-dev directly.
Or on Redhat like systems:
yum install glibc-devel
NB: Although you were briefly answered in the comments, here is an answer just so there is one on record in case someone encounters this one and might be looking for an answer, but not in the comments or the comment is not explicit enough for them.
This is a BUG reported in launchpad, but there is a workaround :
Run this to see where these files are located
$ find /usr/ -name crti*
/usr/lib/x86_64-linux-gnu/crti.o
then add this path to LIBRARY_PATH variable
$ export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu:$LIBRARY_PATH
After reading the http://wiki.debian.org/Multiarch/LibraryPathOverview that jeremiah posted, i found the gcc flag that works without the symlink:
gcc -B/usr/lib/x86_64-linux-gnu hello.c
So, you can just add -B/usr/lib/x86_64-linux-gnu to the CFLAGS variable in your Makefile.
If you're using Debian's Testing version, called 'wheezy', then you may have been bitten by the move to multiarch. More about Debian's multiarch here: http://wiki.debian.org/Multiarch
Basically, what is happening is various architecture specific libraries are being moved from traditional places in the file system to new architecture specific places. This is why /usr/bin/ld is confused.
You will find crt1.o in both /usr/lib64/ and /usr/lib/i386-linux-gnu/ now and you'll need to tell your toolchain about that. Here is some documentation on how to do that; http://wiki.debian.org/Multiarch/LibraryPathOverview
Note that merely creating a symlink will only give you one architecture and you'd be essentially disabling multiarch. While this may be what you want it might not be the optimal solution.
To get RHEL 7 64-bit to compile gcc 4.8 32-bit programs, you'll need to do two things.
Make sure all the 32-bit gcc 4.8 development tools are completely installed:
sudo yum install glibc-devel.i686 libgcc.i686 libstdc++-devel.i686 ncurses-devel.i686
Compile programs using the -m32 flag
gcc pgm.c -m32 -o pgm
stolen from here : How to Compile 32-bit Apps on 64-bit RHEL? - I only had to do step 1.
As explained in crti.o file missing , it's better to use "gcc -print-search-dirs" to find out all the search path. Then create a link as explain above "sudo ln -s" to point to the location of crt1.o
This worked for me with Ubuntu 16.04
$ export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu
./configure --disable-multilib
works for it
On Alpine Linux that would mean that you need musl-dev:
apk add musl-dev
Although in my case the messages were:
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find Scrt1.o: No such file or directory
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find crti.o: No such file or directory
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -lssp_nonshared: No such file or directory
collect2: error: ld returned 1 exit status
Which are also caused by missing musl-dev.
Ran into this on CentOs 5.4. Noticed that lib64 contained the crt*.o files, but lib did not. Installed glibc-devel through yum which installed the i386 bits and this resolved my issue.
Even I got the same compilation error when I was cross compiling i686-cm-linux-gcc.
The below compilation option solved my problem
$ i686-cm-linux-gcc a.c --sysroot=/opt/toolchain/i686-cm-linux-gcc
Note: The sysroot should point to compiler directory where usr/include available
In my case the toolchain is installed at /opt/toolchain/i686-cm-linux-gcc directory and usr/include is also available in the same directory
I solved it as follows:
1) try to locate ctr1.o and ctri.o files by using find -name ctr1.o
I got the following in my computer: $/usr/lib/i386-linux/gnu
2) Add that path to PATH (also LIBRARY_PATH) environment variable (in order to see which is the name: type env command in the Terminal):
$PATH=/usr/lib/i386-linux/gnu:$PATH
$export PATH
I had the same problem today, I solved it by installing recommended packages:
libc6-dev-mipsel-cross libc6-dev-mipsel-cross, libc-dev-mipsel-cross
This worked:
sudo apt-get install libc6-dev-mipsel-cross
One magic command:
sudo apt install build-essential
Fixed everything for me even on Raspberry Pi.
In my case, the crti.o error was entailed by the execution path configuration from Matlab.
For instance, you cannot perform a file if you have not set the path of your execution directory earlier.
To do this: File > setPath, add your directory and save.
use gcc -B lib_path_containing_crt?.o
In my case Ubuntu 16.04 I have no crti.o at all:
$ find /usr/ -name crti*
So I install developer libc6-dev package:
sudo apt-get install libc6-dev
I want to install Ruby SVM. I already have macports with normal settings, and installed libsvm via port just fine. But when I go to compile rubysvm, it barfs. :(
Ruby SVM: http://rubysvm.cilibrar.com/download/ (most links are 404 though)
libsvm: http://www.csie.ntu.edu.tw/~cjlin/libsvm/
Try this:
sudo port install libsvm
wget http://debian.cilibrar.com/debian/pool/main/libs/libsvm-ruby/libsvm-ruby_2.8.4.orig.tar.gz
tar -xzf libsvm-ruby_2.8.4.orig.tar.gz
cd libsvm-ruby-2.8.4
./configure
... and you get the error:
...
checking libsvm/svm.h usability... no
checking libsvm/svm.h presence... no
checking for libsvm/svm.h... no
Error, cannot find LIBSVM svm.h header.
I've tried this, without success:
export DYLD_LIBRARY_PATH=/opt/local/include/:/opt/local/lib/
(... ditto for C_INCLUDE_PATH, LD_LIBRARY_PATH, CPATH, & LIBRARY_PATH)
LDFLAGS="-I/opt/local/include -L/opt/local/lib" CPPFLAGS="-I/opt/local/include -L/opt/local/lib" ./configure
How do I fix this?
libsvm-ruby assumes libsvm installs its header in PREFIX/include/libsvm/svm.h, but the macports package puts it in /opt/local/include.
It's a kludge, but the easiest fix is to manually make the directory /opt/local/include/libsvm and move/copy the svm.h header there. You may still need to run your configure command with the LDFLAGS and CPPFLAGS settings since it looks like the macports install doesn't update pkg-config (which libsvm-ruby uses to try to find the compiler flags).
I'd report this as a package bug to the macports maintainer. If you understand macport's Portfiles, you can probably even provide a patch.
Update: I haven't actually tried this, so there may be other issues once you get past the header file detection.
Update 2: I was able to get past configure with:
sudo mkdir /opt/local/include/libsvm
sudo cp /opt/local/include/svm /opt/local/include/libsvm/
CPPFLAGS=-I/opt/local/include LIBS=-L/opt/local/lib ./configure
But libsvm-ruby appears to depend on obstack.h, which doesn't exist natively on OS X. Based on this, there might be a way to copy in the files that you need, but you'll need to patch the libsvm-ruby main.cpp and Makefile to link that in.
Good luck!