How to build zlib library on a m1 chip macbookpro? - c++

I downloaded zlib from https://zlib.net/ and execute ./configure and make cmd. However, it shows that there are some undefined symbols for architecture arm64. How to build zlib in this case?
I'm using a macbookpro 2021 with apple m1pro chip.
The full info is:
~/GitClone/zlib-1.2.11 > ./configure at 15:42:53
Checking for gcc...
Checking for shared library support...
Building shared library libz.1.2.11.dylib with gcc.
Checking for size_t... Yes.
Checking for off64_t... No.
Checking for fseeko... Yes.
Checking for strerror... Yes.
Checking for unistd.h... Yes.
Checking for stdarg.h... Yes.
Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf().
Checking for vsnprintf() in stdio.h... Yes.
Checking for return value of vsnprintf()... Yes.
Checking for attribute(visibility) support... Yes.
~/GitClone/zlib-1.2.11 > make at 15:43:13
gcc -O3 -DHAVE_HIDDEN -I. -c -o example.o test/example.c
gcc -O3 -DHAVE_HIDDEN -c -o adler32.o adler32.c
gcc -O3 -DHAVE_HIDDEN -c -o crc32.o crc32.c
gcc -O3 -DHAVE_HIDDEN -c -o deflate.o deflate.c
gcc -O3 -DHAVE_HIDDEN -c -o infback.o infback.c
gcc -O3 -DHAVE_HIDDEN -c -o inffast.o inffast.c
gcc -O3 -DHAVE_HIDDEN -c -o inflate.o inflate.c
gcc -O3 -DHAVE_HIDDEN -c -o inftrees.o inftrees.c
gcc -O3 -DHAVE_HIDDEN -c -o trees.o trees.c
gcc -O3 -DHAVE_HIDDEN -c -o zutil.o zutil.c
gcc -O3 -DHAVE_HIDDEN -c -o compress.o compress.c
gcc -O3 -DHAVE_HIDDEN -c -o uncompr.o uncompr.c
gcc -O3 -DHAVE_HIDDEN -c -o gzclose.o gzclose.c
gcc -O3 -DHAVE_HIDDEN -c -o gzlib.o gzlib.c
gcc -O3 -DHAVE_HIDDEN -c -o gzread.o gzread.c
gcc -O3 -DHAVE_HIDDEN -c -o gzwrite.o gzwrite.c
libtool -o libz.a adler32.o crc32.o deflate.o infback.o inffast.o inflate.o inftrees.o trees.o zutil.o compress.o uncompr.o gzclose.o gzlib.o gzread.o gzwrite.o
gcc -O3 -DHAVE_HIDDEN -o example example.o -L. libz.a
ld: warning: ignoring file libz.a, building for macOS-arm64 but attempting to link with file built for macOS-arm64
Undefined symbols for architecture arm64:
"_compress", referenced from:
_test_compress in example.o
(maybe you meant: _test_compress)
"_deflate", referenced from:
_test_deflate in example.o
_test_large_deflate in example.o
_test_flush in example.o
_test_dict_deflate in example.o
(maybe you meant: _test_large_deflate, _test_deflate , _test_dict_deflate )
"_deflateEnd", referenced from:
_test_deflate in example.o
_test_large_deflate in example.o
_test_flush in example.o
_test_dict_deflate in example.o
"_deflateInit_", referenced from:
_test_deflate in example.o
_test_large_deflate in example.o
_test_flush in example.o
_test_dict_deflate in example.o
"_deflateParams", referenced from:
_test_large_deflate in example.o
"_deflateSetDictionary", referenced from:
_test_dict_deflate in example.o
"_gzclose", referenced from:
_test_gzio in example.o
"_gzerror", referenced from:
_test_gzio in example.o
"_gzgetc", referenced from:
_test_gzio in example.o
"_gzgets", referenced from:
_test_gzio in example.o
"_gzopen", referenced from:
_test_gzio in example.o
"_gzprintf", referenced from:
_test_gzio in example.o
"_gzputc", referenced from:
_test_gzio in example.o
"_gzputs", referenced from:
_test_gzio in example.o
"_gzread", referenced from:
_test_gzio in example.o
"_gzseek", referenced from:
_test_gzio in example.o
"_gztell", referenced from:
_test_gzio in example.o
"_gzungetc", referenced from:
_test_gzio in example.o
"_inflate", referenced from:
_test_inflate in example.o
_test_large_inflate in example.o
_test_sync in example.o
_test_dict_inflate in example.o
(maybe you meant: _test_large_inflate, _test_inflate , _test_dict_inflate )
"_inflateEnd", referenced from:
_test_inflate in example.o
_test_large_inflate in example.o
_test_sync in example.o
_test_dict_inflate in example.o
"_inflateInit_", referenced from:
_test_inflate in example.o
_test_large_inflate in example.o
_test_sync in example.o
_test_dict_inflate in example.o
"_inflateSetDictionary", referenced from:
_test_dict_inflate in example.o
"_inflateSync", referenced from:
_test_sync in example.o
"_uncompress", referenced from:
_test_compress in example.o
"_zlibCompileFlags", referenced from:
_main in example.o
"_zlibVersion", referenced from:
_main in example.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [example] Error 1
The clang version and environment variable is like:
~ > clang --version at 16:22:31
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: arm64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
~ > clang++ --version at 16:22:34
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: arm64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
~ > echo $PATH at 16:22:37
/usr/local/include:/opt/homebrew/Cellar/binutils/2.38_1/bin:/Users/hanxiaohao/.npm-global/bin:/Library/Java/JavaVirtualMachines/jdk-18.0.2.jdk/Contents/Home/bin:/opt/homebrew/Cellar/binutils/2.38_1/bin:/Users/hanxiaohao/.npm-global/bin:/Library/Java/JavaVirtualMachines/jdk-18.0.2.jdk/Contents/Home/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin:/Users/hanxiaohao/Library/Application Support/JetBrains/Toolbox/scripts:/opt/homebrew/Cellar/maven/3.6.3/bin:/opt/homebrew/Cellar/maven/3.6.3/bin

