It's basically the same as this one which didn't really ended up.
I'm facing the same issue and I went a bit further. I had to change the code to allow a newer Macos sdk (10.11). So it compiled for a while but then failed whith this:
❯❯❯ perl build
Building Alien-wxWidgets
/Users/guiohm/.cpan/build/Alien-wxWidgets-0.67-rVjMTK/wxWidgets-3.0.2/bld/bk-deps clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.7 -c -o wxtiff_tif_lzma.o -DNDEBUG -I../src/jpeg -I/Users/guiohm/.cpan/build/Alien-wxWidgets-0.67-rVjMTK/wxWidgets-3.0.2/bld/src/tiff/libtiff -I../src/tiff/libtiff -dynamic -fPIC -DPIC -D_FILE_OFFSET_BITS=64 -I/Users/guiohm/.cpan/build/Alien-wxWidgets-0.67-rVjMTK/wxWidgets-3.0.2/bld/lib/wx/include/osx_cocoa-unicode-3.0 -I../include -Wall -Wundef -O2 -fno-strict-aliasing -fno-common ../src/tiff/libtiff/tif_lzma.c
../src/tiff/libtiff/tif_lzma.c:38:10: fatal error: 'lzma.h' file not found
#include "lzma.h"
^
1 error generated.
make: *** [wxtiff_tif_lzma.o] Error 1
system: make all: 512 at build line 68.
❯❯❯ brew search
lzma is now part of the xz formula.
❯❯❯ brew info
xz: stable 5.2.2 (bottled)
General-purpose data compression with high compression ratio
http://tukaani.org/xz/
/usr/local/Cellar/xz/5.2.2 (91 files, 1.4M) *
Poured from bottle
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/xz.rb
==> Options
--universal
Build a universal binary
❯❯❯ brew install xz
Warning: xz-5.2.2 already installed
❯❯❯ find / -name "lzma.h"
/usr/local/Cellar/xz/5.2.2/include/lzma.h
/usr/local/include/lzma.h
❯❯❯ ll /usr/local/include/lzm*
lrwxr-xr-x 1 guiohm admin 31 Oct 11 15:58 /usr/local/include/lzma -> ../Cellar/xz/5.2.2/include/lzma
lrwxr-xr-x 1 guiohm admin 33 Oct 11 15:58 /usr/local/include/lzma.h -> ../Cellar/xz/5.2.2/include/lzma.h
The weird thing is when I checked the config logs:
This one (./wxWidgets-3.0.2/bld/src/tiff/config.log) has other errors than lzma, for instance:
configure:18047: checking for lzma_code in -llzma
configure:18072: clang -o conftest -g -O2 -Wall -W -stdlib=libc++ conftest.c -llzma -ljpeg -lz >&5
configure:18072: $? = 0
configure:18081: result: yes
configure:18096: checking lzma.h usability
configure:18096: clang -c -g -O2 -Wall -W conftest.c >&5
configure:18096: $? = 0
configure:18096: result: yes
configure:18096: checking lzma.h presence
configure:18096: clang -E conftest.c
configure:18096: $? = 0
configure:18096: result: yes
configure:18096: checking for lzma.h
configure:18096: result: yes
configure:18199: checking for X
configure:18307: clang -E conftest.c
conftest.c:89:10: fatal error: 'X11/Xlib.h' file not found
#include <X11/Xlib.h>
^
1 error generated.
configure:18307: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "LibTIFF Software"
| #define PACKAGE_TARNAME "tiff"
See the full version.
Ans it's more or less the same with ./wxWidgets-3.0.2/bld/config.log.
When I changed the code to allow os10.10 SDK, it was previously expecting up to 10.8 or maybe 10.9. I suppose the whole issue comes now from this.
Should I try to fetch an old MacOS SDK?
Basically, I just want to compile Slic3r --gui from source, which requires Wx, which requires wxwidgets.
The problem here is that libtiff configure detects lzma.h under /usr/local because it doesn't use -isysroot, but its compilation does, because of the SDK option, and fails to find it. The right thing to do would be to use -I/usr/local/include explicitly in wxWidgets configure, but for now you should be able to work around this by doing export CPATH=/usr/local/include LIBRARY_PATH=/usr/local/lib to bypass it.
Alternatively (and IMHO preferably), do brew install tiff jpeg png (not sure that the formulae names are correct, please check them) to avoid building the builtin versions of these libraries in the first place.
Running brew install xz fixed the issue for me.
See https://stackoverflow.com/a/37594849/6381715
Related
I am using MacOS Mojave version 10.14.16 and I am trying to install http://www.rpl2.net/index.php (a programming language using Reverse Polish Notation as found on some HP calculators like the 48GX), supposed to work on MacOSX (they say "MacOS X (Xcode 3.1.4 + gfortran 4.5)").
So I have downloaded the latest stable release, cd to the folder, and wanted to run
./configure
make
make install
But the ./configure is failing due to "configure: error: Can not find libgomp !". There is no libgomp package I can install with brew (I already installed gcc which comes with gfortran and thought it would provide libgomp but apparently not).
Could someone help a poor applied mathematician trying to install a software on its macbook?
Thanks
EDIT
in my config.log I have this, maybe it will help:
configure:7433: checking for vim
configure:7449: found /usr/bin/vim
configure:7461: result: yes
configure:7507: checking for main in -lm
configure:7526: gcc -o conftest -g -O2 -O2 -fno-strict-overflow conftest.c -lm >&5
configure:7526: $? = 0
configure:7535: result: yes
configure:7548: checking for pthread_mutex_init in -lc
configure:7573: gcc -o conftest -g -O2 -O2 -fno-strict-overflow conftest.c -lc -lm >&5
configure:7573: $? = 0
configure:7582: result: yes
configure:7687: checking for omp_get_num_procs in -lgomp
configure:7712: gcc -o conftest -g -O2 -O2 -fno-strict-overflow conftest.c -lgomp -lc -lm >&5
ld: library not found for -lgomp
clang: error: linker command failed with exit code 1 (use -v to see invocation)
configure:7712: $? = 1
You don't say how you installed GCC. If you did it using homebrew, and
brew install gcc
you should be able to see:
/usr/local/Cellar/gcc/10.2.0/lib/gcc/10/libgomp.dylib
which would mean you need to compile with:
gcc ... -L /usr/local/Cellar/gcc/10.2.0/lib/gcc/10 -l gomp ...
Failing that, you can always search for libgomp with:
find /usr -name "lib*gomp*lib"
You can test which gcc you are using with:
type gcc
I am trying to compile lftp from source using gcc, compiler that I have also compiled from source under my home folder.
On build step I get an error:
/bin/sh ../libtool --silent --tag=CXX --mode=link g++ -O2 -Wall -Wwrite-strings -Woverloaded-virtual -fno-exceptions -fno-rtti -fno-implement-inlines -export-dynamic -s -o lftp lftp-lftp.o lftp-complete.o lftp-lftp_rl.o lftp-attach.o liblftp-jobs.la liblftp-tasks.la -L/usr/lib -lreadline -lutil -lncurses -ldl
/gsa/pokgsa/home/l/e/leonidt/local/lib/../lib/libstdc++.so: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
make[2]: * [lftp] Error 1
make[2]: Leaving directory /gsa/pokgsa-h3/19/leonidt/local/lftp-4.8.4/src'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory/gsa/pokgsa-h3/19/leonidt/local/lftp-4.8.4'
make: * [install] Error 2
So looks like compiler was built with libstdc++.so for wrong architecture?
I tried to check what's in libstdc++.so:
file /gsa/pokgsa/home/l/e/leonidt/local/lib/libstdc++.so
/gsa/pokgsa/home/l/e/leonidt/local/lib/libstdc++.so: symbolic link to `libstdc++.so.6.0.27'
file /gsa/pokgsa/home/l/e/leonidt/local/lib/libstdc++.so.6.0.27
/gsa/pokgsa/home/l/e/leonidt/local/lib/libstdc++.so.6.0.27: **ELF 32-bit** MSB shared object, IBM S/390, version 1 (GNU/Linux), dynamically linked, not stripped
Below are the steps I did to build gcc in my local folder:
cd ~/local
Uncompressed the gcc-9.2.0.tar.xz
got ~/local/gcc-9.2.0 created with gcc source
cd ../gcc-9.2.0/
Downloaded prerequisites
contrib/download_prerequisites
cd ~/local/gcc-build
../gcc-9.2.0/configure --prefix /gsa/pokgsa/home/l/e/leonidt/local/ --enable-languages=c,c++
I am on SuSe Linux:
uname -a
Linux zdsdeveng03 3.0.101-108.84-default #1 SMP Fri Nov 30 15:57:27 UTC 2018 (7a72692) s390x s390x s390x GNU/Linux
cat /etc/os-release NAME="SLES"
VERSION="11.4"
VERSION_ID="11.4"
PRETTY_NAME="SUSE Linux Enterprise Server 11 SP4"
ID="sles"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:11:4"
You have to specify architecture(s) for configure script.
https://gcc.gnu.org/install/configure.html
I'm trying to build Guile 2.2.
I've installed libunistring to /path/to/libunistring.
When I run
./configure --with-libunistring-prefix=/path/to/libunistring/
it fails, because it can't find libunistring.
configure:15954: checking for libunistring
configure:15976: gcc -std=gnu11 -o conftest -g -O2 conftest.c -lunistring >&5
conftest.c:158:21: fatal error: uniconv.h: No such file or directory
#include <uniconv.h>
How do I fix this?
The configure script is searching for /path/to/libunistring/lib64/. I believe you have only /path/to/libunistring/lib/.
% ln -s /path/to/libunistring/lib /path/to/libunistring/lib64
I have problem when try to install Perl module DBD:Oracle with below env
Fedora 20 64 bit
Perl 5.18 64 bit
Oracle 10g 32 bit
When try to make, it inform below error
Running Mkbootstrap for DBD::Oracle ()
chmod 644 Oracle.bs
rm -f blib/arch/auto/DBD/Oracle/Oracle.so
gcc -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wl,-z,relro Oracle.o dbdimp.o oci8.o -o blib/arch/auto/DBD/Oracle/Oracle.so \
-L/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib/ -lclntsh -lpthread -lperl \
/bin/ld: skipping incompatible /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib//libclntsh.so when searching for -lclntsh
/bin/ld: cannot find -lclntsh
collect2: error: ld returned 1 exit status
make: *** [blib/arch/auto/DBD/Oracle/Oracle.so] Error 1
PYTHIAN/DBD-Oracle-1.74.tar.gz
/bin/make -- NOT OK
Running make test
Can't test without successful make
Running make install
Make had returned bad status, install seems impossible
Failed during this command:
PYTHIAN/DBD-Oracle-1.74.tar.gz : make NO
It seems that Perl try to search for Oralce 64bit lib but can not and error occur.
Can any one help me on this if I need to config anything before build the package?
Thanks,
Quang
I've installed gcc on my Mac (Snow Leopard) so I can compile for AVR microcontrollers. However, it seems to be preventing me from compiling for anything else. I'd like to build the packages from astrometry.net, and when I run ./configure then make i get the following:
make -C ./qfits-an stage CFLAGS=" -g -Wall -ffinite-math-only -fno-signaling-nans -march=native -O3 -fomit-frame-pointer -DNDEBUG -fPIC -Winline -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE" LDFLAGS=" -g -Wall -ffinite-math-only -fno-signaling-nans -march=native -O3 -fomit-frame-pointer -DNDEBUG -fPIC -Winline" CC="gcc"
make -C src stage
gcc -g -Wall -ffinite-math-only -fno-signaling-nans -march=native -O3 -fomit-frame-pointer -DNDEBUG -fPIC -Winline -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -c -o anqfits.o anqfits.c
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc -v gives:
Using built-in specs.
Target: avr
Configured with: ./configure --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --prefix=/usr/local/staging.avr-gcc
Thread model: single
gcc version 4.1.1
I'm not sure how to proceed! It seems that currently everything is set up to only build for the AVR platform, but I have Xcode installed so somewhere there are more versions of gcc lurking. This install was via http://www.micahcarrick.com/installing-gnu-tools-avr-gcc.html if that helps to see how it was set up (I had Xcode installed prior to this).
The solution, I expect, is simple. I just want to avoid messing up my settings and then not being able to compile for either platform.
Many thanks!
You probably want to remove the non-cross-compiler named versions of the AVR tools you have installed (i.e. gcc, ld, etc.), so the cross-compiler, and related tools, are only available using target-specific names.
To do this, find the directory where they are installed (/usr/local/bin ?) and find all the tools installed at the same time. As an example, this is what happens on my Linux machine (to give you an idea):
$ which gcc
/usr/bin/gcc
$ cd /usr/bin
$ ls -li *gcc*
189389 -rwxr-xr-x 2 root root 268088 Dec 6 2011 gcc
195145 -rwxr-xr-x 1 root root 2018 Aug 16 2010 gccmakedep
189389 -rwxr-xr-x 2 root root 268088 Dec 6 2011 x86_64-redhat-linux-gcc
I would then remove gcc, leaving x86_64-redhat-linux-gcc as the only way of starting that compiler (they are hard linked as they share the same inode). There will be other tools as well, which you can identify by date in the same directory.
An alternative approach is to install the cross-compiler into a directory that isn't in your $PATH.