I am attempting to install Cosign on CentOS 6.3 64-bit to work with my employer's central login system.
Their documentation states that I need to set an LDFLAGS directive of:
LDFLAGS="-R/usr -L/usr"
Where /usr is the /PATH/TO/SSL/lib - openSSL is installed and this is the correct path.
However when I then try to ./configure the installation, GCC is throwing an error which I can't work out.
configure:2335: checking for suffix of executables
configure:2342: gcc -o conftest -pthread -R/usr -L/usr conftest.c >&5
gcc: unrecognized option '-R/usr'
I can't find -R as an option in the gcc docs, which has me confused. I'm using gcc version 4.4.6 20120305 (Red Hat 4.4.6-4).
I am not used to seeing options without a space before their argument, but in this case adding a space to make it '-R /usr' just throws the same error.
Earlier in the config.log, I also have this error:
configure:2182: gcc -V >&5
gcc: '-V' option must have argument
Can anyone shed any light?
LDFLAGS should not be fed to gcc "as is", strange as they are like in your output. Probably some bug in the build script.
Try
LDFLAGS="-Wl,-R/usr,-L/usr"
This should compensate the current error by wrapping the flags in the form that gcc expects.
Related
I'm trying to compile a program that I've been able to compile on several other Debian environments with no issues using the C11 <threads.h> library on a relatively fresh install of Debian Bullseye with "gcc (Debian 10.2.1-6) 10.2.1 20210110" installed
with the command
gcc -o <progname> -O3 -Wall -Wextra -std=c11 -lpthread <sourcefile>
and I'm getting a string of linker errors in the form of
undefined reference to 'mtx_unlock'
as well as mtx_lock mtx_init thrd_create etc.
But I'm not getting an error saying the threads.h file is absent. I tried removing the -lpthread argument from the compilation command but this changed nothing.
What is going wrong?
The correct command line parameter seems to be -pthread without the l.
I'm doing all this on a VLE and below is what I'm working with:
Running OS: Linux Centos 7
GCC:4.8.5 & 7.1.0
I'm trying to use GNU autotools (libtool, autoconf, automake) to build a project in 32-bit using gcc-7.1.0. Also, as a requirement, I must do this on Centos 7 and use gcc-7.1.0.
Apparently, the latest version of gcc that can be officially upgraded through yum is 4.8.5. However, I successfully installed gcc-7.1.0 from the official source and even included --enable-multiarch --with-list-multilib=m32,m64 --enable-multilib during configure.
The issue I'm running into is that the autotools seem to want to use the 64-bit libraries even though I'm including -m32 compiler switch in CXXFLAGS, CFLAGS, and LDFLAGS. The reason I think it's using 64-bit libraries at linking is that I get the error below:
libtool: link: g++ -m32 -fPIC -Wall -Wextra -Weffc++ -Werror -std=c++03 -O2 -o fldprog fldprog-icpprog.o ../../ ../seal3/fld/src/.libs/libbsp_fld.a -lpci /usr/local/lib/../lib64/libstdc++.so -lm -Wl,-rpath -Wl,/usr/local/lib /../lib64 -Wl,-rpath -Wl,/usr/local/lib/../lib64
/usr/local/lib/../lib64/libstdc++.so: error adding symbols: File in wrong format
And when I rename /usr/local/lib64 to lib64_something, the program will compile without any errors. However, I want to find a permanent solution.
I've searched the internet for answers but none of them seem to really work. I've tried including -L/usr/local/lib to AM_LDFLAGS, AM_CFLAGS in configure.ac
I'd appreciate any input. Thank you.
Edit:Revised
This is a follow-up to the question at Element-Wise Matrix Multiplication in Rcpp
I have been getting a number of different kinds of errors with RcppArmadillo since upgrading to Mavericks. I have Xcode 5.0.2 and Command Line Tools installed. Also, gfortran from Homebrew. But I keep encountering the error below --
> cppFunction("arma::mat schur(arma::mat& a, arma::mat& b)
{ return(a % b); }", depends="RcppArmadillo")
ld: library not found for -lgfortran
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [sourceCpp_18474.so] Error 1
clang++ -I/Library/Frameworks/R.framework/Resources/include -DNDEBUG -I/usr/local/include - I"/Library/Frameworks/R.framework/Versions/3.0/Resources/library/Rcpp/include" -I"/Library/Frameworks/R.framework/Versions/3.0/Resources/library/RcppArmadillo/include" -fPIC "-mtune=native -g -O2 -Wall -pedantic -Wconversion" -c fileaf992bfb8f84.cpp -o fileaf992bfb8f84.o clang++ -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/lib -L/usr/local/lib -o sourceCpp_18474.so fileaf992bfb8f84.o -L/Library/Frameworks/R.framework/Resources/lib -lRlapack -L/Library/Frameworks/R.framework/Resources/lib -lRblas -lgfortran /Library/Frameworks/R.framework/Versions/3.0/Resources/library/Rcpp/lib/libRcpp.a -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
Error in sourceCpp(code = code, env = env, rebuild = rebuild, showOutput = showOutput, :
Error 1 occurred building shared library.
WARNING: The tools required to build C++ code for R were not found.
Please install Command Line Tools for XCode (or equivalent).
# Contents of Makevars
$ cat ~/.R/Makevars
CC=clang
CXX=clang++
CXXFLAGS="-mtune=native -g -O2 -Wall -pedantic -Wconversion"
FLIBS=-lgfortran
Commenting FLIBS=-lgfortran does not help and results in even more error messages --
> cppFunction("arma::mat schur(arma::mat& a, arma::mat& b) { return(a % b); }", depends="RcppArmadillo")
ld: warning: directory not found for option '-L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/x86_64'
ld: warning: directory not found for option '-L/usr/local/lib/x86_64'
ld: warning: directory not found for option '-L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3'
ld: library not found for -lgfortran
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [sourceCpp_50381.so] Error 1
Thanks in advance.
Update
Following suggestions from response from Kevin and Dirk below, I re-installed Rcpp, RcppArmadillo and inline from source and updated FLIBS to point to the actual directory. This solved the issue.
# Update FLIBS in ~/.R/Makevars
FLIBS=-L/usr/local/Cellar/gfortran/4.8.2/gfortran
#Re-Install from source
install.packages(c("Rcpp","RcppArmadillo","inline"),type="source")
#Restart R
EDIT: If you're a Homebrew user, you now instead need to use brew install gcc (gfortran is no longer provided separate of gcc), and you can then follow the instructions here to get set up.
You have to symlink the libraries to /usr/local/lib manually:
ln -s /usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libgfortran.* /usr/local/lib/
I thought brew link gfortran would handle this, but apparently it only symlinks the gfortran program and not the actual libraries. So, unfortunately, you have to do it yourself.
(Replace 4.8.2 with whichever version of gfortran you're using from homebrew.)
Alternatively, if you want to keep from modifying /usr/local/lib, you can use
FLIBS=-L/usr/local/Cellar/gfortran/4.8.2/gfortran
in your ~/.R/Makevars file instead, so R knows where to find the gfortran libraries.
I can only suggest you study the numerous threads on the r-sig-mac list, the different answers here on SO as well as the posts on the rcpp-devel list.
As your error comes from the failed Fortran linking, maybe also review the standard page by Simon U. as well as the tools page it points too. AFAIK you should use the (older) gfortran 4.2.* from that page with R -- but then I am not an OS X user.
Edit in late 2016: We now have more detailed instructions in section 2.16 of the Rcpp FAQ.
I am on linux and I am compiling the following:
mpif90 -shared source.F90 object1.o object2.o -L/some/path -Qoption,link,-rpath=/some/path -I/some/path -lhdf5 -lhdf5_fortran -fPIC -fpp -DDECDEC_ -DMSMS_ -cxxlib-gcc -o libhdfwrapper.so
and I get
f95: unrecognized option '-Qoption,link,-rpath=/some/path'
f95: unrecognized option '-cxxlib-gcc'
f951: error: unrecognized command line option "-fpp"
can anybody tell me why fpp is not recognized?
-fpp is a flag used by some compilers, notably Solaris Studio. Also -rpath seems to point to Solaris Studio. It seems you are using gfortran or some other compiler, however. Other compilers use -cpp instead. The same holds for the other options.
Also, the part -Qoption,link,-rpath=/some/path is probably not in the right format.
You may want to consult http://www.oracle.com/technetwork/server-storage/solarisstudio/documentation/oss-translate-gfortran-180584.pdf and your compiler's manual.
On my machine (Windows running cygwin) it compiles correctly. Flex is version 2.5.35 and bison is version 2.3
On linux machine 1 it compiles correctly. Flex is version 2.5.4 and bison is version 1.875c.
On linux machine 2 it does not compile correctly. Flex is version 2.5.4 and bison is 2.3.
One would expect by looking at the flex/bison version numbers that if it compiled correctly on my machine, it would compile correctly on machine 2, but that's not the case.
On linux machine 2, when I run gcc -c y.tab.c I get the following warnings several times
warning: incompatible implicit declaration of built-in function 'printf'
And when I run the following
gcc -o cminus y.tab.o lex.yy.o -ly -lfl
I get the following error.
gcc -o cminus y.tab.o lex.yy.o -ly -lfl
/usr/bin/ld: cannot find -ly
collect2: ld returned 1 exit status
make: *** [cminus] Error 1
This error can be removed by taking out the -ly option in gcc so that the program compiles, but the compiled program does not function correctly as it does on my machine and the other linux machine.
What could be causing the problem?
/usr/bin/ld: cannot find -ly
is the message you get when the linker cannot find the library.
You need to locate liby.a or liby.so and then insert a -L<that path> in your gcc command line.
On my Cygwin install, it's located in /lib/liby.a so I would use something like:
gcc -o cminus y.tab.o lex.yy.o -L /lib -ly -lfl
The warning sounds like you have a missing '#include ' in some source file. The link error means that you don't have liby.a installed on your machine. liby is part of yacc and some versions of bison, but is rarely actually needed (it just defines default implementations of yyerror and a couple other things). The fact that it links without it means that you don't really need it.
You don't say in what way the progrma misbehaves when its not functioning correctly, so that's tough to diagnose