Not reproducible.
Tested on M1 Max macOS 12.5.1 with XCode 13.4.1 and Homebrew in the /opt/homebrew directory.
I noticed you have /usr/local/include and /usr/local/bin in your path. Those should be non-existent on M1 macOS. They were for Homebrew Intel.
% ls -l /usr/local/include /usr/local/bin
ls: /usr/local/bin: No such file or directory
ls: /usr/local/include: No such file or directory
Here is the run log of my test:
% ./configure
Checking for gcc...
Checking for shared library support...
Building shared library libz.1.2.12.dylib with gcc.
Checking for size_t... Yes.
Checking for off64_t... No.
Checking for fseeko... Yes.
Checking for strerror... Yes.
Checking for unistd.h... Yes.
Checking for stdarg.h... Yes.
Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf().
Checking for vsnprintf() in stdio.h... Yes.
Checking for return value of vsnprintf()... Yes.
Checking for attribute(visibility) support... Yes.
% make
gcc -O3 -DHAVE_HIDDEN -I. -c -o example.o test/example.c
gcc -O3 -DHAVE_HIDDEN -c -o adler32.o adler32.c
gcc -O3 -DHAVE_HIDDEN -c -o crc32.o crc32.c
gcc -O3 -DHAVE_HIDDEN -c -o deflate.o deflate.c
gcc -O3 -DHAVE_HIDDEN -c -o infback.o infback.c
gcc -O3 -DHAVE_HIDDEN -c -o inffast.o inffast.c
gcc -O3 -DHAVE_HIDDEN -c -o inflate.o inflate.c
gcc -O3 -DHAVE_HIDDEN -c -o inftrees.o inftrees.c
gcc -O3 -DHAVE_HIDDEN -c -o trees.o trees.c
gcc -O3 -DHAVE_HIDDEN -c -o zutil.o zutil.c
gcc -O3 -DHAVE_HIDDEN -c -o compress.o compress.c
gcc -O3 -DHAVE_HIDDEN -c -o uncompr.o uncompr.c
gcc -O3 -DHAVE_HIDDEN -c -o gzclose.o gzclose.c
gcc -O3 -DHAVE_HIDDEN -c -o gzlib.o gzlib.c
gcc -O3 -DHAVE_HIDDEN -c -o gzread.o gzread.c
gcc -O3 -DHAVE_HIDDEN -c -o gzwrite.o gzwrite.c
libtool -o libz.a adler32.o crc32.o deflate.o infback.o inffast.o inflate.o inftrees.o trees.o zutil.o compress.o uncompr.o gzclose.o gzlib.o gzread.o gzwrite.o
gcc -O3 -DHAVE_HIDDEN -o example example.o -L. libz.a
gcc -O3 -DHAVE_HIDDEN -I. -c -o minigzip.o test/minigzip.c
gcc -O3 -DHAVE_HIDDEN -o minigzip minigzip.o -L. libz.a
gcc -O3 -fPIC -DHAVE_HIDDEN -DPIC -c -o objs/adler32.o adler32.c
gcc -O3 -fPIC -DHAVE_HIDDEN -DPIC -c -o objs/crc32.o crc32.c
gcc -O3 -fPIC -DHAVE_HIDDEN -DPIC -c -o objs/deflate.o deflate.c
gcc -O3 -fPIC -DHAVE_HIDDEN -DPIC -c -o objs/infback.o infback.c
gcc -O3 -fPIC -DHAVE_HIDDEN -DPIC -c -o objs/inffast.o inffast.c
gcc -O3 -fPIC -DHAVE_HIDDEN -DPIC -c -o objs/inflate.o inflate.c
gcc -O3 -fPIC -DHAVE_HIDDEN -DPIC -c -o objs/inftrees.o inftrees.c
gcc -O3 -fPIC -DHAVE_HIDDEN -DPIC -c -o objs/trees.o trees.c
gcc -O3 -fPIC -DHAVE_HIDDEN -DPIC -c -o objs/zutil.o zutil.c
gcc -O3 -fPIC -DHAVE_HIDDEN -DPIC -c -o objs/compress.o compress.c
gcc -O3 -fPIC -DHAVE_HIDDEN -DPIC -c -o objs/uncompr.o uncompr.c
gcc -O3 -fPIC -DHAVE_HIDDEN -DPIC -c -o objs/gzclose.o gzclose.c
gcc -O3 -fPIC -DHAVE_HIDDEN -DPIC -c -o objs/gzlib.o gzlib.c
gcc -O3 -fPIC -DHAVE_HIDDEN -DPIC -c -o objs/gzread.o gzread.c
gcc -O3 -fPIC -DHAVE_HIDDEN -DPIC -c -o objs/gzwrite.o gzwrite.c
gcc -dynamiclib -install_name /usr/local/lib/libz.1.dylib -compatibility_version 1 -current_version 1.2.12 -O3 -fPIC -DHAVE_HIDDEN -o libz.1.2.12.dylib adler32.lo crc32.lo deflate.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo zutil.lo compress.lo uncompr.lo gzclose.lo gzlib.lo gzread.lo gzwrite.lo -lc
rm -f libz.dylib libz.1.dylib
ln -s libz.1.2.12.dylib libz.dylib
ln -s libz.1.2.12.dylib libz.1.dylib
gcc -O3 -DHAVE_HIDDEN -o examplesh example.o -L. libz.1.2.12.dylib
gcc -O3 -DHAVE_HIDDEN -o minigzipsh minigzip.o -L. libz.1.2.12.dylib
% gcc --version
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: arm64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
% clang --version
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: arm64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
% clang++ --version
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: arm64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
% uname -a
Darwin Superbook.local 21.6.0 Darwin Kernel Version 21.6.0: Wed Aug 10 14:28:23 PDT 2022; root:xnu-8020.141.5~2/RELEASE_ARM64_T6000 arm64

