I have followed the instruction on the "GMP Install Instruction for Windows Platform". I could build a 32bit version of GMP which can be used for Visual Studio.
./configure --prefix=${gmp-install} --disable-static --enable-shared
make
make install
Then I installed mingw_w64 and msys on another machine (which is running 64bit Windows) and rerun the commands.
./configure was run without any problem. However, when I run "make", I got the following.
m4 -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_add_n -DDLL_EXPORT -DPIC add_n.asm >tmp-add_n.s
gcc -std=gnu99 -c -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_add_n -O2 -pedantic -fomit-frame-pointer -mno-cygwin tmp-add_n.s -DDLL_EXPORT -DPIC -o .libs/add_n.o
tmp-add_n.s: Assembler messages:
tmp-add_n.s:84: Error: operand type mismatch for `push'
tmp-add_n.s:85: Error: operand type mismatch for `push'
tmp-add_n.s:86: Error: operand type mismatch for `push'
tmp-add_n.s:107: Error: operand type mismatch for `jmp'
tmp-add_n.s:114: Error: operand type mismatch for `pop'
tmp-add_n.s:115: Error: operand type mismatch for `pop'
tmp-add_n.s:116: Error: operand type mismatch for `pop'
make[2]: *** [add_n.lo] Error 1
make[2]: Leaving directory `/d/Temp/gmp-5.0.1/mpn'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/d/Temp/gmp-5.0.1'
make: *** [all] Error 2
If I used "gmake" instead, the following error was shown.
m4 gcc -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_add_n -DDLL_EXPORT -DPIC add_n.asm >tmp-add_n.s
m4: gcc: No such file or directory
gmake[2]: *** [add_n.lo] Error 1
gmake[2]: Leaving directory `d:/Temp/gmp-5.0.1/mpn'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `d:/Temp/gmp-5.0.1'
gmake: *** [all] Error 2
I am not familiar with C++ make. Do I need to specify any flag in order to notify mingw_w64 that I am building for 64bit? Thanks.
For me, gmp was successfully built for x86, and I have had problems building x64. The problem was in the following:
In mpn\fib_table.c:
#if GMP_NUMB_BITS != 32
Error, error, this data is for 32 bits
#endif
while in gmp.h:
#define GMP_LIMB_BITS 64
#define GMP_NAIL_BITS 0
#define GMP_NUMB_BITS (GMP_LIMB_BITS - GMP_NAIL_BITS)
fib_table.c is generated by gen-fix.exe tool, and this tool is generated by make.
So, if one tries to build x64 build after building x86 (like me), it is not enough to run "make clean" first. Delete all "gen-*.exe" files in gmp root folder after running "make clean", this files will be rebuilt properly by make. gmp x64 was successfully build for me after that.
Tested on gmp 6.0.0.
How I built dynamic dll gmp-6.1.2 for windows so that the dll can be linked for a visual studio project.
Setup Environment
Install 7-Zip
Install Cygwin, add the following packages to the default installation
gcc-core
gcc-g++
libgcc
m4
make
cmake
bash
Add the following Environment Variable to the User PATH: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\Hostx64\x64
This is so you can use the lib command. Your lib.exe may be located elsewhere.
Build GMP
Download the tar.bz2 version from https://gmplib.org/#DOWNLOAD and extract the gmp-6.1.2 folder with 7-zip.
Launch bash.exe from C:\cygwin64\bin.
Change directory to the unzipped gmp-6.1.2 folder. Ex: cd "A:\Code\gmp-6.1.2"
Execute ./configure --disable-static --enable-shared
Execute make
This will create cyggmp-10.dll under A:\Code\gmp-6.1.2\.libs\
Execute make check
Execute cd ./libs
Execute lib /machine:i386 /def:cyggmp-10.dll
This will generate cyggmp-10.exp and cyggmp-10.lib under A:\Code\gmp-6.1.2\.libs\ for use with visual studio
You now have everything needed to call gmp from C# code.
See http://gladman.plushost.co.uk/oldsite/computing/gmp4win.php , and note this paragraph;
GMP cannot, however, provide high
performance 64-bit libraries on
Windows because its 64-bit assembler
code is incompatible with Windows x64
calling conventions. This means that
64-bit GMP libraries on WIndows are
very slow when compared with MPIR,
which has excellent 64-bit assembler
support.
So you either disable assembly with ./configure --disable-assembly or use MPIR.
You might want to take a look at MPIR. It is a fork of GMP that natively supports Visual Studio.
I have tried the following. The library can be built successfully.
./configure --prefix=/d/Temp/gmp-5.0.1-install --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --disable-static --enable-shared
Related
After upgrading python 3.8.6 to 3.9.10 using homebrew, my Cython extensions no longer without explicitly adding /usr/local/include (for my Intel MacBook) or /opt/homebrew/include to the include_dirs of my extension.
My setup.py.in:
import os, sys
from numpy.distutils.core import setup, Extension
from Cython.Build import cythonize
link_arguments = []
extra_include_dirs = []
if (sys.platform == 'darwin'):
link_arguments.append("-Wl,-rpath")
link_arguments.append("-Wl,#loader_path/")
if os.path.exists('/opt/homebrew/'):
extra_include_dirs.append("/opt/homebrew/include/")
else:
extra_include_dirs.append("/usr/local/include/")
else:
link_arguments.append("-Wl,-rpath=${CMAKE_SOURCE_DIR}/lib/")
pynwp_extension = Extension(
name="pynwp",
sources=["${CMAKE_CURRENT_SOURCE_DIR}/lambert.f90", "${CMAKE_CURRENT_SOURCE_DIR}/pynwp.f90", "${CMAKE_CURRENT_SOURCE_DIR}/readAtmosphereGen.f90", "${CMAKE_CURRENT_SOURCE_DIR}/ptogrot.f", "${CMAKE_CURRENT_SOURCE_DIR}/bilin1.f", "${CMAKE_CURRENT_SOURCE_DIR}/fl2pres_f.f","${CMAKE_CURRENT_SOURCE_DIR}/message.c","${CMAKE_CURRENT_SOURCE_DIR}/gridWindDirCorrection.F"],
libraries=["HirlamUtils_fPIC", "eccodes_f90", "jasper"],
library_dirs=["${PROJECT_BINARY_DIR}", "${CMAKE_SOURCE_DIR}/build${CMAKE_BUILD_TYPE}/src/libHirlamUtils/", "/opt/homebrew/lib/"],
extra_link_args = link_arguments,
include_dirs=["${CMAKE_SOURCE_DIR}/include", "/usr/lib64/gfortran/modules/",
"${CMAKE_SOURCE_DIR}/build${CMAKE_BUILD_TYPE}"] + extra_include_dirs,
extra_f90_compile_args=["-DLINUX", "-DIS_LITTLE_ENDIAN", "-DUSEWALLTIME", "-DHAS_BLAS", "-DHAS_LAPACK", "-DGRIB32", "-DTIMING", "-DPREC32", "-fno-whole-file", "-g", "-fbounds-check"]
#compiler_directives={'language_level' : "3"}
)
setup(name="pynwp",
author="me",
author_email="me!me.com",
version="1.0.1",
description="Python wrapper for pynwp",
package_dir={"": "${CMAKE_CURRENT_SOURCE_DIR}"},
url="http://emaddc.eu",
license="MIT License",
ext_modules=[pynwp_extension]
)
In the file above, I have hardcoded the location (temporarily) of the homebrew library dir and added some functionality for the include dir based on /opt/homebrew being found. If I remove this from the file, compilation fails as eccodes.mod cannot be found, see the output when I run the command generate by python/CMake manually:
buildDebug git:(master) ✗ /opt/homebrew/bin/gfortran -Wall -g -fno-second-underscore -fPIC -O3 -funroll-loops -I<project_dir>//include -I/usr/lib64/gfortran/modules/ -I<project_dir>//buildDebug -Ibuild/src.macosx-12-arm64-3.9/build/src.macosx-12-arm64-3.9 -I/opt/homebrew/lib/python3.9/site-packages/numpy/core/include -Ibuild/src.macosx-12-arm64-3.9/numpy/distutils/include -I/opt/homebrew/opt/python#3.9/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c -c <project_dir>//src/pynwp/readAtmosphereGen.f90 -o build/temp.macosx-12-arm64-3.9<project_dir>//src/pynwp/readAtmosphereGen.o -DLINUX -DIS_LITTLE_ENDIAN -DUSEWALLTIME -DHAS_BLAS -DHAS_LAPACK -DGRIB32 -DTIMING -DPREC32 -fno-whole-file -g -fbounds-check
f951: Warning: Nonexistent include directory '/usr/lib64/gfortran/modules/' [-Wmissing-include-dirs]
f951: Warning: Nonexistent include directory 'build/src.macosx-12-arm64-3.9/build/src.macosx-12-arm64-3.9' [-Wmissing-include-dirs]
f951: Warning: Nonexistent include directory 'build/src.macosx-12-arm64-3.9/numpy/distutils/include' [-Wmissing-include-dirs]
<project_dir>//src/pynwp/readAtmosphereGen.f90:3:7:
3 | use eccodes
| 1
Fatal Error: Cannot open module file 'eccodes.mod' for reading at (1): No such file or directory
compilation terminated.
This extension is part of a larger project that is build using CMake. When running the gfortran command manually, the same errors indicating that eccodes.mod cannot be found. The file is however located on a default location on the gfortran/gcc search path:
locate eccodes.mod
/opt/homebrew/Cellar/eccodes/2.24.2/include/eccodes.mod
/opt/homebrew/include/eccodes.mod
And the search path for gfortran:
gfortran -E -Wp,-v -
#include <...> search starts here:
/opt/homebrew/include
/opt/homebrew/Cellar/gcc/11.2.0_3/bin/../lib/gcc/11/gcc/aarch64-apple-darwin21/11/include
/opt/homebrew/Cellar/gcc/11.2.0_3/bin/../lib/gcc/11/gcc/aarch64-apple-darwin21/11/include-fixed
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks
End of search list.
Another project uses gcc/ld and has a similar problem. I need to explicitly add LINK_DIRECTORIES(/opt/homebrew/lib) to CMakeList.txt in order for gcc to find the eccodes library. Without that, I get:
gcc-11: warning: this compiler does not support X86 (arch flags ignored)
ld: library not found for -leccodes
collect2: error: ld returned 1 exit status
make[2]: *** [src/smoothModeS-v51/smoothModeS-v51.x] Error 1
make[1]: *** [src/smoothModeS-v51/CMakeFiles/smoothModeS-v51.x.dir/all] Error 2
make: *** [all] Error 2
Adding the paths to CPATH and LIBRARY_PATH had no effect.
This method works but seems hard to maintain. What am I missing and what has changed that gfortran/gcc no longer search in the default paths for but libraries and headers/modules?
EDIT
Just found that the standalone executable that uses similar code as the python extension and also uses eccodes has a similar issue. If I do not include INCLUDE_DIRECTORIES(/opt/homebrew/include) in CMakeLists.txt , I get:
cd <project_dir>/buildDebug/src/collocEHS && /opt/homebrew/bin/gfortran -I<project_dir>/buildDebug -I<project_dir>/include -I<project_dir>/src/readASTERIX2 -I<project_dir>/src/geomag70_linux -I<project_dir>/src/libDTG -fallow-argument-mismatch -ffpe-trap=invalid,zero,overflow -DPREC32 -DLINUX -DIS_LITTLE_ENDIAN -DUSEWALLTIME -DHAS_BLAS -DHAS_LAPACK -DGRIB32 -DTIMING -ffixed-line-length-none -g -fcheck=all -Wall -fcheck=bounds -O0 -g -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk -c <project_dir>/src/pynwp/readAtmosphereGen.f90 -o CMakeFiles/collocEHSv2.dir/__/pynwp/readAtmosphereGen.f90.o
<project_dir>/src/pynwp/readAtmosphereGen.f90:3:7:
3 | use eccodes
| 1
Fatal Error: Cannot open module file 'eccodes.mod' for reading at (1): No such file or directory
compilation terminated.
make[2]: *** [src/collocEHS/CMakeFiles/collocEHSv2.dir/__/pynwp/readAtmosphereGen.f90.o] Error 1
make[1]: *** [src/collocEHS/CMakeFiles/collocEHSv2.dir/all] Error 2
make: *** [all] Error 2
So I guess the problem is unrelated to python but more with gcc/gfortran (gcc version 11.2.0 (Homebrew GCC 11.2.0_3).
EDIT 2
A reboot of the laptop fixed the issue with the python extension build and setup.py requiring additional directories. For normal builds using CMake, I still require the extra INCLUDE_DIRECTORIES and LINK_DIRECTORIES order for gcc/gfortran to find libraries installed by brew in /opt/homebrew (or /usr/local for intel MacBook).
As per homebrew devs, this is desired behaviour: /opt/homebrew and /usr/local are "special" directories to be manually added in e.g., CMake projects. This is explained in my bug report on home-brew's GitHub, see https://github.com/Homebrew/homebrew-core/issues/95561.
I haven't been able to confirm this with documentation.
I'm triing to compile the superoptimizer on windows. (https://github.com/bonzini/superopt)
Unfortunatly my knowledge of make is very limited. I tried:
make CPU=-D386 superopt
Which gives me the error:
cc superopt.c -o superopt
process_begin: CreateProcess(NULL, cc superopt.c -o superopt, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [superopt] Fehler 2
After setting the compiler to gcc manually with:
make CPU=-D386 superopt CC=gcc
I get the following error:
gcc superopt.c -o superopt
In file included from superopt.c:27:0:
superopt.h:104:2: error: #error You have to choose target CPU type (--with-arch).
#error You have to choose target CPU type (--with-arch).
^
In file included from superopt.h:130:0,
from superopt.c:27:
longlong.h:1465:14: error: unknown type name 'UQItype'
extern const UQItype __clz_tab[];
^
superopt.c:32:21: fatal error: version.h: No such file or directory
compilation terminated.
make: *** [superopt] Fehler 1
It seems it does't properly selects i386.
Any hints would be greatly appreciated.
That is not the source code of
GNU superopt. It is the source code of someone's project
to patch GNU superopt, last updated 2008, and seemingly
abandoned a hard-hat area.
This is the source code of
GNU superopt. Extract the tarball and build as you have attempted
with:
make CC=gcc CPU=-DI386 superopt
Note: I386, not 386.
You will see warnings like:
warning: incompatible implicit declaration of built-in function 'foo'
because the 20 yearold C code does not diligently include the standard
headers that prototype the standard functions that it calls, but superopt will build successfully.
Since several versions of GCC and Ubuntu I am experiencing annoying issues with paths and naming of several header and object files that are necessary for the installation of GCC.
Description: After installing ubuntu (e.g. in my case 12.04) and installing all prerequisites of the gcc, I run the following commands:
sudo mkdir /usr/local/stow/gcc-4.8.0
./configure --prefix /usr/local/stow/gcc-4.8.0
make
sudo make install
For the sake of completeness, the rest of the installation procedure:
cd /usr/local/stow
sudo stow -t /usr/local/ gcc-4.8.0
gcc -v
However, this simple and proper way of installing gcc has some issues during the 'make' step with the following error messages:
1.) The problem with 'stubs.h'
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
which can be fixed with the following commands added to ~/.bashrc:
if [ -z "$CPATH"]; then
export CPATH="/usr/include/i386-linux-gnu"
else
export CPATH=$CPATH:"/usr/include/i386-linux-gnu"
fi
2.) The problem with 'crti.o', 'crtn.o', and 'crt1.o'
/usr/bin/ld: cannot find crti.o: No such file or directory
/usr/bin/ld: cannot find crtn.o: No such file or directory
/usr/bin/ld: cannot find crt1.o: No such file or directory
which can be fixed with the very ugly solution:
sudo ln -s /usr/lib/i386-linux-gnu/crti.o /usr/lib/i386-linux-gnu/crtn.o /usr/lib/i386-linux-gnu/crt1.o /usr/lib
since - and I don't know why - the following commands do not solve the problem during linking steps of 'sudo make install'
if [ -z "$LIBRARY_PATH"]; then
export LIBRARY_PATH="/usr/lib/${multiarch}"
else
export LIBRARY_PATH=$LIBRARY_PATH:"/usr/lib/${multiarch}"
fi
if [ -z "$LD_LIBRARY_PATH"]; then
export LD_LIBRARY_PATH="/usr/lib/${multiarch}"
else
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:"/usr/lib/${multiarch}"
fi
(With these solutions I could compile GCC-4.7.2 on Ubuntu 12.04. - I have still issues compiling GCC-4.8.0 on Ubuntu 12.04, but that's different topic.)
My questions are: Does anybody know the reason/background that we have these issues? Does anybody know a proper solution? (With "proper solution" I mean a solution that does not require setting environment variables or symbolic linking libraries to different directories. To me these kind of changes are ugly, since they require changes to the system that one may not be able to trace back or redo.)
In the root folder of your GCC source execute ./contrib/download_prerequisites script.
These are the issues i encountered while compiling GCC 4.8.0 on Ubuntu 12.04 with solutions.
This might help you.
Compilation guide for compiling GCC 4.8 on ubuntu 12.04
ERROR 1
configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
their locations. Source code for these libraries can be found at
their respective hosting sites as well as at
ftp://gcc.gnu.org/pub/gcc/infrastructure/. See also
http://gcc.gnu.org/install/prerequisites.html for additional info. If
you obtained GMP, MPFR and/or MPC from a vendor distribution package,
make sure that you have installed both the libraries and the header
files. They may be located in separate packages.
SOLUTION
Download and install gmp version >=4.3.2 package because mpc needs higher version
download the source code from gmplib.org
compile the source code and install
while compiling gmp see ERROR 2 for help
Installed gmp version 5.1.1
Download and install mpfr package
Installed mpfr version 3.1.2
Download and install mpc package
Installed mpc version 1.0
Download the packages from
http://ftp.gnu.org
ERROR 2
Error while compiling gmp library
checking for suitable m4... configure: error: No usable m4 in $PATH or /usr/5bin
SOLUTION
sudo apt-get install m4
http://ubuntuforums.org/showthread.php?t=850491
ERROR 3
Cannot find g++ compiler
I got this error because I installed the OS recently and had not installed the compilers.
SOLUTION
sudo apt-get install build-essential
This installs all the standard build essential software
ERROR 4
checking for i686-pc-linux-gnu-gcc... /home/suhastheju/projects/gcc/gcc-4.8.0/host-i686-pc-linux-gnu/gcc/xgcc -B/home/suhastheju/projects/gcc/gcc-4.8.0/host-i686-pc-linux-gnu/gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include
checking for suffix of object files... configure: error: in `/home/suhastheju/projects/gcc/gcc-4.8.0/i686-pc-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage1-target-libgcc] Error 1
make[2]: Leaving directory `/home/suhastheju/projects/gcc/gcc-4.8.0'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/suhastheju/projects/gcc/gcc-4.8.0'
make: *** [all] Error 2
SOLUTION
Though gcc documentation specify , that , we can provide the path of gmp
and mpfr installtion through –with-gmp and –with-mpfr flag ,
but unfortunately , i tried to give the path but it didnt work.
I am not in position to say final word about , this , whether it is a bug
in build script or something else , but bellow is the solution of the problem.
while building , add gmp and mpfr installation path in LD_LIBRARY_PATH environment
variable. Do as follows
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
If you have the libraries in different path, add the path where libraries are present
ERROR 5
libbackend.a(tree-vect-data-refs.o):tree-vect-data-refs.c:(.text+0x87da): more undefined references to `vector_type_mode(tree_node const*)' follow
collect2: error: ld returned 1 exit status
make[3]: *** [cc1] Error 1
make[3]: Leaving directory `/home/suhastheju/projects/gcc/gcc-4.8.0/host-i686-pc-linux-gnu/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/suhastheju/projects/gcc/gcc-4.8.0'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/suhastheju/projects/gcc/gcc-4.8.0'
make: *** [all] Error 2
SOLUTION
recompiled the source code from begining, It worked magically
make clean all
ERROR 6
/home/suhastheju/projects/gcc/gcc-4.8.0/host-i686-pc-linux-gnu/gcc/../.././gcc/gcov.c:416: undefined reference to `gcc_init_libintl()'
collect2: ld returned 1 exit status
make[3]: *** [gcov] Error 1
make[3]: Leaving directory `/home/suhastheju/projects/gcc/gcc-4.8.0/host-i686-pc-linux-gnu/gcc'
SOLUTION
Added -I/usr/include
I am trying to build from the bigloo scheme's latest source 3.8a on a Linux Mint 12 (lisa), which is Ubuntu 11 (Oneric) derivative:
Here is my "configure":
./configure --enable-pthread --enable-fthread --enable-ssl --enable-sqlite --enable-web --enable-multimedia --enable-mail --enable-calendar --enable-pkgcomp --enable-pkglib --enable-gstreamer --enable-text --enable-srfi1 --enable-srfi27 --enable-crypto --enable-openpgp --enable-phone --enable-alsa --enable-mpg123 --enable-csv --jvm=yes
** Configuration summary **
Release features:
release number.............. 3.8a
supported backends.......... native:yes JVM:yes
default backend............. native
additional APIs............. pthread fthread sqlite web multimedia mail calendar pkgcomp pkglib text srfi1 srfi27 packrat crypto openpgp phone mpg123 csv
native threads support...... yes
openssl support............. no
sqlite support.............. sqltiny + sqlite
dynamic libraries support... yes
Bee configuration:
bee support................. partial
emacs....................... emacs
emacs brand................. emacs23
Implementation details:
tuning...................... standard
cc.......................... gcc
gc.......................... custom (bigloogc-3.8a, v731)
Java version................ 1.3
bignum support.............. gmp (5.0.1)
Directories where Bigloo will be installed:
binaries.................... /usr/local/bin
libraries................... /usr/local/lib
files directory............. bigloo/3.8a
standard zip................ /usr/local/lib/bigloo/3.8a
standard dll................ /usr/local/lib/bigloo/3.8a
manual pages................ /usr/local/man/man1
info documentation.......... /usr/local/info
lisp files..................
temporary build dir......... /tmp
The "make" succeeds; however "make test" fails for pthread
*** pthread **********
make[2]: Entering directory `/home/liew/Downloads/bigloo3.8a/api/pthread/recette'
/home/liew/Downloads/bigloo3.8a/bin/bigloo -c -call/cc -O3 -fcfa-arithmetic -q recette.scm -o recette.o
/home/liew/Downloads/bigloo3.8a/bin/bigloo -O3 -fcfa-arithmetic -q recette.o -o recette
/usr/bin/ld: recette: hidden symbol `pthread_atfork' in /usr/lib/i386-linux-gnu/libpthread_nonshared.a(pthread_atfork.oS) is referenced by DSO
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make[2]: *** [recette] Error 1
make[2]: Leaving directory `/home/liew/Downloads/bigloo3.8a/api/pthread/recette'
make[1]: *** [c-test] Error 1
make[1]: Leaving directory `/home/liew/Downloads/bigloo3.8a'
make: *** [test] Error 2
According to this excellent post about this pthread issue, we need to rearrange the command line parameters while linking pthread library. However, I was unable to find the required Makefile code - probably because it relies on the Makefile default that links the library in a certain way.
Any help will be appreciated.
The problem is probably fixed in newer versions of bigloo.
I'm trying to create a project as a shared library in OS X using CMake 2.8 and gcc 4.6 (from macports). When CMake gets to the point of linking my library into a .dylib, I get the following error from gcc:
g++ -dynamiclib -headerpad_max_install_names -o libmycoollibrary.dylib etc...
g++: error: unrecognized option '-h'
make[2]: *** [libnrtCore.dylib] Error 1
make[1]: *** [CMakeFiles/nrtCore.dir/all] Error 2
make: *** [all] Error 2
This -headerpad_max_install_names seems to be the problem, but I've never seen it before. Does anyone know how to either get CMake to not include this option, or to get GCC to accept this option?
You can re-build cmake to fix this -- it's apparently generating code for the XCode / Darwin version of g++ (a special version of 4.2), which accepts a number of non-standard linker flags.
Just change the Modules/Platform/Darwin*.cmake files and re-build. The culprit lines look like this:
SET(CMAKE_CXX_LINK_FLAGS "-Wl,-search_paths_first -headerpad_max_install_names")