Merging Mono Runtime 3.0.4 with MonoDevelop 3.x fails - mono

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.

Related

Meet "dyld: Library not loaded of wrong architecture" for libquadmath.0.dylib when running scip

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

Raspberry Pi -fatal error: sys/cdefs.h: No such file or directory

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

Building Apache on Mountain Lion libtool problems

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.

How to compile rabbitmq-c library on Mac OS X?

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

Install apache module X-Sendfile on MAMP

How can I install X-Sendfile apache module so that MAMP can use it?
I have followed these instructions to install X-Sendfile, but it didn't work (it seems like it just installed it for the default apache installation). I also tried to manually copy /usr/libexec/apache2/mod_xsendfile.so to /Applications/MAMP/Library/modules/, but that produced the following error when restarting Apache:
Cannot load /Applications/MAMP/Library/modules/mod_xsendfile.so into server: cannot create object file image or add library
naabster's answer is correct if your MAMP binary is built for the same architecture as your kernel. The problem you're having might be that MAMP is not built using the same architecture -- I have Lion running here (10.7.3) with XAMPP 1.7.3 and I just ran across the same issue you were having.
Here's how I figured out what was wrong on my system, and how I fixed it. If your issue is the same as mine, then you should be able to follow along and verify as you go.
First, here's the output of 'uname -a' to show you that what I'm running:
Darwin Tads-Mac-Pro.local 11.3.0 Darwin Kernel Version 11.3.0:
Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64
Here are the steps I took to track down the problem and fix it:
Figure out what attributes the other (working) modules had that my freshly-built xsendfile module was missing. I picked mod_headers.so as an example. The command to find that info is 'file [filename]'. I'm running this from a terminal cd'd to the /Applications/XAMPP/xamppfiles/modules directory:
file mod_headers.so
mod_headers.so: Mach-O universal binary with 2 architectures
mod_headers.so (for architecture i386): Mach-O bundle i386
mod_headers.so (for architecture ppc): Mach-O bundle ppc
As you can see, XAMPP kindly provides a universal binary that supports i386 and ppc architectures. However, because the Lion kernel is running x86_64, everything I build using apxs unless I tell it to otherwise will be x86_64.
Check the mach-o bundle type and architecture(s) supported by the module that was built with the recommended apxs build command ('sudo apxs -cia mod_xsendfile.c'). Because we're passing '-i' the apxs will install the .so into the default apache modules dir ... /usr/libexec/apache2...
file /usr/libexec/apache2/mod_xsendfile.so
/usr/libexec/apache2/mod_xsendfile.so: Mach-O 64-bit bundle x86_64
Just to double-check that this is the problem you can also look at the httpd (apache) binary:
file /Applications/XAMPP/xamppfiles/bin/httpd
/Applications/XAMPP/xamppfiles/bin/httpd: Mach-O universal binary with 2 architectures
/Applications/XAMPP/xamppfiles/bin/httpd (for architecture i386): Mach-O executable i386
/Applications/XAMPP/xamppfiles/bin/httpd (for architecture ppc): Mach-O executable ppc
Well now, that certainly will not work with an apache instance built without an x86_64 image. Trust, but verify, eh!
Now that I'm certain I understand the issue, let's re-build the .so with the proper architecture forced on the apxs command line. To do that I'm just adding two new params, Wl (linker flags) and Wc (compiler flags). The -i means 'install' (move .so into the modules directory) and the -a means 'activate' (add or re-enable LoadModule line in the httpd.conf)
sudo apxs -cia -Wl,"-arch i386" -Wc,"-arch i386" mod_xsendfile.c
re-check that our new .so supports an architecture that matches the Apache installed (i386, not x86_64)
file /Applications/XAMPP/xamppfiles/modules/mod_xsendfile.so
/Applications/XAMPP/xamppfiles/modules/mod_xsendfile.so: Mach-O bundle i386
Awesome. Now then, copy this turkey into the XAMPP install dir:
sudo cp /usr/libexec/apache2/mod_xsendfile.so /Applications/XAMPP/xamppfiles/modules/
And add the LoadModule line to the /Applications/XAMPP/xamppfiles/etc/httpd.conf.
LoadModule xsendfile_module modules/mod_xsendfile.so
You should be able to fire up the server using either the UI or the apachectl script found in the xamppfiles/bin directory.
Hope that helps you.
Also, I did a pretty decent due-diligence search and found just about squat looking for 'XAMPP X-SendFile cannot create object' in the Goog. What I did find was your question here, once I eliminated the 'XAMPP' since I was searching for 'XAMPP', not 'MAMP'
I started out with the 'x'AMP stack something like 10 years back using LAMPP, then WAMPP but the ApacheFriends guys call theirs XAMPP now for all of the platforms they support. I prefer using theirs since I know if I have to set up on a Windows server I can just download the same package that I use now but for Windows and I can expect to find all of the same servers installed without (too many) surprises.
So, just to be (very) thorough, the other way to discover these types of problems more easily is via Console.app. Open that up, filter on org.apache.httpd and you should see something similar to this:
httpd: Syntax error on line 117 of /private/etc/apache2/httpd.conf: Cannot load
/usr/libexec/apache2/mod_xsendfile.so into server:
dlopen(/usr/libexec/apache2/mod_xsendfile.so, 10): no suitable image found.
Did find:\n\t/usr/libexec/apache2/mod_xsendfile.so: mach-o, but wrong architecture
You can also get that from a command line when you start the apache server manually:
sudo apachectl -E /tmp/foo.txt -k start; tail -f /tmp/foo.txt
This worked for me:
Install mod_xsendfile according to this for the default OsX Apache server.
copy /usr/libexec/apache2/mod_xsendfile.so to /Applications/MAMP/Library/modules/
Edit the Mamp httpd.conf file and add this line: LoadModule xsendfile_module modules/mod_xsendfile.so
Restart Mamp