Related

Unable to compile C++ program with Clang-14

I am currently trying to compile a small program I have been working on with Clang and am getting the following error on compilation using scons as the build system:
/usr/bin/clang++ -o src/PluGen/main.o -c -std=c++17 -fPIC -I. -O2 -fno-strict-aliasing -fpermissive -fopenmp --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -fpermissive -fPIC -I. -O2 -flto -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -DHAVE_PYTHON -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DLARGE_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_PERL -DREENTRANT -DHAVE_R -I/usr/include -I/usr/local/include -Isrc -I/usr/include/python3.10 -I/usr/lib/perl5/5.36/core_perl/CORE -I/usr/include/R -I/usr/lib/R/library/Rcpp/include -I/usr/lib/R/library/RInside/include -I/usr/lib/R/site-library/RInside/include -I/usr/lib/R/site-library/Rcpp/include -I/usr/local/lib/R/library/Rcpp/include -I/usr/local/lib/R/library/RInside/include -I/usr/local/lib/R/site-library/RInside/include -I/usr/local/lib/R/site-library/Rcpp/include -I/usr/local/lib/R/site-library/RInside/lib src/PluGen/main.cxx
...
/usr/bin/clang++ -o PluGen/plugen -rdynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.36/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now src/PluGen/main.o src/PluGen/PluginGenerator.o -L/lib -L/usr/lib -L/usr/local/lib -L/usr/lib/perl5/5.36/core_perl/CORE -L/usr/lib/R/lib -L/usr/lib/R/library/RInside/lib -L/usr/lib/R/site-library/RInside/lib -L/usr/local/lib/R/library/RInside/lib -L/usr/local/lib/R/site-library/RInside/lib -Llib -lc -lc++ -lstdc++fs
src/PluGen/main.o: file not recognized: file format not recognized
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
main.o is being generated as a IR bitcode
file src/PluGen/main.o
src/PluGen/main.o: LLVM IR bitcode
Running the linker outside of the scons builder yields the following message:
clang version 14.0.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.0
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.0
Candidate multilib: .;#m64
Candidate multilib: 32;#m32
Selected multilib: .;#m64
"/usr/bin/ld" -pie -export-dynamic --eh-frame-hdr -m elf_x86_64 -export-dynamic -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o PluGen/plugen /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib64/Scrt1.o /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib64/crti.o /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.0/crtbeginS.o -L/lib -L/usr/lib -L/usr/local/lib -L/usr/lib/perl5/5.36/core_perl/CORE -L/usr/lib/R/lib -L/usr/lib/R/library/RInside/lib -L/usr/lib/R/site-library/RInside/lib -L/usr/local/lib/R/library/RInside/lib -L/usr/local/lib/R/site-library/RInside/lib -Llib -L/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.0 -L/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/bin/../lib -L/lib -L/usr/lib -E -rpath /usr/lib/perl5/5.36/core_perl/CORE -O1 --sort-common --as-needed -z relro -z now src/PluGen/main.o src/PluGen/PluginGenerator.o -lc -lc++ -lstdc++fs -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.0/crtendS.o /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib64/crtn.o
src/PluGen/main.o: file not recognized: file format not recognized
The program does compile correctly using GCC. Just not with Clang.
What is going on?
You are using -flto when compiling, but not when linking. clang can't do that. -c -flto compiles to LLVM IR bitcodes which the linker cannot use directly. You should either drop -flto everywhere, or use it everywhere.
$ clang++ -flto -c hello.cpp
$ file hello.o
hello.o: LLVM IR bitcode
$ clang++ -o hello hello.o && echo Ok
hello.o: file not recognized: file format not recognized
clang: error: linker command failed with exit code 1 (use -v to see invocation)
$ clang++ -o hello hello.o -flto && echo Ok
Ok
gcc works differently. It compiles to "fat objects" with both machine code and internal compiler representation baked in. Linker can use these, and apply the LTO plugin automatically.
$ g++ -c hello.cpp -flto
$ file hello.o
hello.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
$ g++ -o hello hello.o && echo Ok
Ok

