I'm failing to compiled the rabbitmq-c library on Mac OS 10.6.6
I intend to build the php-ampq extension against it.
I've tried both the latest branch of rabbitmq-c and rabbitmq-codegen according to the instructions here and the specific branches according to the instructions here.
Running autoreconf -i as per instructions I get:
glibtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
glibtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:12: installing `./config.sub'
configure.ac:12: required file `./ltmain.sh' not found
configure.ac:3: installing `./missing'
configure.ac:3: installing `./install-sh'
configure.ac:12: installing `./config.guess'
examples/Makefile.am: installing `./depcomp'
autoreconf: automake failed with exit status: 1
Running simply autoconf I get:
configure.ac:3: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:12: error: possibly undefined macro: AM_PROG_LIBTOOL
configure.ac:90: error: possibly undefined macro: AM_CONDITIONAL
Most of what I can find by searching online suggests I don't have libtool or automake. I have both.
I'm afraid I'm out of my depth with autoconf, so I don't know how/where to alter configure.ac, or whether the warning is anything do with the missing ltmain.sh file.
I solved the same problem by installing pkg-config:
sudo port install pkgconfig
Related
I installed SCIP Optimization Suite from the SCIPOptSuite-7.0.2-Darwin-Ipopt-gcc10.sh installer of precompiled binary.
I also installed gcc and tbb by running:
brew install gcc
brew install tbb
Error message:
$ SCIPOptSuite-7.0.2-Darwin/bin/scip
dyld: Library not loaded: /usr/local/lib/7/i386/libquadmath.0.dylib
Referenced from: /Users/it/VirtualBox/10运筹学/14SCIP/01install/SCIPOptSuite-7.0.2-Darwin/bin/scip
Reason: no suitable image found. Did find:
/usr/local/lib/7/i386/libquadmath.0.dylib: mach-o, but wrong architecture
/usr/local/lib/7/i386/libquadmath.0.dylib: stat() failed with errno=1
/usr/local/lib/7/i386/libquadmath.0.dylib: mach-o, but wrong architecture
[1] 93720 abort SCIPOptSuite-7.0.2-Darwin/bin/scip
There is other libquadmath.0.dylib with x86_64 architecture installed:
$ sudo find / -name libquadmath.0.dylib
Password:
/usr/local/lib/7/i386/libquadmath.0.dylib
/usr/local/lib/7/libquadmath.0.dylib
/usr/local/opt/lib/gcc/7/i386/libquadmath.0.dylib
/usr/local/opt/lib/gcc/7/libquadmath.0.dylib
/usr/local/Cellar/4.6.4/lib/gcc/x86_64-apple-darwin12.5.0/4.6.4/i386/libquadmath.0.dylib
/usr/local/Cellar/4.6.4/lib/gcc/x86_64-apple-darwin12.5.0/4.6.4/libquadmath.0.dylib
/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/libquadmath.0.dylib
/usr/local/Cellar/gcc#4.6/4.6.4/lib/gcc/x86_64-apple-darwin12.5.0/4.6.4/i386/libquadmath.0.dylib
/usr/local/Cellar/gcc#4.6/4.6.4/lib/gcc/x86_64-apple-darwin12.5.0/4.6.4/libquadmath.0.dylib
/Users/it/miniconda3/lib/python3.6/site-packages/numpy/.dylibs/libquadmath.0.dylib
/Users/it/miniconda3/lib/python3.6/site-packages/scipy/.dylibs/libquadmath.0.dylib
/Users/it/miniconda3/envs/py2/lib/python2.7/site-packages/scipy/.dylibs/libquadmath.0.dylib
$ lipo /usr/local/lib/7/libquadmath.0.dylib -archs
x86_64
I wonder why scip did not find these dylibs with right architecture?
Thanks very much.
First of all make sure you have the correct version of gcc installed, the installer that you downloaded asks for version 10.
Second, try installing all prerequisites first and then rerunning the installer-script afterwards.
If that does not help, please check the output of otool -L SCIPOptSuite-7.0.2-Darwin/bin/scip and echo $DYLD_LIBRARY_PATH to see if the library in question is loaded.
Lastly, you can try to patch the binary by adjusting the path to the library for the correct one:
install_name_tool -change /usr/local/lib/7/i386/libquadmath.0.dylib /usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/libquadmath.0.dylib SCIPOptSuite-7.0.2-Darwin/bin/scip
I am trying to build MKL-accelerated version of TensorFlow using bazel 0.5.1, gcc 6.2, binutils 2.28, Anaconda2 python on Scientific Linux 7.2.
Apparently the system /lib64/libstdc++.so.6 is too old, so I am trying to use gcc installed in another directory. PATH, LD_LIBRARY_PATH are modified to prepend the corresponding paths (using modules). However, while bazel has no trouble picking up correctly executables for gcc, ld, python, it still tries to load old system /lib64/libstdc++.so.6. How to force it to use the one from gcc 6.2? Why does not it pick it up from LD_LIBRARY_PATH?
According to google many people are having trouble with this but I could not find a solution that would work for me. I had no trouble building TensorFlow under Ubuntu 16.04 that has sufficiently new gcc in the standard location.
I do:
1) ./configure
The only non-default options I choose is use MKL and download MKL
2) bazel build --config=mkl --copt="-DEIGEN_USE_VML" -s -c opt //tensorflow/tools/pip_package:build_pip_package
.....
example/example_parser_configuration.proto tensorflow/core/protobuf/control_flow.proto tensorflow/core/protobuf/meta_graph.proto tensorflow/core/protobuf/named_tensor.proto tensorflow/core/protobuf/saved_model.proto tensorflow/core/protobuf/tensorflow_server.proto tensorflow/core/util/event.proto tensorflow/core/util/test_log.proto)
ERROR: /scratch/midway2/ivy2/TF_intel/tensorflow/tensorflow/tools/tfprof/BUILD:42:1: null failed: protoc failed: error executing command bazel-out/host/bin/external/protobuf/protoc '--python_out=bazel-out/local-opt/genfiles/' -I. -I. -Iexternal/protobuf/python -Ibazel-out/local-opt/genfiles/external/protobuf/python ... (remaining 5 argument(s) skipped): com.google.devtools.build.lib.shell.BadExitStatusException: Process exited with status 1.
bazel-out/host/bin/external/protobuf/protoc: /lib64/libstdc++.so.6: version GLIBCXX_3.4.20' not found (required by bazel-out/host/bin/external/protobuf/protoc)
bazel-out/host/bin/external/protobuf/protoc: /lib64/libstdc++.so.6: versionCXXABI_1.3.8' not found (required by bazel-out/host/bin/external/protobuf/protoc)
bazel-out/host/bin/external/protobuf/protoc: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by bazel-out/host/bin/external/protobuf/protoc)
.....
Thank you,
Igor
sorry for the slow reply. Bazel by design ignores LD_LIBRARY_PATH when running actions. It doesn't have to ignore them during C++ toolchain detection, but at the moment, it does :/ To help you forward, I would try adding --sysroot= as linkopt or using bazel grte_top flag. Depending on where your libstdc++.so lives, you might need to disable sandbox. The principled solution would be to write a custom CROSSTOOL that specifies builtin_sysroot or grte_top. But that is not an easy task.
Let me know if I lost you somewhere in that paragraph :)
I'm trying to compile gcc5.3.0 on my Raspberry Pi with latest Raspbian system image.
$ ./configure --enbale-checking=release --enable-languages=c,c++,fortran --host=arm-cortexa7_neon-linux-gnueabihf --build=arm-cortexa7_neon-linux-gnueabihf --target=arm-cortexa7_neon-linux-gnueabihf
$ make
However, the original compiler (gcc4.9) complains about not founding sys/cdefs.h when compiling libgcc.
I checked I have libc6-dev and build-essential installed.
So I used grep -R 'cdefs' /usr/include/ to search it and I found it at /usr/include/bsd/. I created the sys directory and made hard links to these headers under /usr/include/bsd/sys.
This time it gave me a more weird error,
/usr/include/stdio.h:312:8: error: unknown type name 'FILE'.
I searched this on stackoverflow, and there's a similar question, https://stackoverflow.com/a/21047237/5691005. But when I removed /usr/include/sys and /usr/include/bsd, then reinstalled libc6-dev, I cannot find sys/cdefs.h under /usr/include, and the compiler gave errors still.
I'm now totally lost. Any suggestion will be appreciated.
I had similar problem with compiling gcc-8.2. I tried to do as described here with reinstalling:
sudo apt-get --reinstall install libc6 libc6-dev
After that I was locating all missing headers:
find / -name cdefs.h
and copying them to /usr/include:
those steps allowed only to move forward but I still didn't manage to completely build gcc.
The best solution I found is to download compiled version of gcc-8.1 from:
https://solarianprogrammer.com/2017/12/07/raspberry-pi-raspbian-compiling-gcc/
I also ran into this problem when creating a containerized build environment for cross-compiled Qt applications for raspberry pi 4.
I found I needed to edit the mkspec for the linux-rasp-pi4-v3d device and add another cflag so that gcc could find the header from my Raspi sysroot that was used to cross-compile Qt.
Specifically under qtbase/mkspecs/devices/linux-rasp-pi4-v3d-g++/qmake.conf:
QMAKE_CFLAGS = -march=armv8-a -mtune=cortex-a72 -mfpu=crypto-neon-fp-armv8 -I$$[QT_SYSROOT]/usr/include/arm-linux-gnueabihf
I'm trying to merge the Mono Runtime (v 3.0.4) with a MonoMac application, but since the upgrade to 3.0.4 (from 2.10.11) this fails with the following error:
Merging Mono Runtime into app bundle
/Applications/MonoDevelop-old.app/Contents/MacOS/lib/monodevelop/AddIns/MonoDevelop.MonoMac/mmp
-nolink "-minos=10.6.6"
-o "/Users/ted/Documents/XCode/Mac/StageTimer/StageTimer/bin/Release"
-n "StageTimer"
-a "/Library/Frameworks/Mono.framework/Versions/3.0.4/lib/mono/4.0/System.dll"
-a "/Library/Frameworks/Mono.framework/Versions/3.0.4/lib/mono/4.0/System.Xml.dll"
-a "/Library/Frameworks/Mono.framework/Versions/3.0.4/lib/mono/4.0/System.Core.dll"
-a "/Library/Frameworks/Mono.framework/Versions/3.0.4/lib/mono/4.0/System.Xml.Linq.dll"
-a "/Library/Frameworks/Mono.framework/Versions/3.0.4/lib/mono/4.0/System.Drawing.dll"
-a "/Applications/MonoDevelop-old.app/Contents/MacOS/lib/monodevelop/AddIns/MonoDevelop.MonoMac/MonoMac.dll"
"/Users/ted/Documents/XCode/Mac/StageTimer/StageTimer/bin/Release/StageTimer.exe"
Process exited with code 1, command:
pkg-config --variable=prefix mono-2
Unhandled Exception: System.IO.DirectoryNotFoundException: Directory '/lib/mono/4.0' not found.
Even if I configure MonoDevelop to use Mono 2.10.11 instead of 3.0.4 it fails with the same error (and path: '/lib/mono/4.0'). Next I also tried modifying the symlink in /Library/Frameworks/Mono.framework/Versions/Current to point to 2.10.11 but still the same error & path.
Anyone with mono & pkg-config skills that knows how to configure this?
Similar issue happened to F# compiler when one tried to run it alongside Mono 3.0.4 (instead of 3.0.3). The issue boils down to a bugfix in Mono that prevents conflicting the homebrew pkg-config set up. The workaround that was adopted in F# sources was to hardcode the path to Mono's pkg-config.
You could probably get the same result as this by just overriding the environment variable PKG_CONFIG_PATH when launching MonoDevelop, this way:
PKG_CONFIG_PATH=/path/were/mono/pc/files/are/in/Mac:$PKG_CONFIG_PATH monodevelop
The exact path must be somewhere underneath /Library/Frameworks/Mono.framework/Versions/Current/ , just look out for files with .pc extension.
I'm trying to install apache from source on my mac. But keep running into problems. I've tried a ton of different things and just can't get this to build.
First, I couldn't configure without errors so I reinstalled apache apr. Now, I can configure but when I run make, I get this error:
libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'
I tried this to add in the libtool tag:
./configure LIBTOOL='/usr/local/bin/glibtool --tag=CC'
And this still gave the same error. I read that mountain lions glibtool is the unix-like libtool so that's why I tried this here. Still to no avail. I also tried symlinking the libtool that make uses to other versions on my machine, still to no avail, as I got the same error.
Here's what the make command runs, I tried symlinking /usr/share/apr-1/build-1/libtool
/usr/share/apr-1/build-1/libtool --silent --mode=compile /usr/local/Cellar/apple-gcc42/4.2.1-5666.3/bin/gcc-4.2 -std=gnu99 -O2 -arch x86_64 -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -I/opt/local/include -I/opt/X11/include -I. -I/usr/local/src/httpd-2.4.3/os/unix -I/usr/local/src/httpd-2.4.3/include -I/usr/include/apr-1 -I/usr/local/include -I/usr/local/src/httpd-2.4.3/modules/aaa -I/usr/local/src/httpd-2.4.3/modules/cache -I/usr/local/src/httpd-2.4.3/modules/core -I/usr/local/src/httpd-2.4.3/modules/database -I/usr/local/src/httpd-2.4.3/modules/filters -I/usr/local/src/httpd-2.4.3/modules/ldap -I/usr/local/src/httpd-2.4.3/modules/loggers -I/usr/local/src/httpd-2.4.3/modules/lua -I/usr/local/src/httpd-2.4.3/modules/proxy -I/usr/local/src/httpd-2.4.3/modules/session -I/usr/local/src/httpd-2.4.3/modules/ssl -I/usr/local/src/httpd-2.4.3/modules/test -I/usr/local/src/httpd-2.4.3/server -I/usr/local/src/httpd-2.4.3/modules/arch/unix -I/usr/local/src/httpd-2.4.3/modules/dav/main -I/usr/local/src/httpd-2.4.3/modules/generators -I/usr/local/src/httpd-2.4.3/modules/mappers -prefer-non-pic -static -c exports.c && touch exports.lo
This still didn't work.
Finally, I got further if I ran configure like this, ./configure --with-apr='/usr/local/src/apr/apr-config (where I installed the system, but this is still broken.) This got me further but it still wouldn't finish make, and gave me a ton of errors like this.
exports.c:1809: error: redefinition of 'ap_hack_apr_version_string'
exports.c:1141: error: previous definition of 'ap_hack_apr_version_string' was here
I finally figured it out ...
For anyone having trouble installing apache on Mountain Lion, it looks like the default LIBTOOLS in the source's build/config_vars.mk file is the wrong location.
I reinstalled LIBTOOLS with homebrew (which put it at /usr/local/bin/glibtool) and set this as the variable and all worked fine.