I am using the davidva/gcc49 copr, on Fedora 27.
When I try to compile after running source /usr/bin/gcc49 as the copr webpage describes, I get this error:
/usr/bin/ld: cannot find -lgcc_s
After learning about how the flag -l works for gcc, I learned it is looking for library gcc_s. I found it in /opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/lib64, which sounds like the right spot for it to be. Why is it not linking? Do I need to add a directory to a library path? If it's LDFLAGS, it's already there because of the file I sourced:
export LDFLAGS="-L/opt/gcc-$gver/$lib/gcc/$gcc_target_platform/$lib/"
What do I need to do to get gcc 4.9 on Fedora 27 to find its library file which is clearly in the LDFLAGS directory?
The problem is that the libgcc_s.so file is in the wrong directory! Just symlink to it in the 4.9.3 directory:
pushd /opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/4.9.3
sudo cp -p ../lib64/libgcc_s.so.1 .
sudo ln -s libgcc_s.so.1 libgcc_s.so
popd
I guess the /opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/lib64 directory was supposed to be included in any LDFLAGS parameter, and that might be a weakness of the build process I was using and not the gcc 4.9 package.
Putting this file and appropriately-named symlink in the 4.9.3 directory allows my build process to complete successfully.
Reference: https://bgstack15.wordpress.com/2018/02/01/gcc-4-9-for-fedora-27/
Related
I extracted Cmake zip file (downloaded from github) and tried to install it but an error occured.
I tried installing OpenSSL and tried to install Cmake but Error(same) is still comming
Terminal output is below :
CMake 3.16.20191118, Copyright 2000-2019 Kitware, Inc. and Contributors
Found GNU toolchain
C compiler on this system is: gcc
C++ compiler on this system is: g++
Makefile processor on this system is: make
g++ has setenv
g++ has unsetenv
g++ does not have environ in stdlib.h
g++ has stl wstring
g++ has <ext/stdio_filebuf.h>
---------------------------------------------
make: 'cmake' is up to date.
loading initial cache file /root/Cmake/Bootstrap.cmk/InitialCacheFlags.cmake
-- Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the system variable OPENSSL_ROOT_DIR (missing: OPENSSL_CRYPTO_LIBRARY OPENSSL_INCLUDE_DIR)
-- Configuring incomplete, errors occurred!
See also "/root/Cmake/CMakeFiles/CMakeOutput.log".
See also "/root/Cmake/CMakeFiles/CMakeError.log".
---------------------------------------------
Error when bootstrapping CMake:
Problem while running initial CMake
---------------------------------------------
I ran into the same problem today trying to compile cmake 3.16-rc4 under Ubuntu 18.04. While trying to fix that by setting appropriate paths and looking for them in the first place, I discovered this: How do I install the OpenSSL libraries on Ubuntu?
So the solution is to simply do:
sudo apt install libssl-dev
So cmake obviously needs the dev package of openssl. Kudos to Niki Yoshiuchi, who has given the desired answer in the linked question.
I compiled some codes in Matlab on a Linux system, and .mexa64 files has been generated, but in run time, I get the following error:
Invalid MEX-file '/*.mexa64': /matlab-8.5/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6: version `CXXABI_1.3.8' not found.
i tried setting -rpath in make file by two following commands in matlab make file:
LDFLAGS="\$LDFLAGS -rpath=/usr/local/GNU/glibc-2.22/lib/"
LDFLAGS="\$LDFLAGS -dynamic-linker=/usr/local/GNU/glibc-2.22/lib/ld-linux-x86-64.so.2"
But, it cannot solve the problem.
This worked for my case:
Goto your matlab installation:
cd /usr/local/MATLAB/R2015a/sys/os/glnxa64
and rename these two files:
sudo mv libstdc++.so.6 libstdc++.so.6.orig
sudo mv libgcc_s.so.1 libgcc_s.so.1.orig
I follow this post
to setup gtest 1.7 on eclipse cdt 8.2.1.but got this errors:
....test/AllTests.bc src/Test.bc -lgmock -lgtest -lpthread -lstdc++
/usr/bin/ld: cannot find -lgmock
/usr/bin/ld: cannot find -lgtest
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Info: Parallel threads used: 3
By the way,there is some change from gtest 1.5 to 1.7,I actually make link like this:
sudo ln -s lib/.libs/libgtest.a /usr/lib/libgtest.a
As you can see,libgtest is under gtest1.7/lib/.lib(the second hidden dir) not gtest1.7/lib.
so what did I do wrong?
You appear to have attempted to make symbolic links to libgtest.a
and libgmock.a by using the commands:
sudo ln -s lib/.libs/libgtest.a /usr/lib/libgtest.a
sudo ln -s lib/.libs/libgmock.a /usr/lib/libgmock.a
from the console in /your/path/to/gtest-1.7.0 and /your/path/to/gmock-1.7.0
respectively.
If you open /usr/lib in your file manager, find the links libgtest.a
and libgmock.a and exam their properties, I believe you will find that
these links are broken, and that is why the linker cannot find them
in your project. Your ln commands give relative paths to their targets,
but absolute paths are needed.
If so, delete the broken links and recreate them with the commands:
sudo ln -s /full/path/to/gtest-1.7.0/lib/.libs/libgtest.a /usr/lib/libgtest.a
sudo ln -s /full/path/to/mock-1.7.0/lib/.libs/libgmock.a /usr/lib/libgmock.a
E.g on my system /full/path/to/ = /home/imk/develop/
Then I think your build will work.
However, creating these symbolic links in /usr/lib slightly taints your
system installation. It would be better to create them in /usr/local/lib.
Or even simpler, you can just add these static libraries to the object files
for your project linkage:
In Eclipse, navigate your project -> Properties -> C/C++ build
-> Settings -> your compiler Linker -> Libraries and delete gmock.a, gtest.a
Immediately under Libraries you find Miscellaneous. There, in
Other objects, add:
/full/path/to/libgtest.a
/full/path/to/libgmock.a
All these suggestions have worked for me.
I need to install the Perl PDL library via CPAN as the non-root user.
CPAN for non-root works thanks to this SO question: How can I use CPAN as a non-root user?
Now, PDL depends on the FFTW library. Evidently, my sysadmin has the 32-bit version installed when I require the 64-bit for this machine.
I base this on the following error message during the CPAN install:
gcc -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic FFTW.o -o ../../blib/arch/auto/PDL/FFTW/FFTW.so \
-lm -L/lib -L/usr/lib -L/usr/local/lib -L/usr/local/lib64 -L/lib64 -L/usr/lib64 -ldfftw -ldrfftw \
/usr/bin/ld: skipping incompatible /usr/local/lib/libdfftw.a when searching for -ldfftw
/usr/bin/ld: skipping incompatible /usr/local/lib/libdfftw.a when searching for -ldfftw
/usr/bin/ld: cannot find -ldfftw
Now I have successfully installed fftw in $HOME/lib, indeed libdfftw.a.
The problem is I can't get this gcc compilation instance to use that locally installed copy.
I have tried the following:
Setting LD_LIBRARY_PATH in .bash_profile, and yes, exporting it -- No dice.
Following How can I set library and include paths for Makefile.PL for a single installation?, I set o conf makepl_arg in cpan to: LIBS=-L/homedir/lib INC=-I/homedir/include -- Still no dice
I did the same as step 2 but for o conf mbuild_arg --- Again, no dice.
None of these attempts had any effect on the gcc line above; there were no additional paths specified with -L flags.
What else can I try in cpan to get this compilation command to reference my copy of fftw?
Update 1
I should add that before I make any changes, makepl_arg is:
makepl_arg [INSTALLDIRS=site]
Hence, I am setting makepl_arg to:
makepl_arg [INSTALLDIRS=site LIBS=-L/homedir/lib INC=-I/homedir/include]
I am setting these configurations without doing o conf commit to permit experimentation. Should I be commiting these changes?
Update 2
I see that those -L flags in the above gcc line are coming from the makefile, which itself seems to be made by MakeMaker which I presume is reading the file 'Makefile.PL'
The solution was to examine the .cpan/build/PDL-*/ directory.
In it the INSTALL file indicates that the perldl.conf file can be modified to indicate paths to FFTW libs and FFTW include directories.
The process is as follows and can be done after a failed attempt at installing PDL:
Copy the .cpan/build/PDL-*/perldl.conf file to ~/.perldl.conf - notice the . being added before the filename - PDL will look for this file when installing, even under CPAN
Modify FFTW__LIBS and FFTW_INC in ~/.perldl.conf to point to the appropriate locations.
Attempt install of PDL again with CPAN.
A bit confusing that PDL does not adhere to the makepl_arg cpan configuration.
I'm trying to connect to Oracle 10.2.0.4 on a remote system from my intel mac running OSX 10.6 snow leopard. I've tried using perl CPAN to install DBD::Oracle (DBI worked ok) but get compilation errors. Could someone provide an easy to follow guide?
Getting a mac install of perl to play nicely with oracle is a bit of a pain - once it's running it is fantastic, getting it running is a little frustrating..
The below has worked for me on a few different intel macs, there could well be superfluous steps in there and it is likely not going to be the same for other platforms.
This will require use of shell, the root user and a bit of CPANing - nothing too onerous
First off create a directory for the oracle pap - libraries, instant client etc
sudo mkdir /usr/oracle_instantClient64
Download and extract all 64 bit instant client packages from oracle to the above directory
Create a symlink within that directory for one of the files in there
sudo cd /usr/oracle_instantClient64
sudo ln -s /usr/oracle_instantClient64/libclntsh.dylib.10.1 libclntsh.dylib
The following dir is hardcoded into the oracle instant client - god knows why - so need to create and symlink it
sudo mkdir -p /b/227/rdbms/
sudo cd /b/227/rdbms/
sudo ln -s /usr/oracle_instantClient64/ lib
Need to add a couple of environment variables, so edit /etc/profile and add them so they exist for all users:
export ORACLE_HOME=/usr/oracle_instantClient64
export DYLD_LIBRARY_PATH=/usr/oracle_instantClient64
Now try and install DBD::Oracle through CPAN - this will fail, but it means any dependencies will be downloaded and it retrieves the module for us
sudo perl -MCPAN -e shell
install DBD::Oracle
When this fails exit CPAN and head to your .cpan/build dir - if you used automatic config of CPAN it'll be
cd ~/.cpan/build
if you didn't auto configure you can find your build directory with the following command in CPAN
o conf build_dir
Once in the build dir look for the DBD::Oracle dir which has just been created (it'll be called something like DBD-Oracle-1.28-?) and cd into it.
Now we need to switch to the root user. Root isn't enabled as default in osx - for details on enabling see this post on the apple website
Once logged in as root we need to set the above environment variables for root:
export ORACLE_HOME=/usr/oracle_instantClient64
export DYLD_LIBRARY_PATH=/usr/oracle_instantClient64
Now while still logged in as root we need to run the makefile for the module, then make, then install
perl Makefile.pl
make
make install
Assuming that all worked without error log out of root: we're DBD'd up! If this didn't work it's time to bust out google on whatever errors you're seeing
Now just to install the DBI module
sudo perl -MCPAN -e shell
install DBI
Now you're all set - enjoy your perly oracley new life
Additional info from user852637:
Correction to this step
perl Makefile.pl
make
install
The last step should be make install
During make, you may encounter an error that looks like :
lipo: can't open input file: /var/tmp//ccIevTzM.out (No such file or directory)
To correct this you must edit the file "Makefile" created after the "perl Makefile.pl" step and remove all occurrences of the following text :
-arch ppc
This will eliminate the error.
The same error described in (2.) will occur during the installation of the DBI module. You must edit the Makefile created after the perl Makefile.pl step and remove all occurrences of the following text :
-arch ppc
It looks with the XCode4 change (removal of PPC arch support) the Perl installation was not updated in any of the 10.6.X updates to also remove PPC binaries (probably because Rosetta is still present).
Because of this, the configuration files retain "-arch ppc" causing all CPAN module compiles with C libraries to fail because MakeMaker's output Makefile contains -arch ppc.
To fix this one can edit the following file:
/System/Library/Perl/5.10.0/darwin-thread-multi-2level/Config_heavy.pl
at line 1219 you'll see:
$archflags = exists($ENV{ARCHFLAGS}) ? $ENV{ARCHFLAGS} : '-arch x86_64 -arch i386 -arch ppc';
change that to:
$archflags = exists($ENV{ARCHFLAGS}) ? $ENV{ARCHFLAGS} : '-arch x86_64 -arch i386';
Once you do this the generated Makefile will be correct.
These are a great set of instructions. I have a few other comments about potential "gotchas".
Correction to this step
perl Makefile.pl
make
install
The last step should be make install
During make, you may encounter an error that looks like :
lipo: can't open input file: /var/tmp//ccIevTzM.out (No such file or directory)
To correct this you must edit the file "Makefile" created after the "perl Makefile.pl" step and remove all occurrences of the following text :
-arch ppc
This will eliminate the error.
The same error described in (2.) will occur during the installation of the DBI module. You must edit the Makefile created after the perl Makefile.pl step and remove all occurrences of the following text :
-arch ppc
It seems as though the "Perl MakeFile.pl" command is not finding the version of Perl correctly and I get this error message:
bash-3.2# perl Makefile.PL
Multiple copies of Driver.xst found in: /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBI/ /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level/auto/DBI/ at Makefile.PL line 37
Using DBI 1.616 (for perl 5.010000 on darwin-thread-multi-2level) installed in /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBI/
Configuring DBD::Oracle for perl 5.010000 on darwin (darwin-thread-multi-2level)
Remember to actually *READ* the README file! Especially if you have any problems.
Installing on a darwin, Ver#10.0
Using Oracle in /usr/oracle_instantClient64
Can't find sqlplus. Pity, it would have helped.
I'm having trouble finding your Oracle version number... trying harder
WARNING: I could not determine Oracle client version so I'll just
default to version 8.0.0.0. Some features of DBD::Oracle may not work.
Oracle version based logic in Makefile.PL may produce erroneous results.
You can use "perl Makefile.PL -V X.Y.Z" to specify a your client version.
Oracle version 8.0.0.0 (8.0)
DBD::Oracle no longer supports Oracle client versions before 9.2
Try a version before 1.25 for 9 and 1.18 for 8! at Makefile.PL line 175.
I've triple checked that I've downloaded and installed the proper 64-bit drivers from Oracle. I also checked to make sure that I'm running 64-bit Perl.
If I force the version number like this:
perl MakeFile.pl -V 10.2.0.4
It completes, but I receive the error message when running "make":
Oracle.c:2267: error: ‘SQLT_BIN’ undeclared (first use in this function)
Oracle.c:2277: error: ‘SQLCS_NCHAR’ undeclared (first use in this function)
Oracle.c:2281: error: ‘SQLT_INT’ undeclared (first use in this function)
Oracle.c:2283: error: ‘OCI_FETCH_PRIOR’ undeclared (first use in this function)
Oracle.c:2287: error: ‘OCI_FETCH_NEXT’ undeclared (first use in this function)
lipo: can't open input file: /var/tmp//ccyIFLPN.out (No such file or directory)
make: *** [Oracle.o] Error 1
I realize this is because of the "-arch ppc" argument that needs to be removed from Makefile, but even after removal the removal of all 32-bit references, I still saw the error message.
Running 10.6.8 Snow Leopard with Oracle Driver version 10.2.0.4
I found that the key to this issue was making sure that MakeFile.pl could find the Oracle version.
The problem I ran into was that Safari was downloading the zip files from Oracle.com, but unzipping them and somehow corrupting the library.
Instead, I used a different browser and downloaded all the zip files into one directory. Then I ran the following tar commands:
tar -xf instantclient-basic-10.2.0.4.0-macosx-x64.zip
tar -xf instantclient-sdk-10.2.0.4.0-macosx-x64.zip
tar -xf instantclient-sqlplus-10.2.0.4.0-macosx-x64.zip
The copy all the contents in the folder "instantclient_10_2" to $ORACLE_HOME (set previously)
sudo cp -R instantclient_10_2/* $ORACLE_HOME
Also, I did not need to edit the Makefile generated by the MakeFile.pl script to remove the "-arch ppc" references.
You should not recreate on your machine the same directory structure as of the client libraries packager.
Don't do mkdir -p /b/227/rdbms/
Use MacOSX library header management tools: otool and install_name_tool
For instance, I have updated the library headers to my deployment architecture:
otool -L /usr/oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1
/usr/oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1:
/ade/b/2649109290/oracle/rdbms/lib/libclntsh.dylib.11.1 (compatibility version 0.0.0, current version 0.0.0)
/ade/b/2649109290/oracle/ldap/lib/libnnz11.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
install_name_tool -id /usr/oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1 \
-change /ade/b/2649109290/oracle/ldap/lib/libnnz11.dylib /usr/oracle_instantclient/11.2.0.3.0-64-bit/libnnz11.dylib /usr/oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1
otool -L /usr/oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1
/usr/oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1:
/usr/oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1 (compatibility version 0.0.0, current version 0.0.0)
/usr/oracle_instantclient/11.2.0.3.0-64-bit/libnnz11.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
Check all files that come with the Oracle instantclient libraries and fix the path of all dependent libs
otool -L adrci
otool -L genezi
otool -L libclntsh.dylib.11.1
otool -L libheteroxa11.dylib
otool -L libnnz11.dylib
otool -L libocci.dylib.11.1
otool -L libociei.dylib
otool -L libocijdbc11.dylib
otool -L libsqlplus.dylib
otool -L libsqlplusic.dylib
otool -L sqlplus
otool -L uidrvci
Then, you link your dynamic libraries to the place they're supposed to be.
And you can avoid using that export DYLD_LIBRARY_PATH because you know how to setup your system
cd /usr/lib
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1 .
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1 libclntsh.dylib
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libheteroxa11.dylib .
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libnnz11.dylib .
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libocci.dylib.11.1 .
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libocci.dylib.11.1 libocci.dylib
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libociei.dylib .
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libocijdbc11.dylib .
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libsqlplus.dylib .
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libsqlplusic.dylib .