Linker fails with NBIS library

I am trying to use the NBIS library on OS X, but I am getting a problem:
Undefined symbols for architecture x86_64:
"distance(int, int, int, int)", referenced from:
_main in test-2db11c.o
ld: symbol(s) not found for architecture x86_64
I tried using the .a archive, as well as the .o files in there - no luck - same problem.
The source code I am trying to compile (test.cpp):
#include <iostream>
#include <lfs.h>
using namespace std;
int main() {
cout << distance(1, 2, 3, 4) << endl;
}
Here are the execution lines that I tried (unsuccessfully):
$> g++ -std=c++11 -ggdb -g -Wall test.cpp -o test.bin -lm -lc++
$> g++ -std=c++11 -ggdb -g -Wall test.cpp -o test.bin -lm -lc++ -L/NBIS/Main/lib -lmindtct
$> g++ -std=c++11 -ggdb -g -Wall test.cpp -o test.bin -lm -lc++ -L/NBIS/Main/lib -l:libmindtct.a
$> g++ -std=c++11 -ggdb -g -Wall test.cpp /NBIS/Main/lib/libmindtct.a -o test.bin -lm -lc++
$> g++ -std=c++11 -ggdb -g -Wall test.cpp /NBIS/Main/lib/util.o -o test.bin -lm -lc++
Just to confirm that the libraries actually have the method declared, I checked what is inside the libmindtct.a archive:
$> ar t libmindtct.a
__.SYMDEF SORTED
<MANY FILES .o>
util.o
<SOME MORE .o FILES>
$> ar -x libmindtct.a util.o
$> nm util.o
U ___stderrp
00000000000008d0 T _angle2line
U _atan2
0000000000000a10 T _closest_dir_dist
0000000000000600 T _distance
00000000000008a0 T _find_incr_position_dbl
U _fmod
U _free
U _fwrite
0000000000000650 T _in_int_list
0000000000000920 T _line2direction
U _malloc
0000000000000000 T _maxv
0000000000000360 T _minmaxs
00000000000001b0 T _minv
0000000000000690 T _remove_from_int_list
0000000000000630 T _squared_distance
To compile the library I use the following:
$> cd ~/Downloads/NBIS/
$> ./setup.sh /NBIS/Main --64
$> make config && make it && make install LIBNBIS=no && make catalog
lfs.h from NBIS is C only. You need to enable C linkage for lfs.h:
extern "C" {
#include <lfs.h>
}
Additionally, you should not need to manually link libc++ or libm using g++.

