Contrafold-se install error: error: unknown FP unit 'sse' - g++

I am trying to install contrafold-se (link to github here: https://github.com/csfoo/contrafold-se), and I am getting this error when I run 'make' in src:
g++ -O3 -mfpmath=sse -msse -msse2 -msse3 -DEVIDENCE_SR -DEVIDENCE_PARS -DNDEBUG -W -pipe -Wundef -Winline --param large-function-growth=100000 -Wall -c Contrafold.cpp
clang: warning: argument unused during compilation: '-msse' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-msse2' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-msse3' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '--param large-function-growth=100000' [-Wunused-command-line-argument]
error: unknown FP unit 'sse'
error message
I see that contrafold-se installation has been tested on certain versions of g++ but I am using a macbook, and when I run g++ --version, I get:
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: arm64-apple-darwin21.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
Thanks for your help!

Related

Categories in static lib not regocnized at runtime

I am building an executable ("tool") on Linux. Using include $(GNUSTEP_MAKEFILES)/tool.make.
It's linked to a static lib that has also be build with GNUstep. The lib
contains Categories.
The executable builds fine but has errors at runtime not recognizing
methods defined in the static lib's Category:
Uncaught exception NSInvalidArgumentException, reason:
ClassNameOfClassTheCategoryExtends(instance) does not recognize
nameOfMethodInCategory
I am trying to fix that by passing -ObjC to the linker flags (also
tried -all_load) in the executable's GNUmakefile:
ADDITIONAL_LDFLAGS = -ObjC -all_load
But that seems to be ignored by clang. Here is the relevant output of
make install messages=yes debug=yes
clang: warning: argument unused during compilation: '-ObjC'
[-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-all_load'
[-Wunused-command-line-argument]
It looks like ADDITIONAL_LDFLAGS are used compiling, not linking.
Using this leads to the same result:
LDFLAGS := $(LDFLAGS) -ObjC
The excecutables GNUmakefileincludes the following:
include $(GNUSTEP_MAKEFILES)/common.make
# My make
include $(GNUSTEP_MAKEFILES)/tool.make
The resulting command line output is:
$ make install messages=yes debug=yes
This is gnustep-make 2.9.0. Type 'gmake print-gnustep-make-help' for help.
Running in gnustep-make version 2 strict mode.
Making all for tool NameOfExcecutable...
clang -ObjC -fuse-ld=/usr/bin/ld.gold -pthread -fexceptions -rdynamic -fobjc-runtime=gnustep-2.0 -fblocks -o obj/NameOfExcecutable \
./obj/NameOfExcecutable.obj/main.m.o ./obj/NameOfExcecutable.obj/MyClass.m.o ./obj/NameOfExcecutable.obj/StreamRunLoop.m.o ./obj/NameOfExcecutable.obj/Connector.m.o ./obj/NameOfExcecutable.obj/HTTPClient.m.o \
-L/home/user/GNUstep/Library/Libraries -L/usr/GNUstep/Local/Library/Libraries -L/usr/GNUstep/System/Library/Libraries -lgnustep-base -ldispatch -l/path/to/libOwnLib1.a -l/path/to/libOwnLib2.a -l/path/to/libOwnHavingTheCategories.a -l/path/to/libOwnLib4.a -l/path/to/libOwnLib5.a -luuid -lz -lpthread -ldl -lpthread -lobjc -lm
clang: warning: argument unused during compilation: '-ObjC' [-Wunused-command-line-argument]
Question:
What am I doing wrong
or
How can I work around the issue?
After digging into the issue of the linker not knowing the -ObjC flag (which we are used to use in Xcode) it looks like:
only ld.ld64 is aware of this flag
ld.ld64 is a (too genericly named) "linker for macOS" (from LLDB.org)
thus is not available for Linux linkers
To workaround we first stopped using GNUstep makefiles to
disable all GNUstep magic understand what is going on and wrote our own makefiles.
The actual fix to force link/load all .o files was to explicitly pass --whole-archive to the linker:
-Wl,-whole-archive path/to/static/lib/containing/categories/libOwnLib1.a -Wl,-no-whole-archive

g++ error: Cannot specify -static with -fsanitize=address

I am trying to use address sanitizer with g++ and during the build it produces the following linker command, which produces the error g++: error: cannot specify -static with -fsanitize=address
I don't understand what this means, so any help is appreciated. The g++ version is g++ (GCC) 8.3.0 20190222 (Cray Inc.).
g++ -g -fsanitize=address CMakeFiles/pisa.dir/src/Alphabet.cpp.o {more .o files} -o pisa -L/global/homes/e/esaliya/sali/git/bitbucket/combinatorial-blas-2.0/CombBLAS/_install/lib -Wl,-rpath,/global/homes/e/esaliya/sali/git/bitbucket/combinatorial-blas-2.0/CombBLAS/_install/lib -lCombBLAS -lGraphGenlib -lUsortlib

CMake on Cygwin with clang not creating expected dll.a

I'm building a shared library and an application using that lib on Cygwin. With GCC CMake creates a .dll.a to use when linking. Switching to clang I get
[ 34%] Built target xxx_shared
make[2]: *** No rule to make target 'src/libxxx.dll.a', needed by 'xxx.exe'. Stop.
Is this a bug in the clang CMake extension?
I'm using cmake --version 3.3.2
Yes, it seems to be a bug in CMake. Running make VERBOSE=1 reveals that with GCC:
/usr/bin/c++.exe -g -shared -Wl,--enable-auto-import -o XXX -Wl,-Bstatic -lm -Wl,-Bdynamic -lstdc++ -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32
while with clang:
/usr/bin/clang++ -fPIC -g -shared -o XXX -Wl,-Bstatic -lm -Wl,-Bdynamic -lstdc++ -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32
So it seems that somehow clang++ does not get the -Wl,--enable-auto-import flag. Manually running the corrected clang++ command correctly creates the expected .dll.a allowing the rest of the build to proceed as expected.
Haven't figured out why this happens yet, though. At this point I can't decipher CMakes platform extensions, which seems to set this for GCC.
Update: I've reported this here.

nettle-3.0 and gmp-6.0.0 - undefined symbols "gmpz_limbs_write, gmpz_limbs_read..."

I am trying to compile nettle 3.0 with gmp 6.0.0 and I kept getting missing symbols:
Making all in tools
gcc -g -O2 -ggdb3 -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -L.. pkcs1-conv.o misc.o ../getopt.o ../getopt1.o -lhogweed -lnettle -lgmp -o pkcs1-conv
ld: warning: relocation error: R_386_32: file ../getopt.o: symbol optarg: external symbolic relocation against non-allocatable section .debug_info; cannot be processed at runtime: relocation ignored
Undefined first referenced
symbol in file
__gmpz_limbs_write ../libhogweed.so
__gmpz_limbs_finish ../libhogweed.so
__gmpz_limbs_modify ../libhogweed.so
__gmpn_zero ../libhogweed.so
__gmpz_roinit_n ../libhogweed.so
__gmpn_cnd_sub_n ../libhogweed.so
__gmpn_cnd_add_n ../libhogweed.so
__gmpz_limbs_read ../libhogweed.so
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `pkcs1-conv'
Current working directory /root/nettle-3.0/tools
I installed gmp 6.0.0 to /usr/local, then - in the nettle directory -, I ran ./configure --prefix=/usr/local, then make and got the error above.
It looks nettle is finding an older version first. Have you tried?
./configure --prefix=/usr/local --with-include-path=/usr/local/include --with-lib-path=/usr/local/lib
I found the options by using ./configure --help.

Building Chromium, WebRTC without LTO

I'm on Arch Linux x86_64, attempting to build the WebRTC libraries. I get compile errors when I do:
[ghilliard#diadem trunk]$ ninja -C out/Release peerconnection_server
ninja: Entering directory `out/Release'
[1/1] LINK peerconnection_server
FAILED: c++ -Wl,-z,now -Wl,-z,relro -Wl,--fatal-warnings -pthread -Wl,-z,noexecstack -fPIC -B/home/ghilliard/Code/webrtc-attempt2/trunk/third_party/binutils/Linux_x64/Release/bin -Wl,--disable-new-dtags -m64 -Wl,--icf=none -fuse-ld=gold -Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -o peerconnection_server -Wl,--start-group obj/talk/examples/peerconnection/server/peerconnection_server.data_socket.o obj/talk/examples/peerconnection/server/peerconnection_server.main.o obj/talk/examples/peerconnection/server/peerconnection_server.peer_channel.o obj/talk/examples/peerconnection/server/peerconnection_server.utils.o obj/talk/libjingle.a obj/net/third_party/nss/libcrssl.a obj/third_party/jsoncpp/libjsoncpp.a -Wl,--end-group -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -ldl -lcrypto -lrt -lXext -lX11 -lXcomposite -lXrender -lexpat
/home/ghilliard/Code/webrtc-attempt2/trunk/third_party/binutils/Linux_x64/Release/bin/ld.gold: -plugin: unknown option
/home/ghilliard/Code/webrtc-attempt2/trunk/third_party/binutils/Linux_x64/Release/bin/ld.gold: use the --help option for usage information
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
There appears to be a problem with link time optimization. However, I cannot figure out how to build WebRTC without LTO enabled. If I manually run the command that failed and append -fno-lto, it links fine. How can I add or change the compiler/linker flags within the gyp configuration so that it gets applied to everything?
ninja does not respect environment variables, but gyp does.
So after setting the LDFAGS environment variables, you have to run gyp_chromium to let the gyp generate correct ninja build file.
export LDFLAGS='-fno-lto'
build/gyp_chromium
ninja -C out/Release peerconnection_server
You might try to set compiler/linker flags in environment variables before build:
export CFLAGS="${CFLAGS} -fno-lto"
export CXXFLAGS="${CXXFLAGS} -fno-lto"
export LDFLAGS="${LDFLAGS} -fno-lto"
ninja -C out/Release