Specify alternate compiler and linker to make

I have both a default C/C++ tool set (gcc 4.8) and have recently built and installed 5.2 in its own directory. I want to build some C++ programs using a makefile that uses CC and CXX explicity to compile but uses the implicit built-in rule to link the .o files to build the executable.
When I run make on the makefile, I use the command
make all CC=/usr/gcc-5.2.0/bin/gcc-5.2.0 CXX=/usr/gcc-5.2.0/bin/g++-5.2.0
The compile steps all use the 5.2 compilers but when the executable is build, the default g++ is used to link everything. Now, this happens to work and the results run but it isn't what I want. I tried adding
LD=/usr/gcc-5.2.0/bin/g++-5.2.0
to the make command line but LD is ignored. Without changing the makefile, how can I get the link step to use the 5.2 compiler?
Here is the make file:
CPPFLAGS = -Wall
LDFLAGS = -lstdc++
CXX = g++
CC = g++
all: TestSHA3 HashSHA3 HashZeroBytes LongTest sha3sum
debug: override CPPFLAGS += -ggdb
debug: all
SHA3-o3:
$(CXX) $(CPPFLAGS) -O3 -c -o SHA3.o SHA3.cpp
o3: SHA3-o3 all
TestSHA3: TestSHA3.o SHA3.o
HashSHA3: HashSHA3.o SHA3.o
HashZeroBytes: HashZeroBytes.o SHA3.o
LongTest: LongTest.o SHA3.o
sha3sum: sha3sum.o SHA3.o
.PHONY: clean realclean rc debug all o3 SHA3-o3
clean:
rm SHA3.o TestSHA3.o HashSHA3.o HashZeroBytes.o LongTest.o sha3sum.o
rc: realclean
realclean: clean
rm TestSHA3 HashSHA3 HashZeroBytes LongTest sha3sum
Here is the command:
make all CXX=g++-5.2.0 LD=g++-5.2.0
And here are the results of the make:
g++-5.2.0 -Wall -c -o TestSHA3.o TestSHA3.cpp
g++-5.2.0 -Wall -c -o SHA3.o SHA3.cpp
g++ -lstdc++ TestSHA3.o SHA3.o -o TestSHA3
g++-5.2.0 -Wall -c -o HashSHA3.o HashSHA3.cpp
g++ -lstdc++ HashSHA3.o SHA3.o -o HashSHA3
g++-5.2.0 -Wall -c -o HashZeroBytes.o HashZeroBytes.cpp
g++ -lstdc++ HashZeroBytes.o SHA3.o -o HashZeroBytes
g++-5.2.0 -Wall -c -o LongTest.o LongTest.cpp
g++ -lstdc++ LongTest.o SHA3.o -o LongTest
g++-5.2.0 -Wall -c -o sha3sum.o sha3sum.cpp
g++ -lstdc++ sha3sum.o SHA3.o -o sha3sum
Use:
make all CXX=g++-5.2.0 CC=g++-5.2.0
The implicit rule for linking uses CC (make manual):
n is made automatically from n.o by running the linker (usually called
ld) via the C compiler. The precise recipe used is ‘$(CC) $(LDFLAGS)
n.o $(LOADLIBES) $(LDLIBS)’.
With your Makefile and dummy source files:
$ make all CXX=`which g++`
/usr/bin/g++ -Wall -c -o TestSHA3.o TestSHA3.cpp
/usr/bin/g++ -Wall -c -o SHA3.o SHA3.cpp
g++ -lstdc++ TestSHA3.o SHA3.o -o TestSHA3
/usr/bin/g++ -Wall -c -o HashSHA3.o HashSHA3.cpp
g++ -lstdc++ HashSHA3.o SHA3.o -o HashSHA3
/usr/bin/g++ -Wall -c -o HashZeroBytes.o HashZeroBytes.cpp
g++ -lstdc++ HashZeroBytes.o SHA3.o -o HashZeroBytes
/usr/bin/g++ -Wall -c -o LongTest.o LongTest.cpp
g++ -lstdc++ LongTest.o SHA3.o -o LongTest
/usr/bin/g++ -Wall -c -o sha3sum.o sha3sum.cpp
g++ -lstdc++ sha3sum.o SHA3.o -o sha3sum
$ make all CC=`which g++`
g++ -Wall -c -o TestSHA3.o TestSHA3.cpp
g++ -Wall -c -o SHA3.o SHA3.cpp
/usr/bin/g++ -lstdc++ TestSHA3.o SHA3.o -o TestSHA3
g++ -Wall -c -o HashSHA3.o HashSHA3.cpp
/usr/bin/g++ -lstdc++ HashSHA3.o SHA3.o -o HashSHA3
g++ -Wall -c -o HashZeroBytes.o HashZeroBytes.cpp
/usr/bin/g++ -lstdc++ HashZeroBytes.o SHA3.o -o HashZeroBytes
g++ -Wall -c -o LongTest.o LongTest.cpp
/usr/bin/g++ -lstdc++ LongTest.o SHA3.o -o LongTest
g++ -Wall -c -o sha3sum.o sha3sum.cpp
/usr/bin/g++ -lstdc++ sha3sum.o SHA3.o -o sha3sum
$ make all CC=`which g++` CXX=`which g++`
/usr/bin/g++ -Wall -c -o TestSHA3.o TestSHA3.cpp
/usr/bin/g++ -Wall -c -o SHA3.o SHA3.cpp
/usr/bin/g++ -lstdc++ TestSHA3.o SHA3.o -o TestSHA3
/usr/bin/g++ -Wall -c -o HashSHA3.o HashSHA3.cpp
/usr/bin/g++ -lstdc++ HashSHA3.o SHA3.o -o HashSHA3
/usr/bin/g++ -Wall -c -o HashZeroBytes.o HashZeroBytes.cpp
/usr/bin/g++ -lstdc++ HashZeroBytes.o SHA3.o -o HashZeroBytes
/usr/bin/g++ -Wall -c -o LongTest.o LongTest.cpp
/usr/bin/g++ -lstdc++ LongTest.o SHA3.o -o LongTest
/usr/bin/g++ -Wall -c -o sha3sum.o sha3sum.cpp
/usr/bin/g++ -lstdc++ sha3sum.o SHA3.o -o sha3sum

cygwin compiled tree successfully but no output

Trying to compile tree from here (i uncommented appropriate section for cygwin in make script):
http://mama.indstate.edu/users/ice/tree/
$ make
gcc -O2 -Wall -fomit-frame-pointer -DCYGWIN -c -o tree.o tree.c
gcc -O2 -Wall -fomit-frame-pointer -DCYGWIN -c -o unix.o unix.c
gcc -O2 -Wall -fomit-frame-pointer -DCYGWIN -c -o html.o html.c
gcc -O2 -Wall -fomit-frame-pointer -DCYGWIN -c -o xml.o xml.c
gcc -O2 -Wall -fomit-frame-pointer -DCYGWIN -c -o hash.o hash.c
gcc -O2 -Wall -fomit-frame-pointer -DCYGWIN -c -o color.o color.c
gcc -O2 -Wall -fomit-frame-pointer -DCYGWIN -c -o strverscmp.o strverscmp.c
gcc -s -o tree.exe tree.o unix.o html.o xml.o hash.o color.o strverscmp.o
$ make install
install -d /usr/bin
install -d /usr/man/man1
if [ -e tree.exe ]; then \
install -s tree.exe /usr/bin/tree.exe; \
fi
install doc/tree.1 /usr/man/man1/tree.1
When i try to run however crickets
No output, no error, nothing. I'm using this compiler (running on 64bit cygwin):
/usr/bin/gcc -> i686-pc-cygwin-gcc.exe
What am i doing wrong, how can i resolve?
EDIT:
More on crickets:
i checked return code (echo $?) and it's 127
However, i also did
$ ls /usr/bin | grep tree
tree.exe

OS X clang -pthread

What are the compiler/linker requirements for using pthread library with clang in OS X.
With GCC i know that using -pthread set the appropriate compiler/linker options, but i unsure about OS X with clang.
air:~ jose$ clang++ -c test.cpp -pthread
air:~ jose$ clang++ -o test -pthread test.o
clang: warning: argument unused during compilation: '-pthread'
air:~ jose$ g++ -c test.cpp -pthread
air:~ jose$ g++ -o test -pthread test.o
clang requires -pthread when compiling but not when linking. This is annoying, but it is observed behavior:
$ clang -c x.cpp
$ clang -pthread -c x.cpp
$ clang -o x x.o
$ clang -pthread -o x x.o
clang: warning: argument unused during compilation: '-pthread'
$
$ clang --version
Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
$